Cooling, Undervolting, and Greening Gimli

So here's the best answer so far. I don't want to make an unsightly hole in my computer case's side wall (see prior post), but I need to get air flow under control for best cooling my Core i7 920 chip. The solution is to use some 4-inch plastic air hose with wire reinforcing to direct supply air from one of the two front air inlet fans (lower right on photo) to the CPU cooler fan. This minimizes the "blow back" of hot air from the CPU cooler outlet to the cooler inlet. This solution still works well when the case is buttoned up. We don't have to worry about the acoustic and radio frequency noise that would leak out through any new holes.

The hose is available at hardware stores for clothes dryer connections.

So, the airflow and CPU cooling is about as good as it is going to get without moving to a more exotic chip cooler scheme. The next step toward controlling operating temperature is to minimize CPU power consumption. My philosophy is to keep the specified CPU performance (i.e., clock rate), but to reduce operating voltage to a safe minimum. This is called "undervolting".

(Many computer tinkerers want to get the highest performance possible from their chips, e.g., by "overclocking". This generally requires operating at higher voltage which in turn means more power dissipation, bigger and noisier cooling systems, etc.)

I devised a simple Python program that loads all 8 "processors" (4 cores x 2 hyperthreads/core) for a specific interval and measures the temperature rise. This is a good test of the cooling system and the power level of the CPU (as a function of core Voltage, clock rate, etc.) It is not meant to be a typical application program, just a source of heat. (Actually, it is such a trivial program -- a tight loop -- that it causes more power drain than typical real programs.)

The standard CPU core Voltage (Vcore) is 1.29375 V. Our Gigabyte GA-EX58-UD4P motherboard provides great flexibility in selecting all kinds of CPU parameters, but I am mainly varying Vcore. Running the test program, I observe a final case temperature (Tc) of 65 C and mean junction temperature (Tj) of 75 C. The AC supply power is about 204 W under load, and 98 W at idle.

I tried successively lower Vcore settings. At Vcore = 0.91250 V, the computer would begin the BIOS display at boot, but would fail before it completed. At Vcore = 0.95000 V, it booted partly into Linux, but it failed before getting to the Ubuntu login. At Vcore = 0.97500 V, we had a successful boot. The supply power was 150 W under load, 97 W at idle. Final temperature was Tc = 53 C, Tj = 57 C.

It is not clear how stable the system would be at 0.975 V under all conditions (room temperature, computing loads, etc.), so I raised the voltage a couple of steps to Vc = 1.01250 V. At this voltage, we ended with Tc = 53 C and Tj = 58 C. AC power under load was 155 W; at idle, 97 W.

From Intel's data, it is not clear what the ultimate "safe" operating temperature of the i7 920 chip is. As we said earlier, it comes down to a subjective judgement about how much stress is acceptable. Less is always better from the standpoint of system stability and longevity. Some of Intel's charts suggest that Tc = 68 C is an acceptable maximum. In that case, our operating maximum of 53 C should be fine. (Note that we must allow for ambient temperature changes. Our measurements here are at Tamb ~ 20 C, but our ambient could rise to ~ 30 C on a hot day.)

For now, the engineering is "done", and we can go back to BOINC running all day without fear. We have also trimmed about 25% from our power bill.

Gimli Explorations (Core i7 Thermal)

My earlier posting introduced Gimli, our new Intel Core i7 920 system. Time for some progress reports. My main focus has been operating with a heavy scientific computing load -- running under the BOINC framework for distributed computing on large-scale scientific problems, such as the Search for Extraterrestrial Intelligence (SETI), protein folding, etc.

The system is based on a Gigabyte EX58-UD4P motherboard in an Antec "Solo" case:

The CPU cooler is the stock Intel system. The photo shows the bottom of the cooler with the central copper disk, which after coating with heat sink compound presses down on the top of the CPU. Under the heat sink is a fan that draws air down (up in the photo) from "cool" the case interior, past the fins, and then radially outward to be drawn away by the case's nearby exhaust fan.


Normally, the Antec case is covered on the side by a solid removable panel, which works very well for noise control and appearance. However, Intel's Chassis Air Guide manual suggests a different "solution" for good thermal performance. They propose a duct leading from ambient air external to the case down to the top of the CPU cooler. This will prevent recirculation of warm air within the case that will tend to heat the CPU unnecessarily. So, I did experiments under 3 conditions: (1) cased closed with normal side, (2) side removed, and (3) side removed with temporary duct installed. The photo shows the temporary duct in place, made from two 8.5 x 11 inch sheets of paper and Scotch tape. (I suppose I should have used duct tape...)


The computing load ranged from zero (Ubuntu Linux 9.04 idling) drawing 100 W AC power, to full load (8 parallel threads of SETIathome jobs) drawing about 200 W AC. The LCD display is not included in power measurements, and I am running at stock clock speeds -- no overclocking.

There are 9 temperature values reported by the CPU: one junction temperature for each hyperthread (two per CPU core) and one temperature for the CPU case (below the chip). There is considerable discussion about how to treat these values. For example see the post at Tom's Hardware site. There are calibration questions, and there are questions about what actual CPU temperatures should be permitted. The Core i7 has several self-protection features that will control power dissipation if temperatures are allowed to get "too high". Unfortunately, there is apparently no published maximum temperature spec for the chip. In any case, the maximum we want to tolerate is subjective. Lower temperatures generally mean more operating stability and longer lifetimes.

It's not clear if there is any meaning to any difference between the two temperature readings associated with each physical core -- or even between the different cores, assuming that the Linux scheduler distributes the computing work equally among cores. These junction temperatures typically vary up to +/- 2 C among the group. I will report only the approximate median Tj of the 8 junction readings. I also report the case temperature Tc.

The numbers given are summaries of a number of readings. I don't claim great statistical power -- only a rough comparison of the options. Room temperature ~ 74 F.

Antec side panel on
Sytem Idling
Tj = 43 C; Tc = 41 C
System 75% load (6 jobs)
Tj = 72 C; Tc = 63 C
System 100% load (8 jobs)
Tj = 75 C; Tc = 63 C

Antec side panel off
System 100% load
Tj = 72 C; Tc = 62 C

Antec side panel off; paper duct installed
System 100% load
Tj = 67 C; Tc = 62 C

Moral: Intel's ducting scheme really does make a substantial improvement. A 5 - 8 C temperature reduction is significant, but in the absence of hard temperature specifications, it is hard to say how great a benefit to system stability and lifetime will result.

Another moral is that if you buy a packaged Core i7 system from a mainstream manufacture, you are likely to get an "engineered" thermal system that is better than what a do-it-yourselfer is likely to concoct with generic motherboards and cases. Of course, it's less fun and more expensive to buy complete systems!

The cooling improvement is specific to Intel's standard CPU cooler. There are numerous more exotic chip coolers on the market, which may not require a ducting system.

My options seem to be:

• Accept up to 75 C junction temperatures when running full loads.
• Cap operation at 50 - 75% of full load.
• Cut a hole in the Antec side panel and install a permanent duct.
• Check out a different CPU cooler.
  

Note also that the BOINC / SETI CPU load is only one particular application. It is not hard to make programs with more or less power dissipation, but this test does seem to be representative.

A question from Iran

Say hello to Gimli

Gimli is a new home-built system comprising an Intel Core i7 CPU, 6 GB RAM, 1 TB HD, and GeForce 9500 graphics. It runs 64 bit versions of Ubuntu 9.04 and Windows 7. The chip provides 4 CPU cores with hyper-threading, or 8 concurrent threads of execution, more or less.

I am hoping to start to understand CUDA programming and otherwise to see what kinds of DSP we can do. Oh, and maybe load a game or two.

A New Featurette

I incorporated "share this" into this blog. Now you can repost all the wisdom here to Facebook or what-have-you! See the option at the bottom of each posting.

Do Not Read!

The latest technology toy here (and supposed moneysaver) is the Amazon Kindle 2. I unsubscribed from my dead-tree New York Times and signed up for the Kindle on-line NYT. I calculate that after 18 months or so, the savings will have paid for the Kindle. We'll see about that.

It has been an interesting experience reading the newspaper as if it was a book. I find I tend to get wrapped up in long stories much more easily than before, and I now appreciate some of the fine writing skills of those ink-stained wretches at the Gray Lady. If I let myself, I can spend hours more every day with the paper.

On the other hand, it would be nice if the Times were a little more careful and intentional about formatting itself for the Kindle. Navigation is not too hard, but many of the cues about which articles are more significant than others is lost. Letters to the editor loom as large at first blush as feature articles. (There is no word count provided, as there is for Newsweek.)

Today's bit of strangeness appears above. An obituary is published under the title "Do Not Publish". If that came out in the print edition, there would be hell to pay, but maybe quality control for the Kindle is an afterthought. I checked the online web edition, which has the correct title.

Why good QSOs go bad (propagation)

KB6NU has an interesting propagation question about why good QSO's go to pot.

This evening, just after dark, I called CQ on 40m CW. On the second call, VE3QO, in Ottawa, ON replied to my call. On that first transmission, he was at least 10 dB over S9... Unfortunately, on the next go-around, VE3QO was a lot weaker, and on his third transmission he was nearly unreadable.

...

My question is what propagation mechanism is causing this behavior? Is it perhaps the combining of the F1 and F2 layers? If that’s the case, why is the calling station so unusually strong on the first transmission?

OK, I'll bite. I've had similar experiences, not always at sunset. I call CQ -- or answer a CQ -- and signal reports are 59+. After a few minutes, we're both down in the mud. On one level, that's a selection effect. We are more likely to call or be called if the propagation is very good -- we answer the strong stations first. Statistically, you'd expect to start talking to people at a prop. maximum, and things will naturally get worse from there, sometimes dramatically.

My hand-waving "scientific" explanation for both the sunset ("gray-line") and the variability issues comes down to thinking of the ionosphere as a time- and spatially variable propagation medium. We get strong skip when there are (a) strong gradients (acting as mirrors) in ionospheric conductivity (as around sunrise/sunset) and (b) when the gradients have a favorable geometry for a given path. E.g., they tend to lie on ellipsoids that have the two stations as foci, and the ellipsoids are arranged (in Fresnel zones) so that multiple paths arrive in phase.

So it's no surprise that we see a range of signal strengths. Why do we get such a range? We get momentary deep nulls when signals arrive out of phase and cancel. Maybe the question is why do we see the opposite - short periods of very strong propagation? Again, with hand waving, it is reminiscent of the "cusps" you see, for example, on the bottom of a sunlit swimming pool, as the more or less random waves act as lenses that focus light in very bright lines.

STS-119 seen from CT, or what?

This is a long posting about what was and what might have been. It's about how hard it is to get data without preparation and without "pro" tools, but how you can dig something even out of poor results.

This is about the NASA STS-119 Space Shuttle launch that occurred at 7:43 pm EDT on the evening of March 15, 2009. This was billed as an unusual opportunity, because it was to take place just as the sky was darkening over the East Coast. The trajectory was to send it into an orbit with 51 degree inclination, to catch the International Space Station. That takes it more or less parallel to the Eastern Seaboard of the US. Would it be visible at Branford, CT? (lat 41d 15m 09s, long 72d 50m 02s W)

Earlier in the day, I heard about the launch and the viewing opportunity. I set an alarm to remind myself, but otherwise did not think to prepare.

The alarm rang, I looked out the window and surprisingly the sky was mostly clear. There was some haze that obscured the stars below about 20-30 degrees elevation, over Long Island Sound. (Fortunately, from my back yard I have a clear view to the south, east, and north over water.)

I connected to NASA TV with my PC using Livestation, and watched the actual liftoff starting. Without much thought, I picked up my new little video camera (a cheap Polaroid DVC-00725F, bought from Woot.com), dimmed my living room lights, and headed out into the cold and almost dark yard.

Without any detailed trajectory analysis that would tell me the apparent track of the Shuttle as it was to come by Connecticut, I stood watching the southern sky for things that move. (It doesn't help that we are under the main approach to Hartford/Springfield airport from the south, but aircraft are generally easy to identify by their flashing lights, etc.)

I fiddled with the vidicam a bit, not ever having tried it for "astrovideography". I thought I knew how to make it work, although there are quite a few problems for this application. It's handheld, of course. It has an LCD screen which is annoyingly bright and very hard to use to point at "stellar" objects. The autofocus feature (no manual setting) makes it likely to go out of focus if you try to zoom. The zoom magnification is not calibrated and so on. I discovered later that the camera has a "night" mode, but there is no documentation of what that actually does. In any case, I did not use it.

A crucial missing piece of equipment, as it turned out, was a timekeeping device, or so I thought at the time. In fact, I now realize the camera has a clock that I am able to calibrate as being about 42 seconds slow.

I noticed something coming north toward me, so I began an HD recording. From the file date and time, I find that it started at 7:52:28 pm EDT. The launch time was 7:43 pm, so our video starts 9 minutes after launch. According to the CBS trajectory prediction, the Shuttle was at about 1,000 miles downrange from Cape Canaveral at that point, about 65 miles altitude, traveling at over 17,000 mph. Google Earth tells me that the distance from Canaveral to Branford, CT is very close to 1,000 miles as the crow flies. That fits, but I have no way to know what track across the sky I should have expected.

Visual

Was it STS-119? Before considering the video, what did I see as a visual observer? It was very fast -- about 2 degrees/sec at closest approach (estimated from video). That's much faster than commercial air traffic at altitude. It was completely silent, and it was brightest as it was moving away from me to the northeast, perhaps comparable to Sirius. It had an unusual extended appearance (to the eye) as it moved past, and it appeared as a very close visual binary object (i.e., double) with perhaps a few arc minutes separation as it moved away. There was no flashing light, as normally seen on commercial aircraft. At the time, I thought it probably was not the Space Shuttle, but now I am not sure what it was.

Sky

The sky at the time was graphed by Stellarium -- extremely helpful for celestial navigation! Here is a partial snapshot of the theoretical sky:



Conveniently, the bright stars Sirius (m -1.45) and Procyon (m 0.4) are separated by about 25 degrees on the sky and were near the track of the "object", providing good calibration points.

Video

The full 42 sec. video is available for download at my aa6e.net site. (10 MB AVI format) I learned more than I wanted about video processing in Linux to get this video into a usable state. It needed to have its brightness and contrast adjusted to bring up the faint images that are just above the noise level. (An upload to YouTube was a failure, since their processing degrades the quality, even in "HD" mode.) Note that your computer may or may not have the power to play this video at full speed and resolution. It is 30 fps, 1280 x 720 pixels, mpeg4 encoded. (My Athlon XP 2000+ is barely able to manage.)

Because of the limitations of the recording, you may wonder if there's anything useful there at all. But there is!

I constructed a timeline for the video:

Start (07:52:28 pm EDT +/- 1 sec)

+ 00 s: Sirius in view
+ 11 s: Object appears faintly about 150 pixels away from Sirius on a vector about 50 degrees clockwise from "vertical". Diffuse with reddish hue.
+ 15 s: Object passes "above" Sirius (vector 0 degrees).
+ 17 s: Sirius passes out of frame, but object continues
+ 21 s: Procyon enters frame (upper left)
+ 23 s: Object passes out of frame. Some structure (non stellar)
+ 35 s: Procyon leaves frame (right)
+ 38 s: Object re-enters frame, binary point source, bottom center
+ 42 s: Recording ends

Closest approach (highest elevation) would have been about 07:52:51.

If you are not able to view the video, I can present portions of a few of the final frames showing the double object.

Analysis

This is pretty crummy data, acquired impromptu with a marginal recording device. Still, given the stellar calibrations and the timing, some information can be extracted.

First, how fast was the object moving? Tracking it as it moved from the neighborhood of Sirius to Procyon, it was moving at roughly 2 degrees/second. If the range is 100 miles, the linear velocity would be over 12,600 mph, depending on the projection angle. If it were an aircraft at 5 miles range, it would be traveling over 630 mph.

What about the double structure? The final video frames show a binary separation of about 4 pixels, which corresponds to 0.08 degrees or 4.8 arc minutes -- given a very sketchy idea of the horizontal field of view being 25 degrees. (A guess based on the apparent Sirius - Procyon separation.) The resolution limit of the human eye is said to be about 1 arc minute, and given that the double object was fairly clear, our estimate of 4.8 minutes is not unreasonable.

If the object were at 100 mile range, what would the separation be? I work out 737 feet! From NASA info, the Shuttle wingspan is 78 feet, somewhat more than the separation of the two boosters. However, if the range were 5 miles, the separation would be 36 feet, also large for typical military jets.

We are left with a mystery. The time and angular speed suggest that we were seeing STS-119, although quite possibly it should have passed lower in the east -- in our haze layer. The fact that the object was brighter moving away than moving towards us suggests rocket engines or a military jet (afterburners?), but the separation of the double point image is puzzling -- in either case.

So it was a UFO... at least until or unless we find an error in calculation (it has happened before) or more data come to light. Do readers have any suggestions?

Update: A number of other on-line sighting reports as STS-119 passed "over" Connecticut, but I have still found nothing more quantitative about trajectory or timing. Was the Shuttle flying over land or over the Atlantic? (Early in the launch, it has to be over water for safety, but probably not this far into the flight.) If it was strictly over ocean, it would have had to fly 50 or more miles to the east, which might not be compatible with my observation.

The surprising separation of the "binary" receding view might (with some hand-waving) be explained if the visible light comes from large exhaust plumes rather than the engines themselves. Also, the separation reported above is likely to be an over-estimate, because I measured those frames that showed a clear separation. Many frames are more muddled, but still show an extended image along the same axis. The average apparent separation might be say 2 arc minutes, and it could even be less, if the video zoom factor was larger than estimated.

Kindle Hack Prescience

Yesterday's post foresaw the wonderful things that could happen if someone did some "special research" on the Kindle. Well, today's news (Ars Technica) tells of a hacker who has indeed gained access to the K2's Linux essence via the USB port. The original Kindle was hacked way back in 2007.

I don't expect to do this myself any time soon, but it is fun to watch another digital barrier fall.