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.
Wednesday, November 18, 2009
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.)
Monday, October 26, 2009
SDcards and ZFS
I've gotten this question a few times. "Would SDcards make a good ZIL device?" "Would SDcards make good ZFS devices?" The answer to both is resoundingly no.
The reason for this is simple, and is the same reason you should never reformat SDcard media using your computer.
It boils down to the fact that you need to do some very "SDcard" specific optimizations when you layout your filesystems in order to get good performance. (The details for this are only available after signing an NDA with the SDcard trade association, btw.) Of course, general purpose computers use general purpose filesystem code, which is targetted for hard disks. So the optimizations, if there are any, are all wrong for SDcard media. (Note that this only matters when doing the initial filesystem layout .... i.e. when you are formatting the media.)
You can reclaim at least some of the performance you might have lost if you've made this mistake, by reformatting the media in your camera. But unless you have a much fancier camera than I do, your camera probably doesn't speak ZFS.
The reason for this is simple, and is the same reason you should never reformat SDcard media using your computer.
It boils down to the fact that you need to do some very "SDcard" specific optimizations when you layout your filesystems in order to get good performance. (The details for this are only available after signing an NDA with the SDcard trade association, btw.) Of course, general purpose computers use general purpose filesystem code, which is targetted for hard disks. So the optimizations, if there are any, are all wrong for SDcard media. (Note that this only matters when doing the initial filesystem layout .... i.e. when you are formatting the media.)
You can reclaim at least some of the performance you might have lost if you've made this mistake, by reformatting the media in your camera. But unless you have a much fancier camera than I do, your camera probably doesn't speak ZFS.
Subscribe to:
Posts (Atom)