Do you use IDN? (E10K inter-domain networking)

I was looking, and one of the legacy device drivers we still support is the Enterprise 10000 Inter-Domain Network. This is a memory based interconnect network that emulates an ethernet.

It occurs to me that we could update this driver to use the GLDv3, which would potentially have a significant performance boost for it. (Really, a better solution would be to create a new low level MAC type for it Nemo, but clearly that's probably too much pain for a product that is no longer shipping).

Anyway, I'd be interested to hear of any sites which use IDN on E10K class systems, and would like to see this (already high performance) network get another boost.

The other legacy SPARC drivers which are not GLDv3 compliant are:

• cassini (ce) (probably never going to be GLDv3, but that's another matter)
• gem (ge) -- this one could be easily converted *if* I had fiber cards to test it with, although there are political concerns as well. (It uses the same MAC controller as "eri", which I converted a while back.)
• scman -- This is used for the Starcat (E15K/25K) connection between the SC and domains. It is also based on the eri driver, but has some special hacks. I'm a bit paranoid about touching this one, but if someone really wants it to be GLDv3, please let me know. (This isn't supposed to be a high performance network!)

I'm not aware of any other non-GLDv3 device drivers remaining for SPARC, but if you know of any, please let me know!

New audioctl coming soon

I integrated a replacement for mixerctl (and also removed mixerctl) back in build 130. Well, build 130 is coming out really soon (I believe it is available internally in SXCE form now.)

I think therefore that it is time to provide more detail here about the new audioctl syntax:

NAME
   audioctl -    audio mixer control command line application

SYNOPSIS

   audioctl list-devices

   audioctl show-device [-v] [-d device ]

   audioctl show-control [-v] [-d device] [control ...]

   audioctl set-control [-v] [-d device] control value

   audioctl save-controls [-d device] [-f] file

   audioctl load-controls [-d device] file

DESCRIPTION
   The audioctl command is used to control various features  of
   the audio mixer and to get    information about the audio mixer
   and the audio device.

   The audioctl command operates on the following data types:

  device
      An audio device, such as "audiohd#0".   The subcommands
      that accept this do so as an argument to an option -d.
      If not supplied, then the default audio device is assumed.
      Any device node associated with an audio device will work
      as well, such as /dev/sound/0, /dev/dsp1, or /dev/audio.

  control
      A mixer control name, such as "volume".

  value
      The value of a control.  The specific format depends on
      the type of control.  Monophonic values usually use a single
      whole number between 0 and 100, inclusive.  Stereo values
      use a pair of such numbers (representing right and left
      channels.)  Boolean values indicate either "on" or "off".
      Enumerations take a single value of one or more names.

  file
      An ASCII text file of control settings.

Options:
   Each subcommand has its own set of options that it takes.
   However, some subcommands support the special flag -v, which
   indicates a request for more verbose output.

SUBCOMMANDS
   The following subcommands are supported:

   audioctl list-devices

  List all the audio devices on the system.

   audioctl show-device [-v] [-d device]

  Display general information about a device.

   audioctl show-control [-v] [-d device] [control ...]

  Display the control setting values for the device.  The named
  controls are displayed.  If no control names are provided, then
  all control values are displayed.

   audioctl set-control [-v] [-d device] control value

  Changes the value of a control to the supplied value.

   audioctl save-controls [-f] [-d device] file

  Saves the current state of all mixer control values to the named
  file.  The command will abort safely if the file already exists,
  unless -f is supplied.

   audioctl load-controls [-d device] file

  Restores previously saved state in the named file for all mixer
  controls.


ENVIRONMENT VARIABLES
   AUDIODEV     If the    -d and -a options are not specified,  the
       AUDIODEV  environment    variable is consulted. If
       set, AUDIODEV contains    the full path name of the
       user's     default  audio    device.

I expect there may be some questions or concerns about the new syntax. If they are not answered by the manual page above, please don't hesitate to ask me.

quick system identification

I am frequently needing to know "which system am I using". (I have trouble keeping track of which ones are which) -- i.e. is this the laptop, the Ultra 20, the whitebox, etc.

I had been using smbios a lot, but that's a bit awkward and non-portable to SPARC or systems that don't support smbios. Here's a quick script that can quickly tell me what model I'm working on. It works on SPARC and x86 alike. I have it stored in ~/bin/system -- it only works on Solaris of course. Feel free to borrow, reuse, whatever -- I hereby donate it to the public domain:

#!/usr/bin/ksh

sysconf=`/usr/sbin/prtdiag | head -1`
biosconf=`/usr/sbin/prtdiag | head -2 | tail -1`

sysconf=${sysconf#*:}
biosconf=${biosconf#*:}
sysconf=`echo ${sysconf} | /usr/bin/sed -e 's/^ //g'`
biosconf=`echo ${biosconf} | /usr/bin/sed -e 's/^ //g'`
if [ -z "$sysconf" ]
then
printf "BIOS: %s\n" "$biosconf"
else
printf "%s\n" "$sysconf"
fi

Sample outputs from a Toshiba laptop, a Sun V890, and a non-name Intel whitebox system:

TOSHIBA TECRA M9
Sun Microsystems sun4u Sun Fire V890
BIOS: Intel Corp. BX97520J.86A.2777.2007.0805.1747 08/05/2007

While the format isn't terribly parseable, its great for giving a quick assessment about what type of machine I'm on.

new aquarium lights

Some of you may know that I keep a salt water reef aquarium (210 gallon). Well, one of the challenges with such aquariums is lighting -- most corals need a large amount of high quality light to grow.

Most systems use metal halide lighting, which is extremely bright, and extremely hot. On my aquarium I've used three 250 watt MH lights, supplemented by a pair of 150 watt MH lights. (The 150s have been out for a while due to a bad ballast.) Yes, that's over a kilowatt in lighting. And MH lights have historically been considered some of the most efficient lighting -- i.e. most lumens or PAR per watt.

One alternative that has been up and coming has been LED based lighting. High power LED systems offer a lot of potential capabilities (although due to a patent problem that has put at least one company out of business and probably set the industry back at least five years, software based control of LEDs is only available on extremely expensive lighting systems -- systems costing thousands of dollars.

And until recently, inexpensive LED lighting simply did not exist.

I recently had cause to investigate this, as the bulbs in two of my 250s have died recently -- and I'm particularly unhappy with 250 watt MH lighting for several reasons: heat, problems with bulb fit (whoever designed the mechanical interface used for 250 and 400 watt double-ended MH lighting needs to quit mechanical engineering -- I've had numerous problems getting the bulbs to stay put in their "friction" based holding interface, and broken a couple of bulbs trying to increase tension so that they wouldn't fall out of the fixture), and power consumption (power in California is very expensive.)

Anyway, I'm happy to report that I found a good alternative. LED Wholesalers.com offers a 120 watt LED fixture intended for this application for just over $300. (They have an eBay store where the fixture can be purchased for under that, but with shipping and our ridiculous 9.25% CA sales tax, you'll still be over $300.) Compared to other options, this price is ridiculously low.

I put it on my aquarium yesterday, and comparing side by side with the remaining 250 watt MH fixture, I think the fixture "appears" to be about equivalent to a 250 watt MH. I've not measured it precisely, but the light appears about as bright as the 250 MH (the wife says brighter, but I'm not sure), although the spectrum is a bit bluer. If I had to guess I'd guess the spectrum to be somewhere around 18000K.

Anyway, I thought I'd post this here, since I think I'm one of the very early adopters of this. I'm going to monitor the health of my corals, and if it goes the way I hope it will, I'll be purchasing two more of these units to get full coverage over the entire aquarium. I might even purchase one for my 56 gallon tank. (I might supplement with another 100 - 200 watts of compact fluorescent at ~6500K though. That's still only about half as much power as my system previously consumed.)

I'll return to this post in the coming months to report my results as I get more experience with these lights.

Bad sound in Virtual Box in recent builds

Its been pointed out to me that if you use Virtual Box and Solaris guests with recent builds (say newer than 124), that you might get a bad sound in the Solaris guest.

Turns out that the problem is that the Boomer stack has increased its timing accuracy to a higher limit, beyond what Virtual Box can provide.

We're going to fix this properly soon... but in the meantime, you can just edit /kernel/drv/audio810.conf and change the play-interrupts to 30 in the guest.

This is CR 6901849 in case anyone is tracking it closely.

Jack of all trades, master of none

While I probably say this about other things (C++, perl), I think I've found something else it applies to -- the OpenSolaris Live CD.

The Live CD attempts to offer both a "Live Use" environment, and a "full" (for some value of full) installable copy of OpenSolaris.

The problem with this is that we have way, way too many things duplicated on the Live CD. For example, two copies of Mozilla, two copies of Evolution, and two copies of Thunderbird. (One copy each to run in the live environment, and one copy in packaged form for installation.)

This is crazy.

People who want to play around with an operating system don't need two different mailer packages. In fact, one could argue that if I'm going to use a Live environment, the CD is not going to be my method of choice. I'm going to want eithe a DVD, or (more likely) USB media where I can get faster performance and have more options. Trying to keep a live demonstration environment in the confines of a CD (or rather the space left on the CD after the installable portions), makes no sense at all. As a Live environment, I am going to want all the bells and whistles, and compilers too! (And -- perhaps most importantly -- office applications like Open Office, which don't fit in the CD right now.)

Conversely, there are those who just want to install the bits. The live media is just a vehicle to install from. Oh, there are potentially useful applications that can be present too, but they are always in support of installation. Having a web browser so that I can access my router's configuration, for example, or search for updated information about my hardware, is likely to be useful. But do I really need or want two different mailers? And klotski? PDA synchronization? Etc. This is crazy.

And its worse; because of the size of the Live "CD", we already have a situation where it does not fit on the CD. We have also sacrificed other things that, in my opinion, we should not have, in the name of "space". I'm a strong tcsh advocate, and its absence from the installation media is sorely felt, especially when installing to systems that don't have a Internet connectivity. I'm sure there are other similar things that could be the installation media if only there were space.

Well, there is space. Easily. We just need to be smarter about it.

Its time to separate the jobs into separate tasks.

• Live Media. (Live DVD, and probably also USB.) Give up on trying to do it in 700MB for a CD though. This should be sized for a single DVD, and have all the goodies, including OpenOffice. It should continue to offer installable bits as well.
• Install media. This should not have the Live environment, but have only those tools which are deemed supportive to installation. (Do include a web browser, but don't include games or a music player, for example.) It should fit easily within 700MB. I suspect that the installation media could even be merged into the AI media, to support a single disk that can do either network installation, or local CD-ROM based installation.
  

Eventually the 700MB limitation is going to be a problem even with a change like the above. I believe that we can go a lot longer with what we've got, if we don't try to force the jack-of-all-trades to fit into a shoebox, though.

sar graphical output - do you use sag?

In the process of trying to "clean house", one of the hiccups we've run into is "sag", which is used to generate graphical output from "sar" data. (If you don't use "sar" or "sag", you can stop reading now.)

sag generates Tek 4014 mode output, which can (through some contortions) be viewed either in xterm, or converted (using "posttek") to PostScript. The results are actually fairly unpleasant to work with, and rather ugly, as the results are generated through some rather ugly abuse of "graph" and "plot".

I'd like to eliminate sag altogether, because I believe far superior alternatives exist. One example is kSar, which is a Java application which generates a variety of graphs and has both interactive and scripted operation. (It can also process sar output from the Sysstat package used on Linux, or AIX which is a plus.) It can generate output in a variety of useful formats as well, making it useful in generation of web-based reports, etc.

If you use sag, and would be impacted by its absence, I would really like to know. I am operating on the belief that there are very few, if any, of you out there -- tell me otherwise if this case, please!

Specifically, are you using sag in programs or scripts? What does sag offer for you that kSar lacks? (Or would the transition to kSar otherwise be painful for some reason?)

Note that for the purposes of this discussion we can assume that I'd be making kSar available as an IPS package via the SFW consolidation, and that it can process sar data from any version of Solaris going all the way back to at least Solaris 2.6 (and likely all the way back to Solaris 2.0 or 2.1.)