v3.0 WU Time Predictions

Update! - If you want to jump into the recent update on run times you can check it out here.  If you want to see the old stuff....read on!

There are a lot of different factors which go into determining the run times for a particular work unit.  First and foremost is the CPU type and speed that the work unit is run on.  We have already known from the version 2.x clients, that CPU cache size, and memory bandwidth was an important factor for version 2.x.  Even though the version 3 client appears to be more cache friendly than version 2, there still may be some cache dependency with smaller L2 cache CPUs such as the Celeron.  Other factors which may affect run times include the type of FPU the CPU has, and also how "dedicated" the system is to running the SETI clients.  Of course, if you use your system for CPU intensive tasks, your SETI client performance will be affected. 

This article is not meant to be a be all and end all guide for determining work unit times across all computer systems and CPUs.  Instead it is more of an early survey on my two specific computers here at home.  Benchmarking of specific work units on many different CPU types and speeds are needed to compile a database of information, before general trends on CPU performance can be determined.  Some of the information supplied here may be used to relate to a system with similar configurations to mine, but because each person's system setup may be different, the findings here may not match the results from those other systems.

The Math
The equations used and information about the SETI client comes from the work of both Roelof Engelbrecht and Lawrence Kirby.  Lawrence made measurements on the SETI client to determine the amount of calculations the client produces based on the work unit's angle ranges.  Roelof took that information, and developed equations that specifically relates the number of FLOPs (Floating Point OPerations) that are performed on a work unit, based on the angle range.  These equations are shown here (The equations have been changed to reflect TeraFLOPs instead of FLOPs):

Angle Range (AR)	TeraFLOPs
AR < 0.2255	TeraFLOPs = 2.40*Exp(0.31*AR)
0.2255 <= AR <= 1.1274	TeraFLOPs = 2.34*AR^(-0.225)
AR > 1.1274	TeraFLOPs = 2.26*AR^(-0.0169)

The graph above is what you get when you plot the angle range vs TeraFLOPs in a work unit.  The big drop off in TeraFLOPs is due to the transition between equations at 0.2255 angle range.  TeraFLOPs are the total amount of calculations needed to complete a work unit.  Because of this, the run times for a work unit should actually mirror the number of TeraFLOPs for that work unit.  Below is a plot of completed work unit times versus the angle range, and the above TeraFLOP graph is superimposed upon the data  (arbitrary fitting by hand).

As you can see, the run times are quite variable.  This is most likely due to the machine these work units were run on (the machine I am writing this on) is used for a variety of different things.  The SETI client is usually running in the background while I am doing various tasks.  Some CPU intensive applications such as pulling the team stats and preparing them daily, can lead to large variations in run times.  But the trends are still there...and they seem to follow the trends in the amount of TeraFLOPs across different angle ranges.

Luckily, there is a way to relate the SETI work unit run times to the amount of TeraFLOPs needed to complete those work units.  I know you want to see this, so here it goes:

T_opt = 278(TeraFLOPs * (CpF/MHz)

T_opt = Optimal WU procssing time (hours)
CpF = Cycles per FLOP
MHz = Processor Speed in MHz

If you use SetiSpy, when a work unit is completed, one can get three of the 4 variables in the equation above.  The SetiSpy log will give you the T_opt (in this case it is the work unit completion time), the MHz (ok you know what your CPU is running at dont you?), and the number of TeraFLOPs of the work unit (based on the equations shown earlier).  The only thing left is the CpF variable.  CpF is the "processing efficiency number".  This valuse tells yu how many processor cycles are needed to calculate one Floating Point OPeration (FLOP).  CpF is dependent on a variety of different things, and some of them are outlined on Roelof's SetiSpy page. But ok...we're talking about one system here right?  Lets do a little trick and calculate the CpF based on some work units that were already run on the system.  Just arrange the last equation above to get:

CpF = (T_opt x Mhz) / (278 x TeraFLOPs)

Predicting WU Times
You can use one, or several different work units to get the CpF.....and take an average.  This will give you the average processing efficiency of your system.  Using the data from the graph above (the green circled data) the average CpF for those work units turns out to be 5.76.  Now we can predict the run times of the work units on this system.  The T_opt and the TeraFLOP/angle range equations can be combined, to now give a relationship between the Topt and angle ranges (ok we will get three different equations):

 Now lets plot this estimated work unit time vs. angle range and see how it compares to the data collected already

Not bad eh?  Well I guess there are some caveats to this equation....and it has to do with the variability of the work unit times.  If you notice, there is about a 45 minute span of work unit times over work units at the same angle range (angle ranges ~0.4).  This is probably due to differing activities going on while the work units were processing. 

Version 3.0 GUI versus CLI
The most popular client for the SETI@Home project was the Windows GUI version, but a version that grew in popularity was the Command Line Interface (CLI) version.  The CLI version did not have the overhead associated with the graphical version, and with the version 2.x clients it ran a work unit faster, than the GUI did.  This version was popular because of the speed, and also because it leant itself to scripting on different types of operating systems. 

The CLI for version 3.0 was release a day or so ago and I have switched processing over on two of my machines to the CLI.  I do not have that much processing time on the CLI yet, but I do have some results and can also do the above predictions on the CLI.  The following two graphs are plots of the actual work unit times for two of my machines, and the estimated run times derived from the above equations.

Note!  The CpF for the PIII CLI above is actually wrong, it should read 4.95, instead of the 5.30 listed in the graph above.  Also the CpF for the Cel GUI below is incorrect....instead of 4.95 below it should read 5.30  (I got them backwards :P )

The first thing to notice with the switch to the CLI is that there is an immediate decrease in run times.  This is most likely due to the stripped down version of the client.  The CPU doesn't have to worry about any GUI overhead, and there will be no calculations needed to draw the GUI, and any of the associated graphics.  This leaves the CPU more time to do some crunching.  Not surprisingly, the CpF for the processors are a tad bit lower, but honestly, it didn't really drop that much (0.46 difference for the PIII , and 0.3 for the Celeron).  The run times for the Celeron, even with the GUI version do not have as much variation as with the PIII.  This is mainly due to the Celeron machine being a dedicated SetiQueue server and SETI cruncher.  That computer is not used for anything else right now.  Therefore the times are not as variable.

The last thing to take a look at is the times for large angle ranges ( > 1.1274).  Granted I don't have that many work units completed for large angle ranges, but with the three work units done, there does seem to be a trend going on.  It seems that the work units with large angle ranges have run times that are significantly lower than the "predicted" work unit times from the line plots.  I am wondering if the calculations that Lawrence made, or the equations that Roelof developed, may be inaccurate at large angle ranges.  But I do want to say, that three data points on three different graphs are not enough to say that these are wrong.  More work units of that type are needed to come up with any kind of conclusion.

Finally
I have pointed out a way that you can try to predict the run times for work units crunched on very different machines.  The most important thing to remember is that the data that I used, and the graphs that I made, may not (probably will not) give accurate estimations for any reader's machines.  Each person would need to do some calculations for their machine at home for a good estimate for them.  It is true that any PIII 650E should have basically the same efficiency as every other PIII 650E, but the actual CpF can depend on the motherboard, operating system and other background tasks being carried out by the computer system.  Hopefully from different benchmarks that will be submitted, that Roelof can come up with a nice a nifty graph like he has on his page for the version 2.x clients comparing the different CPU types and their multiplier settings versus the CpF of that processor.  Once those are determined, that CpF could be plugged into the bottom equations and a general work unit time graph could be made for that CPU.  -zAmboni

Update!  Follow this link here for some updated information about Predicting Version 3.0 Client Run Times!