#883 - the Mount Diablo Challenge

This weekend marks the first time I've ever participated in any kind of organized cycling event - the 2007 Mount Diablo Challenge, a fundraiser for Save Mount Diablo.  The Mount Diablo Challenge is a bicycle race up 10.8 miles of paved road, climbing 3249 feet (so they say) with an average grade of 5.7% or so; here's a good graph of the elevation profile.  I parked at Monte Vista High School and rode the 3 miles or so over to The Athenian School early Sunday morning; the overnight low had been chilly, but the skies were very clear and the morning was sunny - it was perfect.  Sunny, with an air temperature in the mid-50s, warm in the sun.  Perfect.

My old friends Bob and Joe and I started in wave 4, about 200 riders at the tail-end of a total of 1000.  As an aside, Bob, Joe and I first met while working at Locus Computing Corporation 20 years ago; are we really that old now?  Our heart-rate monitors were giving pretty similar numbers, so it was easy to maintain a fairly matched pace, and we rolled-up on the South Gate ranger station almost before I knew it, followed by the Rollers in Rock City.  We rolled past the Junction ranger station about 36 minutes after the start, a very decent time for me (in training rides, I've been happy to reach the Junction in 38 minutes).  Normally, I'd stop at the Junction and eat a gel, refill my water bottle, but this time I'd loaded the water bottle with Gatorade instead of water, thus obviating the need for a gel - or a stop at all.  That was the big thing for me on this ride - I was pacing myself to avoid stopping at all, since my training rides always had 10 minutes or so of stops on the way up.

After the Junction, the ride remained moderate for about a mile and a half, but notched up into a steeper climb as we passed picnic spots named Blue Oak, Oak Knoll and Grapevine - it eased off temporarily passing Juniper and the large Diablo Valley Overlook.  Bob had broken away from us by now, and poor Joe was asking me if I would still give him a ride afterwards if he wet his spandex shorts - the toilet at Juniper was a welcome sight, and we burned about a minute there.  From previous rides, I knew my hardest section was next, riding from Juniper up to Devil's Elbow, a sharp hairpin turn about 1 mile from the summit, and it was really important to keep a good pace and not burn out and stop before passing the Elbow - because the climb flattens out (by now, Joe had realized "flat" on the hill means "less than 3% grade") and there's plenty of rolling recovery there before The Wall.  All I had to do was roll past the Elbow and I'd be set to finish the ride.

We passed a remarkable pair of riders on the way to the elbow, Jens and Peter Hillen.  Peter is 6 years old and was pedalling very seriously on a tag-along attached to Jens' bicycle.  I tried to make a joke with young Peter, asking "is your dad carrying his weight?" and Peter answered with something like "he's doing the best he can" with a very serious expression.  The sincerity was almost tear-jerking.

Shortly afterwards, I passed another rider, and he called out "Hey! Myers!".  It was Ed; we'd met on the hill one morning in September and realized that our bib numbers for the Challenge were sequential (me #883, Ed #884).  Fun stuff.

After passing the Elbow (and being snapped for posterity sake), I soon shifted-up a couple of gears and enjoyed the "level" ride, and started to get psychologically ready for The Wall - a 16+ percent grade leading to the finish line. Summit Road splits into an "up" lane and a "down" lane at the base of The Wall; only for the Challenge, the "down" lane becomes the up lane - and I'd never done it that way before.  It turns out that the grade is slightly easier at first and peaks right before the finish line.  So I paced Joe until a few meters before the finish line, then sprinted. My effort was good enough to secure a 400mS lead!  1:17:08.3 represents my best time ever up the hill, and it rewarded me for nailing a pace that let me avoid stopping.  Also, narrating the ride for Joe helped me remember where the hard work and the recovery was, so I planned better and rode better.

Bob had beat us to the top about 2 minutes earlier, and we did a little sight-seeing from the summit before heading down to the "lower summit" parking lot where a big party was already in progress.  We spent about an hour there, meeting up with yet another old Locus friend, Marty Heyman of the Mount Diablo Amateur Radio Club, a volunteer for the event, enjoying a handful of Mother's frosted animal cookies and a Jamba Juice smoothie.

The Contra Costa County Sheriff's Office was running an escort for cyclists down the hill; we had to wait in waves again, but our escort was running a very pleasant clip, basically as fast as I would normally ride down the hill.  It was icing on the cake, really - riding down the hill, working the turns in a pack of cyclists.  It took me straight back 20 years to my motorcycle road-racing days on the tracks and in the canyons of Southern California.  Once we were nearly at the bottom, in the Tire Poppers, I managed to trail-brake into a soft patch and break loose into a good rear-end slide.  My only real worry was that I'd tag a cyclist next to me, which didn't happen (it would have been Bob!).  I did manage to remember to shout out "I meant to do that! I do that every time I ride here" as if it were true after recovering a little less gracefully than I'd prefer.

We rode back to the Monte Vista High School parking lot, even though Bob and Joe started griping about something, loaded the bikes onto the Thule rack, and headed out for lunch with family at Primo's Pizza in Danville.  This was one of the most enjoyable weekends I've had in a long time - old friends, a great day and a great ride really clicked together.

Posted by danasblog [Cycling] ( October 10, 2007 01:53 AM ) Permalink

How I got ready for the Mount Diablo Challenge 2007

Way back in 1979, when Jimmy Carter was U.S. President, I used to bicycle a lot, on a sturdy Grand Auto 10-speed.  One summer day,with a handful of friends, we started up Mount Diablo. I ended up making it to the base of "The Wall", about 600 feet from the summit proper, up a very steep 18% incline.  It would be another 28 years before I returned for a second shot at the summit.

In the last few days of 2006, my doctor explained that my cholesterol levels were borderline and that I really needed to do something about it.  He suggested diet changes, exercise, weight loss and prescribed a mild dose of cholesterol medication.  I must have been ready, because I implemented those changes starting that day.  At the time, I was around 245 pounds and basically sedentary, other than 3-4 mile hikes a couple of times a month to go geocaching.  I started walking daily, hiking more on the weekends, and bought a mountain bike.  In late May, I was down to 185 pounds and didn't need the cholesterol meds any longer (frankly, I think my doctor figured that I would be like every other patient and perhaps lose 5 pounds; he was pretty surprised when I came back 6 weeks later, 26  pounds lighter).

Still, I didn't do a lot of cycling, until my old friend Bob said "Hey, I'll be in town next week, let's go for a nice, easy ride up Mount Diablo".  The morning of June 3, 2007, Bob very patiently led me up to the summit that I'd failed to reach 28 years earlier.  It took me something like 2 hours and 45 minutes on that tank-like mountain bike, but the hook was in my cheek.  On the way up, Bob mentioned the annual Mount Diablo Challenge race to the summit, and how much he enjoyed it, enough to drive up from Los Angeles to do it.  He suggested I should enter this year, but the idea was pure fancy as far as I could tell.  Surely, no one took nearly three hours to make the climb from The Athenian School like I did.

A few weeks later, I had to ride back up that mountain, I just knew I could do better; I'd started riding 8 miles most every day around my house.  This time, I had a very pleasant 2 hour, 25 minute ride to the summit.  A couple of weeks later, I made the same ride in 1h 59 minutes.  I'd upgraded the mountain bike to street tires and SPD pedals, but it was clearly time to start shopping for a road bike (and, since I weighed 175 pounds now, I wasn't worried about breaking spokes any longer).

Ultimately, I selected a 2007 Cannondale Synapse 1 Triple, at a very reasonable clearance-sale price at REI (I know, I know, it's a triple, I'm such a recreational cyclist...).  I rode the new bike up Mount Diablo for the first time on September 1 - measuring 1 hour, 42 minutes, but I sure had to work harder this time - I'd become reliant on those really low granny gears on the mountain bike.  At this point, the Mount Diablo Challenge didn't sound like such a flight of fancy, so I signed-up.

I spent the next week doing daily sessions of repeated runs up a local hill, shifting up gears until I had to stand in the saddle, and I returned to Mount Diablo at the end of the week - and did the climb in 1 hour, 32 minutes. On September 30th, feeling a little tired, I made it up Mount Diablo in 1 hour, 26 minutes.  The next ride up would be with 1000 other cyclists on October 7.

Posted by danasblog [Cycling] ( October 09, 2007 01:56 PM ) Permalink

American River Parkway, 23 Sep 2007

I've been craving a longer ride for a couple of weeks; every weekend I've been riding up Mount Diablo, in preparation for the Mount Diablo Challenge, and that usually uses up my budget of riding time for the weekend. So I planned ahead for this weekend that I'd do Diablo on Saturday (as usual) and then ride the American River Parkway on Sunday.

Essentially, the American River Parkway has a paved bike path that runs 32 miles from downtown Sacramento to Folsom Lake. The path crosses maybe 3 actual roads; the rest of the crossings are basically driveways.

At the beginning of August, before I'd bought the road bike, I rode my MTB (with slicks) up the Parkway. It took about 6h 45m total to ride up and down the path, and that includes the 5-mile detour I took off the path into downtown Sacramento (I had no idea there were two identical-looking bike paths starting in Discovery Park...) and the long amount of time I lazed around at Folsom Lake. Total ride was about 69 miles, and I was definitely dragging on the way back.

Now that I'd been riding the road bike for a while, I kept thinking I wanted to go ride the Parkway again. As luck would have it, the weather was a bit gloomy Saturday morning and I ended-up not riding on Saturday, doing family-stuff instead. On Sunday, I sucked-down a gel
and hit the American River Parkway path at Discovery Park around 1130 under partly-overcast skies, temperatures on the low-side of seasonal around 73F. I stopped once for a few minutes to suck down another gel and refill my water bottle at one of the many parks along the way, but was surprised to arrive at the end of the path after 1h 45m - averaging 18.3MPH for 32 miles and about 850 feet of total climb.

One interesting moment came when I passed a large mass of bicyclists at one park; they were about to launch the Third-Annual Mustard Seed Spin and there were 400+ young cyclists ready to go; I admit I was happy to be ahead of the massive bunch, but it was great to see so many enthusiastic youngsters on bikes.

The end of the path at Folsom Lake is at a normally popular beach called Beals Point; since the lake is unusually low right now, the beach is dry and the only people I saw there were other cyclists, including an interesting couple on a tandem. I scarfed a Clif Bar and spent longer chatting with the tandem couple than I'd planned to rest; I started back down the bike path around 1340.

About half-way back, I stopped at a park to have one more gel and met a few of the Sacramento Bike Hikers that were sweeping the Mustard Seed Spin. In a pleasant small-world moment, I mentioned that I drove SAG for the Breast Cancer Fund's Bike Against the Odds last weekend, and they said “oh yeah, we rode that!”. As I spent a few minutes at this stop, the last of the Mustard Seed riders arrived, and, after I took off, I started encountering groups of them. Again, it was pretty impressive to see these youngsters spinning along on a wide variety of bikes completing at least a 13-mile ride. At the Mustard Seed start/finish, they had a balloon arch, kids with horns, cheerleaders (!) and many parents, and they cheered me on as I passed, even though I wasn't a participant.

After I passed Sac State, I picked-up the pace a bit and was averaging around 20MPH for much of the remainder of the ride; I rolled-up to my car in Discovery Park 3h 58m from when I rolled away, averaging just over 16MPH for the entire ride and about 18.7MPH while rolling. My recovery snack was a Balance Bar washed down with Costco's version of Gatorade.

Compared with my previous ride at the beginning of August, I felt considerably better this time, and spent far less time on rest stops. Apparently, Trails.com voted the American River Parkway the “best bike path of 2006”, and it is easy to understand why. It is very pretty, well-maintained, easy-to-access and has water and restrooms in many places, really quite a gem.

Posted by danasblog [Cycling] ( September 24, 2007 10:31 AM ) Permalink

Mazda Zoom-Zoom Live 2006, Alameda, CA

For the first time since I bought a new MX-5 Miata in 2002, I got around to going to a Mazda Zoom-Zoom Live event. Four courses were in operation, but I only opted to drive the RX-8 and MX-5 on the sport course, and the CX-7 on the "Timed Gymkhana" course.

While waiting for a turn in the RX-8, the people running the line kept calling out for anyone interested in driving an car with automatic transmission. How silly! There was usually a taker, but sometimes they'd call for several minutes. Mazda seemed to bring about half each of auto and manual; three-fourths manual would have made the lines go faster.

Once I drove the RX-8, I liked it. It was smooth, quick, handled pretty well for having such a cushy ride and flogged well through the (untimed) course in second gear. Woo-hoo. Too bad the car is butt-ugly and is an apex-seal failure waiting to happen.

While waiting for the MX-5, I noticed the same problem with automatics, though it was even worse than for the RX-8. The automatic MX-5s just sat there for several minutes at a time. Meanwhile, one of the MX-5s with a manual tranny pulled-in, with a very loud engine knock. The driver got out and mentioned that the check-engine light was on; that car was spirited away a few minutes later after sitting there, idling and making me think the event could be Knock-Knock Live. This, of course, made the line move quite a bit more slowly...

My 2002 Special Edition is due for new suspension after 40,000 miles, but the 2006 I drove was clearly tuned for a cushy yet reasonably tight ride. Everything about the car felt different; they even moved Reverse to where first-gear is on my '02 (glad I didn't punch the throttle before noticing that). The car was quick, smooth and just felt bigger in vague ways than my '02. My '02 is definitely stronger (since it's running a Jackson Racing Supercharger kit) but the '06 was nice, even if it's not exactly a Miata.

Last, I decided to give the CX-7 a whirl on the Gymkhana track (the line was the shortest and it seemed like a challenge to flog one of those). In Gymkhana, the goal is to precisely hit the target time (27.000

seconds in this case). I had two turns to see how I'd do, and I figured the first turn was a throw-away. A luck would have it, I came in at 27.1 seconds on the first turn. Woo-hoo. I'm sure I'd do worse on the second try, so I bailed at that point. The CX-7 was surprisingly nimble, I didn't actually hate it very much, and it was certainly pretty quick. I didn't feel like waiting in the longer lines for the other tracks.

It was amusing that each track had a different incentive associated with it. The sport track (with just the MX-5 and RX-8) had no competitive scoring and was limited to two turns, clearly people want to drive these cars. The rest of the courses had some kind of competitive scoring, either target times or fastest-overall. Mazda marketing is smart - they know most people into cars are pretty competitive and are suckers for a driving contest. So the most exciting cars didn't need an incentive, but the more boring rides all had some kind of reward for trying them.

Overall, not a bad way to spend a few hours on a sunny Sunday morning. Maybe I'll do it again next year.

Posted by danasblog [My Roadster] ( October 23, 2006 10:06 PM ) Permalink

How often does Solaris sync-up with Intel ACPI CA releases?

We receive updates to the ACPI CA source on a semi-periodic basis from Intel, and I'll do a quick integration into a Solaris workspace using a simple script that handles the “average” case in under 2 minutes. I'll then build a kernel and sanity-test it on a machine or two. The entire process typically takes less than an a half-day, and I can quickly provide feedback to the Intel ACPI CA team. I'll review the changes in the update; if there's something compelling, or it has been more than 4 months since the last time I integrated into Solaris Nevada, I'll do additional testing on a much broader range of machines and start the integration process. This means that Solaris Nevada is usually less than a few months out-of-sync with the very latest Intel sources and represents broad “soak” testing.

Backports to Solaris 10 are demand-driven by escalations and functional-dependencies; for example, as part of the work I did to support the Sun Blade 8000, I backported the integration of ACPI CA release 20060217 to Solaris 10 6/06 (aka Update 2). Individual bug fixes (like CR 6426595) are often backported ala carte.

Posted by danasblog [ACPI] ( August 31, 2006 10:35 AM ) Permalink

Intel ACPI CA source release 20060721 integrated into Solaris Nevada build 48

I recently integrated Intel ACPI CA 20060721 into Solaris Nevada; it will be available in build 48. As is the case with most updates to ACPI CA, there are a few enhancements and a few bug fixes. One of the interesting enhancements in this update is to increase compatibility with “the other” ACPI AML interpreter:

Implemented support within the AML interpreter for package objects that contain a larger AML length (package list length) than the package element count. In this case, the length of the package is truncated to match the package element count. Some BIOS code apparently modifies the package length on the fly, and this change supports this behavior. Provides compatibility with the MS AML interpreter. (With assistance from Fiodor Suietov)

This is a good example of how everyone wins with open source – pretty much every non-Microsoft x86 OS today uses Intel ACPI CA. At the risk of tooting my own horn a bit, this update also contains the following bug-fix:

Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Myers)

I found this particular bug while testing on the Sun Blade 8000 (Andromeda); a very intense hot-plug test scenario would reliably fail after precisely 3 hours and 3 minutes, like clock-work. Andromeda's ACPI BIOS is used to implement PCIe hot-plug, so the test scenario was very heavily exercising a portion of the ACPI BIOS which dynamically creates a SystemMemory operation region, leaking a bit of memory-mapping each time. After something like 180 or so hot-plug cycles, this resource was exhausted, leading to the failure. I'm pleased we found this in the lab before a customer did, but I'm more pleased with how quickly the fix was integrated by Bob Moore at Intel. Once again, everyone wins with open source. This is a corner-case problem that won't be seen in the field.

Another change Intel made at my request was to provide support for 64-bit thread Ids – a minor change, but again, one which enhances stability and ease-of-integration.

For a complete list of changes in each ACPI CA release, have a look usr/src/uts/i86pc/io/acpica/changes.txt which is updated with each integration. The previously-integrated release of ACPI CA was 20060317.

Posted by danasblog [ACPI] ( August 31, 2006 09:05 AM ) Permalink

Solaris ACPI CA debug output options

How to control Solaris ACPI CA debug output on DEBUG and non-DEBUG kernels.[Read More]

Posted by danasblog [ACPI] ( May 09, 2006 09:36 AM ) Permalink

Smoking salmon at home...

One of my interests is traditional American barbecue (as opposed to grilling); I have both a New Braunfels Silver Smoker offset and a (gasp) Brinkman's Electric bullet.  While I prefer the offset for most anything, I've made several attempts at smoking fish (specifically, salmon) and the electric is much easier to manage for this.  Note that the 'stock' Brinkman's runs around 230F, which is too hot to produce good hot-smoked salmon, so I had to make a modification.  It's easy really; I got a 2000W rotary dimmer, a heavy-duty 6-foot extension cord, some twist-on caps and a bunch of zip-ties and made up a heavy-duty,  in-line dimmer (obviously, not to code).  It's easy now to dial the smoker down to 160-165F for hours on end, and the dimmer heat-sink doesn't even get (too) warm.  If you try this at home, don't skimp - you really need a 2000W dimmer for the 1500W electric smoker.

An important part of getting good smoked salmon (or any fish, for that matter) is brining the fillets before smoking them to set up a pellicle.  I'd made several attempts using a dry brine, a mixture of non-iodized salt, sugar, brown sugar and spices that is used to coat the fish, and was never happy with the results.  Dry brining just left way too much salt on the fish no matter what I did, and the spices really don't alter the flavor of the end result.

This week, I tried a traditional wet brine, in which I mixed just 1/4 cup each non-iodized salt, sugar and brown sugar into a gallon of water and soaked the 1.5" to 2" chunks of fillet overnight in the brine (in a covered plastic tub, in a refrigerator).  After draining and patting the pieces dry, I dusted them with a little black pepper - that's all - let then air-dry on a wire rack for about an hour, and then smoked them at 165F for 8 hours using a handful of Alder pellets  in the bottom of the smoker about every 45 minutes for the first 5 hours.  Well, 8 hours was a guess and it was too long for most of the pieces; they tasted great but were a bit over-cooked.  My next trial at this will probably dial the process in, smoking for around 6 hours and tossing-in a handful of Alder pellets every 45 minutes or so the entire time.


Posted by danasblog [General] ( March 15, 2006 07:08 PM ) Permalink

Living with a loquacious BIOS (or what's all that stuff in /var/adm/messages?)

I haven't heard any complaints about this yet, but I recently noticed that /var/adm/messages on my Acer Ferrari 3400 was filling up with jabber from the system BIOS, like this:

Mar 15 16:23:22 unknown acpica: [ID 927697 kern.notice] [ACPI Debug] String: [0x8] "QUERY_09"
Mar 15 16:23:22 unknown acpica: [ID 486228 kern.notice] [ACPI Debug] String: [0xD] "CMBatt - SMSL"
Mar 15 16:23:22 unknown acpica: [ID 214751 kern.notice] [ACPI Debug] Integer: 0x F1
Mar 15 16:23:22 unknown acpica: [ID 920918 kern.notice] [ACPI Debug] String: [0x12] "CMBatt - CHBP.BAT1"
Mar 15 16:23:22 unknown acpica: [ID 729625 kern.notice] [ACPI Debug] String: [0x1B] "CMBatt - BAT1 still present"
Mar 15 16:23:22 unknown acpica: [ID 578842 kern.notice] [ACPI Debug] String: [0x12] "CMBatt - UPBI.BAT1"
Mar 15 16:23:22 unknown acpica: [ID 776413 kern.notice] [ACPI Debug] Package: [0xD Elements]
Mar 15 16:23:22 unknown acpica: [ID 411424 kern.notice] [ACPI Debug] (0) Integer: 0x 1
Mar 15 16:23:22 unknown acpica: [ID 923811 kern.notice] [ACPI Debug] (1) Integer: 0x 1130

Pretty exciting, eh?  Back in Solaris Nevada build 29, I fixed kernel printf() so Solaris ACPI CA debug output would work, and I left the default ACPI CA "debug level" setting intact.  One of the things that the default level sends to /var/adm/messages is when an ACPI BIOS contains ASL statements like:

                Store ("CMBatt - BAT1 STATE CHANGE", Debug)
and
                Store (PBST, Debug)

The Acer Ferrari 3400 BIOS is peppered with them.  Some of you are already familiar with Intel's ACPI CA interpreter and know that there is a gobal variable to select levels of debug output, and may have just fixed it yourself (gold stars for all of you) but I'd bet a dollar there are many more people that are just suffering in silence.   Well, here's the easy way to make it stop - add the following line to /etc/system and reboot:


That's all.  If you really don't want to see any debug output from ACPI CA, you set it to 0, but that's a bit extreme.  For more information, have a look at this ACPI CA header file in OpenSolaris.

Solaris Nevada will continue to default to leaving this feature turned on, but I'll change the default for Solaris 10 when I backport to an update release.




Posted by danasblog [ACPI] ( March 15, 2006 05:40 PM ) Permalink

ZFS v. UFS performance for building Solaris

Abstract:


Background:

In the last week, a wad of ZFS fixes have integrated into Solaris Nevada, and, I'm sure, will roll out into the sunlight in a Solaris Express release.  The fixes sounded quite promising, so I ran an experiment this weekend.

DISCLAIMER: these are not official benchmarks of any kind.  They're just some stuff I did because it was too wet to go outside and mow the lawn.

I added another disk to my personal workstation (an 80GB Hitachi SATA 7200RPM drive, if it matters), partitioned it into two equal 40GB slices, and created a UFS in one slice and a ZFS pool in the other (I suppose it is possible that the location of the slices on the disk may have some impact on the overal performance; I may try swapping the filesystems in the slices as a sanity-test for this.  For now, I'm going to assume that the disk performance is the same for both slices).

... Then I got to work with some simple Solaris nightly-build benchmarking.

The tests are simple:

• Initial workspace bringover time
• Several trials of full nightly build time
• A "parallel" bringover, in which two workspaces were brought over at the same time
• A "parallel" build, in which two workspace were built at the same time.

Note that I only tested one kind of filesystem at a time, and that the system configuration was unchanged during the tests.  The system was essentially idle otherwise.  Overall, I'm assuming that the impact of all other system elements is identical.

On to the numbers!

First, the intial bringover:

UFS	ZFS
real    7m31.42s user    0m13.58s sys     0m19.53s	real    6m25.35s user    0m13.56s sys     0m18.63s

Well, the user time is identical in both trials, which one would expect.  I ran the same application twice, so the times should be about the same.  Whew! Sane results so far.  Note that ZFS seems to enjoy about a 17% performance advantage in this trial.  Note that this test is dominated by filesystem performance.

Now, the full nightly build trials.  I did three; the first one does a little less work in that the workspace is not populated with binaries to delete (make clobber).  These are just the real elapsed-time for each build, in HH:MM:SS:

UFS	ZFS
real    1:39:08 real    1:46:01 real    1:47:56	real    1:42:08 real    1:43:47 real    1:44:50

Interesting.  I'm not surprised UFS was quicker on the first trial and slower on the subsequent trials.  ZFS seems to be slightly faster overall, though the difference is just 1-2%.  Clearly, this experiment suggests that ZFS and UFS performance are essentially identical when it comes to building Solaris.  Note that this test is dominated by CPU performance.

Before the recent wad of ZFS fixes, I began to suspect that ZFS was too aggressive in internal locking and that multiple threads would become synchonized on a ZFS pool.  In fact, this would tend to explain the 40% penalty for using ZFS that I had seen on earlier Solaris bits.  So the next tests attempt to do two things in parallel; I launched the tests with a script that did something like


First parallel test - two bringovers in parallel:

UFS	ZFS
real    13m57.95s user    0m27.83s sys     0m41.19s	real    8m21.28s user    0m27.30s sys     0m36.77s

More sane numbers!  User times are the same and twice what a single bringover took.  UFS was almost but not quite twice the single-bringover real-time.  ZFS does very well in this test, around 65% faster.  Again, this test is dominated by filesystem performance.

OK, let's do two builds in parallel:

UFS	ZFS
real    8:09:42	real    3:34:15

The ZFS trial looks totally sane; 3h 34m is just about exactly twice the 1h 47m times we saw in the single-build trials.  The UFS trial took over 8 hours, which isn't easy to explain.  I did not monitor the system page/swap statistics during either trial, but I have a hard time believing ZFS wouldn't equally suffer page/swap penalties.   If I wasn't busy enough with real work, I'd try this again, but I don't believe I did anything blatantly wrong in this test case.

Whew.  This is strange - but the ZFS numbers remain totally sane.

Let's try one more round of tests, this time, turning compression=on in the ZFS.  Since I didn't do UFS trials, I'll just compare uncompressed to compressed here:

ZFS (uncompressed)	ZFS (compressed)
Bringover: real    6m25.35s user    0m13.56s sys     0m18.63s Single build times: real    1:42:08 real    1:43:47 real    1:44:50 Parallel bringover (2 ws): real    8m21.28s user    0m27.30s sys     0m36.77s Parallel build time (2 jobs): real    3:34:15	Bringover: real    6m32.13s user    0m13.56s sys     0m19.99s Single build: real    1:43:14 Parallel bringover (2 ws): real    9m48.18s user    0m27.55s sys     0m41.02s Parallel build time (2 jobs): real    3:30:35

From this, I suspect that ZFS compression exacts a slight penalty on write performance, but may impart a slight improvement in read/build performance.  In any case, I noted a compression ratio of over 1.7x after the parallel build time tests, so it's pretty cool that I'm getting more data on the disk and not paying a performance penalty at all.

As soon as build 36 makes it out into Solaris Express, I'd love to get some comparable results from the community.



Posted by danasblog [Solaris] ( March 06, 2006 11:56 AM ) Permalink

Something silly - "Fear Of Girls"

Google Video is great fun; this following short movie is simply amazing. I'm sure I'm not alone remembering FRP enthusiasts like these.

Posted by danasblog [General] ( January 31, 2006 02:42 PM ) Permalink

Configuring Solaris ACPI at boot-time

As part of the new Solaris ACPI subsystem integrated as part of Newboot, I've added a new bit to the "acpi-user-options" boot option.

Historically, acpi-user-options=0x2 has been the only publicly documented option, and is used to disable Solaris use of ACPI for CPU enumeration and interrupt routing. Generally speaking, the pattern has historically been to set acpi-user-options=0x2 if there's any problem at all, just to see if the system works better. Changes made in Solaris 10 have made ACPI use in Solaris much more robust, so disabling use of ACPI should not be required as frequently as in previous releases.

Beginning with Newboot, integrated into Solaris source in April (2005), acpi-user-options has changed in a couple of ways:

• The previous ACPI subsystem did not put the system into “ACPI” mode, but left the system in “Legacy” mode, where the system BIOS retains control of the system. The new Solaris ACPI subsystem based on ACPI CA now places the system in ACPI mode by default.

• acpi-user-options=0x8 causes the new Solaris ACPI subsystem to leave the system in Legacy mode. This is the first option one should try if ACPI-related issues are suspected.

• acpi-user-options=0x4 is present in Solaris 10, and causes both the previous Solaris ACPI subsystem and the new subsystem to partially disable use of ACPI – but Hyper-Threaded CPUs are still enumerated using ACPI tables. This is the second option one should use if ACPI-related issues are suspected.

• acpi-user-options=0x2 is present in Solaris 10, and causes both the previous Solaris ACPI subsystem and the new subsystem to disable the use of ACPI.

Generally speaking, the new Solaris ACPI subsystem seems to do very well by default. I'll blog separately about some issues I've diagnosed that appeared to be ACPI-related but turned out to be to something else (BIOS issues, actually).

Posted by danasblog [ACPI] ( June 14, 2005 10:21 AM ) Permalink | Comments[8]

Suppose I ought to introduce myself...

I'm Dana Myers, and I'm in the Solaris engineering organization where I spend most of my time leading the Solaris ACPI engineering effort. In my nearly 12 years at Sun, I've been a Solaris x86 engineer, a Consumer/Embedded engineer, a Java Wireless BizDev technologist, and once again a Solaris engineer. While my focus in on providing a high-quality ACPI sub-system based on Intel's excellent ACPI CA interpreter, you might find me tinkering with pretty much any system-board level thing. I still have a soft-spot for network device drivers - perhaps some of you are still using the PCnet-PCI driver in Solaris? I was pleasantly surprised to find a fair bit of the code I wrote at the end of 1994 is still visible in that driver. Coming back to Solaris engineering after a long absence, at a time with so much new energy and new development as we dramatically expand x86 and x64 support, this is such a rush! Just so I don't start thinking it is as good as it gets, I was fortunate to be able to join the Newboot development team - Newboot was my first customer for the new Solaris ACPI subsystem. My ACPI-team colleague David Chieu quickly developed the ISA-device enumeration code on top of the new interpreter, and we're pleased to have filled-in a key piece of Newboot. I'll be blogging a bit about the relatively few, relatively minor issues I've encountered since integrating ACPI CA into Solaris. In general, ACPI CA is working extremely well - the issues we've seen are generally related to how I've changed the way that Solaris interacts with the system. The biggest change is that we run the system in ACPI-mode now, not legacy mode - but I'll save that for another blog. Cheers!

Posted by danasblog [General] ( June 14, 2005 09:40 AM ) Permalink | Comments[0]

Dtrace: kool-aid worth drinking

So, a few days ago I installed an experimental Solaris kernel build, and my mouse stopped working. In the old days, before dtrace, this would have meant digging around in kernel source, building experimental modules and running the kernel debugger. This time, though, I wrote a few lines of "D" code, kicked-off dtrace and a few minutes later I'd located exactly where the error was occurring. It just took another couple of minutes to check to see if the source file had been recently modified - and I found the bug had just been fixed the day before, I just needed to grab the updated source. Start to finish, it took under 30 minutes to resolve this issue. dtrace is an *amazing* tool.

Posted by danasblog [General] ( May 10, 2005 11:05 AM ) Permalink | Comments[0]