- I found the setting that preventing booting and locked me out of the BIOS. Twice. If I chose "AHCI" or "Linux AHCI" instead of "IDE" for the SATA interface -- that which talks to the various storage devices, including the optical drive, hard drive, and SSD -- I got my unbootable lockout. So, having had to open the case and reset a jumper twice to get back to defaults, I know to avoid these! (Theoretically they should work. Theoretically.)
- The memory (RAM) was rated at 1.8-1.9 volts. The motherboard auto-chose 1.9 volts. I decided to manually set it to 1.8 volts, and it still works fine, even under the stress test. The idle power consumption edged down from 30 watts to 29 watts.
- It looks like the CPU temperature reporting isn't fully locked at 42°C, but rather won't report anything less than that. During some of the stress tests I saw brief flickers up to 43°C, leading me to believe that the sensors are alive. This summer, when the room temperatures are 5°-6°C higher than now, the sensors are more likely to wake up during the stress tests.
- I've been slowly experimenting with overclocking -- running the CPU and memory at faster than the rated speeds. The bog-standard default for juno's equipment is 2.93GHz for the CPU, and 800MHz for the RAM. Gradual bumps in speed have been followed by stress testing, so that I know sooner rather than later that it's gone too far. By now, juno is up to 3.16 GHz / 864 MHz. I've left the CPU and RAM "linked" -- overclocking in tandem. If I care to, I can unlink them, so that, for instance, I could continue to bump the CPU speed without taking the memory further than it can go. That juno can accomplish this with the -.10v undervolt of the CPU and the 1.8v setting on the RAM shows how some parts are binned by demand rather than quality. That is, my CPU may be a perfectly good 3.06 GHz or better part, but Intel needed more of the less expensive 2.93 GHz parts to sell, and fixed it as such. In any case, I plan to be conservative, and back off a couple of steps when either 1) the stress test starts to throw errors, or 2) the power consumption starts to climb more than a watt or two.
- I may also experiment in future with the power consumption response to deliberately underclocking the system.
Wednesday, March 17, 2010
Further Education with juno
Now that I've been working with juno for a few weeks, I have a few updates.
Sunday, March 7, 2010
The aconites are blooming
As the snows begin to melt -- they aren't all gone yet, oh no -- the winter aconites along our front walk begin to bloom.
They our reliable first flowers of spring, and a very welcome sight they are. Winter is drawing to a close with the colorful promises our aconites are making. Here's a closeup.
Thank you, guys! Thank you for enduring the frosty mornings and for saying hello.
Friday, March 5, 2010
Assembling Juno: Installing and Results
With the first power-on, juno responded as hoped: the BIOS identified all the peripherals correctly, and then noted that no device contained any operating system to boot. I did a restart and went into the BIOS to change several settings (time, splash screen, boot order, etc.) and rebooted with a CD. Or rather, I tried to reboot with a CD. Even though I tried several bootable CDs, juno refused to even try to boot from them. It was as if juno would boot only from the first device and failed to check the others. Time to go into the BIOS again. But wait ... the system no longer responded to the DEL key. I couldn't get into the BIOS, even with several attempts! Eventually I had to switch a jumper to reset the motherboard to its factory default settings, and then, as if having enjoyed the attention, juno has never since failed to recognize a bootable device (including a USB memory stick) or to respond to the DEL key. I have changed most of the BIOS parameters again (one at a time), with no ill effect. Sometimes I think computers must go through a learning process when they first wake up or move to a new environment, and exhibit behaviors that disappear after a single baffling appearance.
The first job was to properly set up the SSD (solid state, or flash memory, drive). Including this part was one of the two less conservative items in juno's constitution. SSDs are relatively new, and early adopters (the last 18 months) have seen drives that slowed down over time, turned into expensive paperweights after applying a manufacturer's upgrade, and so forth. By now I hoped that the worst problems had been solved (or identified) by the truly early adopters. Because these devices, although blazingly fast compared to spinning platter hard drives, are very expensive, I stuck to a 40GB 'value' model by Intel (the writes are much slower than the reads, although still faster than a hard drive). I had to create a bootable CD from an image downloaded from the Intel website, in order to upgrade the device's firmware. Fortunately, this went without a hitch. Then I booted Ubuntu from a memory stick, and manually partitioned the SSD, not leaving that to the automated install. It gets very technical, but it's a good idea to align the partition with the SSD erase-size boundaries, and where possible, make file systems in those partitions with tweaks that also are driven by the erase block size. I hope that the next time I build a computer the SSD quirks will either be fixed, or compensated for by the operating system.
Then the Ubuntu install began. Here is the second of my two "leaps" -- I was installing 64-bit Ubuntu. Microprocessors began to have 32-bit capability in the mid-1980s, and 32-bit addresses meant that they, and programs that ran on them, could theoretically recognize up to 4 gigabytes of RAM. For the last several years processors have had 64-bit capability, although consumer machines typically continued to run with 32-bit operating systems and programs. However, with memory becoming cheaper and cheaper, and programs and data sets becoming larger and larger, 4 gigabytes of RAM could be a limitation. Also, for some tasks the 64-bit versions of the same program can be faster than the 32-bit. I decided to take the plunge and install the 64-bit version of Ubuntu with 4 GB of RAM in juno. For technical reasons that are historical -- PCs just grew that way from their origins in the 1970s -- a 32-bit operating sytem would actually be able to use no more than about 80% of that 4 GB.
The install went smoothly. (One does always need to tweak and individualize things.) I had been most apprehensive about Adobe Flash, because Adobe Flash for 64-bit Linux was available only as an 'alpha' to be downloaded from Adobe's web site. However, so far this has worked flawlessly, beyond my expectations. The other 64-bit issue was that there is no 64-bit version of Google Earth for Linux, at least not yet. Some have gotten the 32-bit version to run on a 64-bit system with some extensive workarounds, but for now I'm content to wait for a real 64-bit version.
At this point I noticed some oddities. The CPU temperature was 42°C, which I thought quite high for idle. Then I discovered that it was always 42°C, regardless of load or CPU speed -- the sensors were stuck. I gather this is a not-common but not-rare fault in some of the Intel processors of this generation. At least I was getting good temperature data from the combined controller and integrated graphics chip (nVidia MCP79), and from the 500 GB hard drive, so if things were getting hot I would have some warning.
The next oddity was that the BIOS showed my 1150rpm fans running thousands of RPMs faster than that:
Another sensor issue, fan quirk, or BIOS flaw, no doubt. It doesn't reduce the functionality of the system. I usually adjust the fan speeds several times at the beginning, to reach a balance between low-enough noise and good-enough cooling, and then leave them alone.
Through all this work the blue LEDs for the power button and the disk-activity indicator were bugging me. They were way too bright! So I put a little electrical tape over the disk activity light, blocking most of it, and put a disk of black construction paper in the center of the power button.
Here are a couple of images of at juno at work (taken with flash).
I should point out the small keyboard. It's a "Happy Hacking" keyboard for people, such as me, who don't use the numeric keypad, or have a small desk space, or prefer the traditional UNIX key locations for ESC, CONTROL, and the insidious CAPS LOCK.
Regarding the "faster" goal, I don't have any handy Linux benchmarks. Of course, with the SSD, booting now takes only 31 (plus or minus) seconds from power-on. Of that, 19 seconds are the motherboard waking up devices and taking inventory, and only 12 seconds to boot Linux and put up the login screen. Applications start a lot faster too. Let's just compare the specs. The prior computer, tbroma, had a CPU running at 2.13 GHz with a 667 MHz FSB (memory interface) and DDR2-667 memory. Juno runs at 2.93 GHz with a 1066 MHz FSB and DDR2-800 memory. It's gotta be faster!
What about the final goal, "cooler"? Well, tbroma would draw 42 watts when started up and logged in but not doing anything in particular, a state referred to as "idle". juno draws only 30 watts, measured by the same kill-a-watt meter. When running a CPU stress test program (from the Mersenne Prime search), tbroma, in the days when I could undervolt it, drew 77 watts. In the last year, when undervolting through Ubuntu finally became just too difficult, tbroma reverted to drawing 90 watts. juno sips 63 watts under that test.
And here's one of the best surprises. In tbroma's early days, I tried to get 'sleep' to work. Joan's iMac does 'sleep' very well; just hit a key or move the mouse, and in two or three seconds your desktop is back. I could never get tbroma to wake up properly from a sleep; it always thought it had been rebooted without a proper shutdown. Perhaps it was the motherboard, perhaps it was the operating system of three years ago, but I gave up on it. Guess what? Sleep on juno works, although it is not as slick as the iMac. I must press the power button, and eleven seconds later, after a few messages flash by on the screen, too fast to read, my desktop is back. (Complete with 'network disconnected' and 'network reconnected' notifications.) While asleep, juno draws only 5 watts! Heck, the power drain for just being plugged in while off is 4 watts. I've got juno set to automatically go to sleep after 30 minutes of no activity.
Can I repeat "faster, smaller, cooler" in two or three years? I think so. Smaller will be the biggest challenge, but it can be done, as with this system, which is about the same width and depth but shorter than juno. As infrequently as I use the CD/DVD drive, I could employ an external optical drive on those occasions where I needed one, which would free up space and reduce the cable count. As components get smaller and more capable, where's the limit?!
The first job was to properly set up the SSD (solid state, or flash memory, drive). Including this part was one of the two less conservative items in juno's constitution. SSDs are relatively new, and early adopters (the last 18 months) have seen drives that slowed down over time, turned into expensive paperweights after applying a manufacturer's upgrade, and so forth. By now I hoped that the worst problems had been solved (or identified) by the truly early adopters. Because these devices, although blazingly fast compared to spinning platter hard drives, are very expensive, I stuck to a 40GB 'value' model by Intel (the writes are much slower than the reads, although still faster than a hard drive). I had to create a bootable CD from an image downloaded from the Intel website, in order to upgrade the device's firmware. Fortunately, this went without a hitch. Then I booted Ubuntu from a memory stick, and manually partitioned the SSD, not leaving that to the automated install. It gets very technical, but it's a good idea to align the partition with the SSD erase-size boundaries, and where possible, make file systems in those partitions with tweaks that also are driven by the erase block size. I hope that the next time I build a computer the SSD quirks will either be fixed, or compensated for by the operating system.
Then the Ubuntu install began. Here is the second of my two "leaps" -- I was installing 64-bit Ubuntu. Microprocessors began to have 32-bit capability in the mid-1980s, and 32-bit addresses meant that they, and programs that ran on them, could theoretically recognize up to 4 gigabytes of RAM. For the last several years processors have had 64-bit capability, although consumer machines typically continued to run with 32-bit operating systems and programs. However, with memory becoming cheaper and cheaper, and programs and data sets becoming larger and larger, 4 gigabytes of RAM could be a limitation. Also, for some tasks the 64-bit versions of the same program can be faster than the 32-bit. I decided to take the plunge and install the 64-bit version of Ubuntu with 4 GB of RAM in juno. For technical reasons that are historical -- PCs just grew that way from their origins in the 1970s -- a 32-bit operating sytem would actually be able to use no more than about 80% of that 4 GB.
The install went smoothly. (One does always need to tweak and individualize things.) I had been most apprehensive about Adobe Flash, because Adobe Flash for 64-bit Linux was available only as an 'alpha' to be downloaded from Adobe's web site. However, so far this has worked flawlessly, beyond my expectations. The other 64-bit issue was that there is no 64-bit version of Google Earth for Linux, at least not yet. Some have gotten the 32-bit version to run on a 64-bit system with some extensive workarounds, but for now I'm content to wait for a real 64-bit version.
At this point I noticed some oddities. The CPU temperature was 42°C, which I thought quite high for idle. Then I discovered that it was always 42°C, regardless of load or CPU speed -- the sensors were stuck. I gather this is a not-common but not-rare fault in some of the Intel processors of this generation. At least I was getting good temperature data from the combined controller and integrated graphics chip (nVidia MCP79), and from the 500 GB hard drive, so if things were getting hot I would have some warning.
The next oddity was that the BIOS showed my 1150rpm fans running thousands of RPMs faster than that:
Through all this work the blue LEDs for the power button and the disk-activity indicator were bugging me. They were way too bright! So I put a little electrical tape over the disk activity light, blocking most of it, and put a disk of black construction paper in the center of the power button.
I should point out the small keyboard. It's a "Happy Hacking" keyboard for people, such as me, who don't use the numeric keypad, or have a small desk space, or prefer the traditional UNIX key locations for ESC, CONTROL, and the insidious CAPS LOCK.
Regarding the "faster" goal, I don't have any handy Linux benchmarks. Of course, with the SSD, booting now takes only 31 (plus or minus) seconds from power-on. Of that, 19 seconds are the motherboard waking up devices and taking inventory, and only 12 seconds to boot Linux and put up the login screen. Applications start a lot faster too. Let's just compare the specs. The prior computer, tbroma, had a CPU running at 2.13 GHz with a 667 MHz FSB (memory interface) and DDR2-667 memory. Juno runs at 2.93 GHz with a 1066 MHz FSB and DDR2-800 memory. It's gotta be faster!
What about the final goal, "cooler"? Well, tbroma would draw 42 watts when started up and logged in but not doing anything in particular, a state referred to as "idle". juno draws only 30 watts, measured by the same kill-a-watt meter. When running a CPU stress test program (from the Mersenne Prime search), tbroma, in the days when I could undervolt it, drew 77 watts. In the last year, when undervolting through Ubuntu finally became just too difficult, tbroma reverted to drawing 90 watts. juno sips 63 watts under that test.
And here's one of the best surprises. In tbroma's early days, I tried to get 'sleep' to work. Joan's iMac does 'sleep' very well; just hit a key or move the mouse, and in two or three seconds your desktop is back. I could never get tbroma to wake up properly from a sleep; it always thought it had been rebooted without a proper shutdown. Perhaps it was the motherboard, perhaps it was the operating system of three years ago, but I gave up on it. Guess what? Sleep on juno works, although it is not as slick as the iMac. I must press the power button, and eleven seconds later, after a few messages flash by on the screen, too fast to read, my desktop is back. (Complete with 'network disconnected' and 'network reconnected' notifications.) While asleep, juno draws only 5 watts! Heck, the power drain for just being plugged in while off is 4 watts. I've got juno set to automatically go to sleep after 30 minutes of no activity.
Can I repeat "faster, smaller, cooler" in two or three years? I think so. Smaller will be the biggest challenge, but it can be done, as with this system, which is about the same width and depth but shorter than juno. As infrequently as I use the CD/DVD drive, I could employ an external optical drive on those occasions where I needed one, which would free up space and reduce the cable count. As components get smaller and more capable, where's the limit?!
Thursday, March 4, 2010
The Tale of the Owl and the Squirrel
As unlikely as it seems, a squirrel has been carrying leaves for nesting to the owl tree, stuffing them in a hole several feet below the owls' cavity and perhaps 90° offset. Yesterday the squirrel, confident in his maneuverability, perched on a stubby branch just on the other side of the owl.
The owl knew the squirrel was there, and also knew that she was better at snatching critters on the ground than squirrels in a tree. Eventually she decided to fly off to the nearby pine tree in which she likes to pass the time of day while keeping an eye on the nest. Her departure alarmed the squirrel.
I have no idea what the outcome of this proximity will be. What do you think will be the ending to the tale of the owl and the squirrel?
