Insider Seti@home info?!

[Escalade]

I found this following discussion quite interesting...


| I can't seem to get my CPU dedication past 77%
| even with just Spy, Driver, Systray and Explorer
| running. Any suggestions, anyone? System
| specs: PII/350 MHz, 128MB RAM, 512kB L2 cache.

That is a software 'governor' put in the 3.03 client to even everyone's
stats out. Those of us in the "I'll buy a new computer when I buy a new
car" SETI group asked for it. The 3.03 client identifies the processor,
figures out what the max percentage would be in order to stick to the
baseline speed (a Pentium 233?) and then starts crunching away.

Really, I'm surprised you're the first to notice it. I figured the people
running quad 1GHz PIII's would be screaming by now...

 

[Assimilator1]

Hmm ,where did you get this from? ,can't you provide a link to that discussion?

Somehow I doubt its true ,everyone would spot that in task managers.
Also the added science to SETI should slow the client enough for their servers to be able to cope.Why would they want to pull a stunt like this?

 

[JWMiddleton]

If that is the case you can run multiple copies and get better results!! We need to get DigWeed to try it on his 1 GHz box. Actually doubt that they have done this, but you never know.

I will PM him!

 

[Robor]

I can't imagine this is true. If it is, there's gotta be a way around it.

Rob

 

[JWMiddleton]

I just downloaded cli 3.0.3 and ran a test on a Cel2-600/902. Wintop showed that the process was using 99.70% CPU consistently. I only ran it for 10 minutes then switched back to version 3.0; thus, I don't know how long it would have taken to process. But, SetiSpy says that 3.0.3 takes 4.11 TeraFLOPs to process a file. Based on a Normal WU I projected the time to be 6h6m on a PIII-933 compared to 4h15m with rev. 3.0. Guess we will find out in a few weeks!

 

[DigWeed]

Actually I have a P3 933 oced up to the max 1100mhz and it take at least 7 hours to complete 1 wu on the seti 3.03 CLI not gui gui time is around the same maybe a 10-20 minute difference unless I am doing something wrong? All I run with it is setispy no queue or anything as i have 24/7 connection and it never failed for the entire week I have been a member that is connecting to the seti servers. I would like to see if someone could provide me with a link to the 3.0 CLI for winnt as I would like to benchmark that on my system and see if it is actually the client or I need some speed tweaks somehow. By the numbers you guys display I should be looking for the cause of my problem because my wu's sucky sucky hehe

 

[networkman]

Well, aside from the value of the science, one issue I really have a problem with it the stats for the WUs themselves! If it's gonna take so much longer to complete a WU under 3.03, how does that jive with the resulting times with 3.00?? From a stats perspective, we're now comparing apples and oranges.. having completed 6,000 WUs with previous clients doesn't mean as much to those people now running 3.03, who are producing WUs with more valid results because of the increased science!! Pursuant to analyzing the data for the same type of science, would it not be prudent to re-distributed all of the work previous to version 3.03, in order to make certain that the same data is looked at?!?

I've been having this nagging thought for some time now, and I'm just now figuring out how to express it. Personally, I'm of a mindset that results from this newest client should be organized into a different S@H project, so that at least then the results mean something similar across the board.

Does any one understand what I'm saying?? :|

 

[DigWeed]

i know exactly what your saying and in blunt terms it fits the term not fair to the new guys! and in the name of science i say yes i would want to look at all that data over again and you know it probaly will you never know I just think something stinks....

 

[DigWeed]

i know exactly what your saying and in blunt terms it fits the term not fair to the new guys! and in the name of science i say yes i would want to look at all that data over again and you know it probaly will you never know I just think something stinks....

 

[Assimilator1]

I also ran CLi v3.03 for a short while & I was getting 98% of cpu time ,so that story just isn't true.He's probably just got some other task hogging cpu time.

Digweed
>>>All I run with it is setispy no queue or anything as i have 24/7 connection and it never failed for the entire week ....<<<<

You've been fortunate so far then ,but you will be kicking yourself when 1 day you can't connect........

NWM

I see where your coming from,
ref the stats I think its just a case of everyones on the same boat ,so what's the difference? .Yes new users will be at a relative disadvantage ,but what could SETI do about it? start all over again? I would think that would take along time ,too much time.
Interesting point you make about V3.03 should crunch ALL WU's again to make sure nothing was missed ,maybe they will? Seeing as all WU's are crunched twice anyway maybe they're saving old WU's for just that reason?.

Anyone got any 'real' inside info on that?

 

[danzigrules]

I thought that they redid all the w/u! By sending them out multiple times to make sure that nothing was missed.
I am most likely wrong about that though.

 

[JWMiddleton]

NWM: At first I agreed with you, but then I realized that we have only had this &quot;benefit&quot; for a relatively short period. It has been the combo of fast CPU's and version 3.0 that has given us an advantage. Six to nine months ago a PIII-600 (512k cache) was considered a hot machine! The 700e CU has only been out a bit more that a year and last year it was very expensive! Now a bunch of us are sitting at 933 MHz, and up, on multiple machines!

Once everyone changes to the new version ALL production will fall. It will be harder to get to the level that you have obtained, but no one will feel that you got there with in unfair manner. We all should be proud of what you have accomplished. It will just take a lot longer to make milestones in the future. We have basically been spoiled over the past few months. We will have to adjust our thinking and accept the change.

If it helps the project with better analysis and helps S@H with bandwidth issue, then it has to be looked at as a positive change. I wonder if we are going to have the same issue in another 6 months with 2 GHz P4's, etc??

 

[Robor]

networkman: You make a good point about the difference between the clients and stats. It is going to be much harder to climb in the rankings now that the WU's are going to take longer. Another way to look at that is those of us who used the earlier clients that completed WU's faster are the same people who've been participating in the SETI project a long time. In other words, if it weren't for those of us who got in early on this project it probably wouldn't have been so successful and we might not be where we are right now.

I have a feeling that they will be looking at the old WU's again. Wouldn't it make more sense to redo an old WU with the new client than redo a WU that the new client already checked once?

Rob

 

[Poof]

Guys - the post about seeing seti not going over 77% of the CPU may possibly be true. If you recall my threads on the VLAR WU problem and what some of us felt was a bug. Well since the SETI@home folks obviously ignored the data we presented to them, the &quot;problem&quot; persists.... Perhaps that is the normal behavior for the CLI, although we never saw it with the GUI, nor did we see it with linux or the Mac.

I did some benches last weekend with the 3.03 CLI (run on WINE with the nt40 file system switch). One of you donated a 0.001 WU to me... and I ran a bench on it. Time was 8:32 hrs on a P3 600@800 (the one in my sig).

Now the key here is that although the reported-out CPU time was 8:32 hrs, the actual &quot;clock&quot; time was about 12 hrs. :Q That is, it took 12 hours from the time the WU processing was started until it completed and uploaded the result.

What I observed happening was that the CPU processing time was diverted to doing something with system resources, which took from about 20-50% of the time (not a consistent 50% like 3.00, but a cycle that went up and down, ie., 50/50, 60/40, 70/30, 80/20, wash, rinse, repeat... the ratio being SETI/system resources). At no time once it got in that state, did the seti-dedicated time go over 80% with that VLAR WU. For other angle ranges, the SETI process stayed at about 99% of the CPU time.

Again, this was my observation on what would be the equivalent of NT 4.0. Previously, I saw this behavior magnified on 9x/ME based on my benches with VLARs. So if the person who was quoted had been running a low angle range (or even a series of them, since they come in batches) with the 3.03 CLI, then yes, that is EXACTLY the behavior...

 

[Assimilator1]

hmm ,darn ,I'll have to keep an eye open for that.

Does the varying cpu time between SETI &amp; the resources show up in a task manager? eg Taskinfo 2000?

Escalade

It would be very helpful if you said where that discussion came from

 

[Poof]

Assimilator1 - I think someone did check it with Taskinfo 2000 and thought they saw it but I never got any clear details about what they saw. I've heard one suggestion that it was the pulse checking routine that was causing this behavior, since that routine does get invoked in the VLAR WUs but not in the VHAR WUs. Thing is, why is this only doing it with the CLI and not the GUI, nor on Linux or Mac clients?

When I watch for the behavior of WINE using *nix's &quot;top&quot; application (which monitors *nix processes), it shows me the the WINE process (which is the SETI process) at 99% normally, with a wineserver process popping in and out at 0.1%. But when that VLAR condition occurs, the WINE process will go from 99% down to 80%, then 75%, then 70%, then 60%, then 50%, with the winserver process correspondingly increasing to make up the rest. It then reverses and starts increasing back up to a max of about 80%, never going any higher. If I plotted it, I bet it would come out with a sine curve.

The effect increases the amount of clock time required for the SETI analysis to complete, sortof akin to running 2 SETI processes simultaneously on a single CPU machine.

There is a fascinating phenomena that was recently discovered by TLC poster alastair b who like Roelof Engelbrecht (SETI Spy author), has been plotting and analyzing WU data. One plot that alistair posted about contains the coolest assed thing I've ever seen, ie., he found a unique pattern had formed in the WU data plots of Teracycles vs angle range. :Q

Anyway, this project gets curiouser and curiouser....

 

[Assimilator1]

Thanks for the info Poof ,I'd be interested to hear more when you have more.
BTW ,remind me what a sine curve is!?

 

[Poof]

LOL Assim1!

Hmmm.... lessee:


_/^\.../^\_
.....\./.....

Or something like that...

[EDIT to make it look something like it's supposed to!!! grrrr]

 

[JWMiddleton]

Assim-1: This is case where a picture is worth 1,000 words. If you have ever seen a picture representing AC current, that is a sine wave. I've seen it many times on an O'scope. Radio waves are also a form of sine wave. When you see picture explaining how computer memory works with what looks like steps; those are refered to as square waves (where +1 is up and -1 is down.)

I give up! Here is a link that will show you: click here.


Poof: is that Grocho Marx?

 

[Assimilator1]

Ah ,radio waves &amp; AC current shape ,now I know what you mean

 

[CurtOien]

I'm not sure if this has anything to do with what you guys are talking about but it seems to me that since I went to 3.03 for SETI, My RC5 has picked up how much gets done when SETI runs. Before, nothing would get done if SETI was running, but now, RC5 has been getting some CPU cycles. It seems like a fair amount like maybe 20% of the cycles at times.

This could be completely wrong but this is what I had been thinking before I had read this thread. I was going to say something but I was not sure that this was what was happening.

 

[MikeyP]

I ran two clients simultaneously, and got about 17 hours for each WU. My other units for 3.3 have ranged between 6.5-9.5 hours. Athlon 700.

 

[Poof]

<< Poof: is that Grocho Marx? >>


LOL JWMiddleton! Gotta work on that ASCII art...

Hey, maybe it'll help if I start hanging out again on /.

 

[JWMiddleton]

You know Curt Oien may have something. Everyone on our SETI TeAm could run RC5 if in fact there are spare cycles to be used. That could be a nice boost to the TeAm! Also need to know more about running two instances of S@H. If one runs in 9.5 hrs and 2 copies run in 17 hrs then that would help the new crappy production times.

Hmmm...two copies of S@H or
1 S@H and 1 RC5 wonder what DanC would say?

 

[Assimilator1]

Curt Oien

Interesting ,does the shared cpu time show up in a task manager?
Does changing SETI's priority help?