I use SETI Spy to monitor performance and recently switched to the command line client and noted it upped my speed significantly. However, I got ahold of two work units on my fastest machine that ran REALLY slow! Normally I run around 140 MegaFlops/sec on that machine, but for these two WU, it was down around 90 MegaFlops/sec.
I couldn't believe it, thought something must be wrong with the machine...but after fussing with the computer (reboots, etc.) couldn't find anything wrong. I use the "normal" priority in SETI Driver. Anyway, I let the slow WU's complete, and now, on a new WU, am back up to "normal" speed.
Anybody know what gives? I never noticed dramatically slower WU's with the GUI client. Is this something I should expect occasionally with the command line client?
Asus CUBX, 566 Celeron II OC to 977 MHz., 256 meg RAM CAS 2, Windows ME, SETI Driver 22.214.171.124, 3.03.i386-winnt-cmdline.exe
Yes, the speed per workunit can shift quite dramatically. I recommend you to use SETI Watch to (set SETIDriver to create setilog.csv) and you can track all your WU's on ALL your PCs in your network.
My fastest to slowest units are:
TBird 1G: 5:45 ~ 8:58
Duron 600: 8:17 ~ 10:14
Celeron 563: 11:45 ~ 17:56
P3 600: 12:04 ~ 17:14
As you can see there are big differencies between the units, I don't know why this is. All of these computers are used while crunching SETI this could impact, but not that much.
My fastest unit ever was 8min! This was due to too much space noise (according to Berkely), you still get the WU, but the data will be discarded by Berkley.
You're right! One of my other computers just swallowed one of the sssllllooooowwwww work units... It's struggling just like the first one. The cycles per flop goes down the tube - instead of running in the 6 to 7 range, it blows up into the 11 to 12 range! These work units are all small (3.52 teraflops). I'm gonna have to e-mail Berkley about this and see if they can explain it...
I still wonder why I didn't experience this level of variability with the GUI client?
The Arecibo radio observatory can track stars to a certain
degree, even if it's basically a big hole in the ground. If the telescope is moving more slowly, you get more data from a smaller area of the sky, simply more time on one target. This makes it possible for the pulse finding algorithm to use a larger chunk of the WU data at a time, making it more sensitive to possible pulses received."
Humm... "larger chunk of the WU data at a time"... I wonder if these slow WU's have something to do with this larger data chunk relative to the L2 cache size? My Celeron only has 128k, so it might be more sensitive to that than my Tbird with 256k, where I have yet to experience such a slow down... More time going back and forth to RAM means more cycles the CPU waits for data...which would mean more cycles per flop... makes sense. Although it still doesn't explain why I never saw the slow down on the GUI client.
I found that my K7's (Duron and TBirds) were much faster with the SETI driver proportionally than my Celerons and P3. The Intel CPU gained something like 15-20% by going to SETI Driver, while the K7's gained closer to 50%.
Could it be that the graphical unit benefit Intel more than AMD?
Anyhow the AMD is clearly the better choice for SETI, my Duron 600 is much faster than my P3 600. This could be due to the P3 600 is a notebook and notebooks tend to do clock throttling to avoid heating up the CPU too much. I will try to cool the notebook further with an external fan and see if I can speed it up...
Scout, I think I found out why certain units are very fast and others are slow!
On SETIWatch I checked all my fast units and they all had one thing in common, a very high angle range (5-8), while my very slow units had a very low angle range (0-0.5).