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.
Thursday, December 10, 2009
Wednesday, November 18, 2009
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.
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.
Monday, November 16, 2009
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.
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.
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.
Sunday, November 15, 2009
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.)
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.)
Friday, November 6, 2009
nice ZIL device....
Working together with James McPherson, I've been able to get a driver for a really nifty device from DDRdrive -- see here -- working with OpenSolaris.

The device itself has interesting applications -- but I suspect the real killer application for it is in use as a "Logzilla" (ZIL) to accelerate synchronous write loads with ZFS. The only limitation on performance is the software and the single PCIe lane. (We're really right up against the PCIe single lane limit.)
From the driver perspective, its really interesting because it works with only modest changes to blk2scsa (which I'll be integrating into Nevada soon). The driver itself is tiny -- only about 950 lines of code. Its proven to be a great validation of the concept of blk2scsa -- while I never intended blk2scsa for use with high performance devices, I'm ecstatic that its as performant as it is. (Sorry, I can't post performance numbers here -- at least not yet.)
If you already have one of these devices, and want to test it in a non-production environment running OpenSolaris (no Solaris 10 yet!), please drop me a line. I'm willing to work with a few people to get some more testing done.

The device itself has interesting applications -- but I suspect the real killer application for it is in use as a "Logzilla" (ZIL) to accelerate synchronous write loads with ZFS. The only limitation on performance is the software and the single PCIe lane. (We're really right up against the PCIe single lane limit.)
From the driver perspective, its really interesting because it works with only modest changes to blk2scsa (which I'll be integrating into Nevada soon). The driver itself is tiny -- only about 950 lines of code. Its proven to be a great validation of the concept of blk2scsa -- while I never intended blk2scsa for use with high performance devices, I'm ecstatic that its as performant as it is. (Sorry, I can't post performance numbers here -- at least not yet.)
If you already have one of these devices, and want to test it in a non-production environment running OpenSolaris (no Solaris 10 yet!), please drop me a line. I'm willing to work with a few people to get some more testing done.
Thursday, October 29, 2009
audioemu10k driver pushed
I just pushed the audioemu10k driver into Solaris -- it will be in builds 128 and higher. Here's what the flag day message said:
I still would enjoy receiving test feedback, especially for folks who want to use it with unusual configurations or for more than just plain stereo output.
The push of CR 6539690 introduces support for audio for Creative Sound Blaster Live! and Audigy devices based on the EMU 10K1 and 10K2 devices. If you have such a device, you can now enjoy audio playback and record support using your audio device.
Devices supported are identifiable by the PCI ids pci1102,2, pci1102,4, and pci1102,8. This should be the full set of Sound Blaster Live! and Audigy PCI devices not already supported by the audiols or audiop16x drivers. It does not include support for any X-Fi devices.
This driver includes 5.1 and 7.1 surround sound support, and SPDIF support, for devices that are capable of it. It also includes support for the various break out boxes (Live! Drive and Platinum products), although it does not include support for MIDI or the infrared remote control found on such boxes.
I still would enjoy receiving test feedback, especially for folks who want to use it with unusual configurations or for more than just plain stereo output.
Tuesday, October 27, 2009
Taking myself off of laptop discuss
I'm tired of seeing bounce messages each time I reply to some thread on laptop-discuss@. The draconian list management policy is set such that when I reply to a message delivered to me, it always results in a bounce. This happens a couple of times a week when I try to reply to a message where I think I might have helpful information. (The bounces might have been due to a bogus attempt on my part to use a vanity opensolaris.org address in my subscription, I don't know. To be honest, I don't really care -- it should not matter. This has become a matter of principle to me.)
I think there is a way I can cobble my list subscription address to work, and there are solutions where I can subscribe multiple times to the list, but I refuse to go to ridiculous contortions because the list manager for this list still refuses to actually moderate the list.
(Mailman has both support for manual moderation of addresses that are not subscribed to it and the moderator can also whitelist addresses that he knows are from reasonable posters. This is the procedure I use for managing the several lists I maintain.)
Btw, this problem is probably going to impact nearly every Sun employee post Oracle acquisition, by the way, particularly if Oracle does header rewriting to rewrite outbound From: headers to be some @oracle.com address.
If you want my participation on laptop-discuss (and this will probably also happen to driver-discuss), then ask the list moderator to change his way of doing business. (Or perhaps, to actually start doing the real duty of moderating posts instead of setting a draconian policy and then ignoring it.)
I think there is a way I can cobble my list subscription address to work, and there are solutions where I can subscribe multiple times to the list, but I refuse to go to ridiculous contortions because the list manager for this list still refuses to actually moderate the list.
(Mailman has both support for manual moderation of addresses that are not subscribed to it and the moderator can also whitelist addresses that he knows are from reasonable posters. This is the procedure I use for managing the several lists I maintain.)
Btw, this problem is probably going to impact nearly every Sun employee post Oracle acquisition, by the way, particularly if Oracle does header rewriting to rewrite outbound From: headers to be some @oracle.com address.
If you want my participation on laptop-discuss (and this will probably also happen to driver-discuss), then ask the list moderator to change his way of doing business. (Or perhaps, to actually start doing the real duty of moderating posts instead of setting a draconian policy and then ignoring it.)
Subscribe to:
Posts (Atom)