of the Work Unit, or basically "How much the Antenna moved" during the
time the WU was being recorded. If the antenna moved a lot during that
particular WU the processing time will be faster. If it was stationary
observing an object, the SETI client has more time to examine that same
source & will do more triplet & pulse searches (which take lots of calculations)
but will not do Gausians searches. The triplet & Pulse searches are also the
reason for the high angle range work units completing faster, since they are
not done at all above a certain point. So in answer to the original question:
If you are using a caching program that looks at the Clients you are running
it can "stack the deck" & send each client the WU's they are best suited
for to save some processing times, as different CLients do perform
slightly differently speed wise on different AR's, though the results are the
same. The caching proxy would simply look at the AR of the WU.
If you look back through your results (If you can that is) you should see
lots of WU's with an AR of 0.417 (the most common) & on a system I have
these tend to complete in 7h57m40s, that's not an average, that is how
long the work units with an AR of 0.417 take on that particular machine.
Actually 3 0.417 ARs took 7h57m40s & a fourth took 7h57m38s, less than
a 2 second variance. Usually I see more of a variance in WU times, maybe
as much as 30 seconds on a single machine, but this is mostly due to
background processes & is not related to the WU itself.
Bill
At 07:40 PM 4/4/01 +0000, you wrote:
I don't believe the SETI client has any capacity to benchmark the system
it's running on, though I can't be certain. I also don't see how the SETI
system could know how long it would take to finish a work unit anyway,
since presumably the input work units haven't been analyzed at all, so the
system has no way to know how "interesting" it is and therefore if any
extra work will need to be done to it.
My guess as to why SETISpy says your faster system spends more FLOPs is
because of its higher MHz rating. All other things being equal (which in
your systems' case they aren't because the two have different bus speeds
and almost certainly different chipsets), processors tend not to scale
perfectly in terms of performance as frequency incresases because there are
always things that the core has to wait for because it's faster than
everything else. Perhaps SETISpy calculates FLOPs in a crude manner that
can't take into account all the real variables, but I'm far from certain on
that- it's just a guess. I don't know enough about SETISpy and SETI@home's
inner workings to say for sure.
Evan
Tom Schoenherr writes:
>
>
>
> I have two computers doing SETI wu's. The slower computer,
> a P II at 350 mhz consistently receives wu's that will take
> about 3 teraflops to complete (plus or minus 15%). The faster
> computer, a P III at 533 mhz consistently recieves wu's
> that will take about 4 teraflops (plus or minus 15%) to
> complete. The teraflop numbers are from SetiSpy.
> Does the SETI server sense the speed of your machine
> before it sends a wu to it?? i.e. if your puter is a slower
> machine, it sends out easier wu's??
> Has anyone else noticed this??
> ==
> Unsubscribe instructions: http://www.talkspace.net/mlists/setiathome.html
> This list sponsored by talkspace.net: building space communities online.
> Mailing list services provided by klx.communications -- www.klx.com
>
==
Unsubscribe instructions: http://www.talkspace.net/mlists/setiathome.html
This list sponsored by talkspace.net: building space communities online.
Mailing list services provided by klx.communications -- www.klx.com
