has anyone else been experiencing the same thing? i used to get a loaded unit every once in a while, but lately it seems that most are loaded, with quick ones coming every once in a while. or am i just unlucky?
SETI: More LOADED workunits lately?
- Thread starter TuffGuy
- Start date
I've been noticing quite a few "noisy" packets.. I'm finding some of them are getting 30+ spikes.. double-digit Triplets.. all kinds of stuff. I'm not sure if this is good news or bad news..
Hi TuffGuy,
When I first learned about Low Angle-Range(LAR) WU's, I reviewed my log files and found very few of these types. I have six systems at the apartment and there is always at least one LAR crunching at any time. I really wonder if some folkes are throwing these things out and they are being resent? :|
I am going to install NT4.0 on one of the boxes next week and see if that helps.
When I first learned about Low Angle-Range(LAR) WU's, I reviewed my log files and found very few of these types. I have six systems at the apartment and there is always at least one LAR crunching at any time. I really wonder if some folkes are throwing these things out and they are being resent? :|
I am going to install NT4.0 on one of the boxes next week and see if that helps.
I think running NT 4.0 should help a lot. I'm currently trying to figure out how to send only low-angle WU's to my P133 (it has the 2.04 GUI running), but I haven't figured out an easy way to do that yet.
I've found that they seem to come in groups. My work fleet has 29 ships so I download about 80 WU with SetiQ per day. It seems that when I download I get either a bunch of easy WU's or a bunch of loaded WU's. It all balances out I guess.
Rob
Rob
Right now with 3.0, Linux seems to process the very low angle range WUs faster than the windoze 3.0 CLI for all windoze platforms. If you don't have Linux, then 2K/NT would be a little better than 95/98/ME for just those type of WUs. Technically, if the 3.0 CLI wasn't broken, the very low and very high angle range WUs would run FASTER than the middies. But with this current CLI, the very lows run SLOWER than the mids on all windoze platforms, with 9x/ME being the worst.
What I found is happening is that somewhere during the processing of the WU (I think around 1/3 of the way through), the client suddenly begins to use about 50% of the CPU's processing time to mess with system resources, which inturn only allows the 50% that remains, to actually process the WU. Once this condition goes into place, it seems to stay that way throughout the remainder of the WU processing. This means that the actual clock time to get the WU's result uploaded increases significantly, although the CPU time devoted to actual WU processing would be reported as being the same.
For example, if the avg. CPU time to do a low angle takes say 5.5 hrs, then rather than processing for 5.5 hrs of clock time and then uploading, it's taking almost 8-9 hours before the WU is finally completed (even though the reported time for processing is still 5.5 hrs)! What the heck the windoze client is doing with the system resources, who knows! I haven't had chance to load up TaskInfo 2000 to really check it but I have confirmed this behavior when running the CLI via WINE, with both the nt40 file system and win95 file system options (using top to determine what was going on)....
Sigh... they need to recall that 3.0 CLI (and probably all the rest of them)...
What I found is happening is that somewhere during the processing of the WU (I think around 1/3 of the way through), the client suddenly begins to use about 50% of the CPU's processing time to mess with system resources, which inturn only allows the 50% that remains, to actually process the WU. Once this condition goes into place, it seems to stay that way throughout the remainder of the WU processing. This means that the actual clock time to get the WU's result uploaded increases significantly, although the CPU time devoted to actual WU processing would be reported as being the same.
For example, if the avg. CPU time to do a low angle takes say 5.5 hrs, then rather than processing for 5.5 hrs of clock time and then uploading, it's taking almost 8-9 hours before the WU is finally completed (even though the reported time for processing is still 5.5 hrs)! What the heck the windoze client is doing with the system resources, who knows! I haven't had chance to load up TaskInfo 2000 to really check it but I have confirmed this behavior when running the CLI via WINE, with both the nt40 file system and win95 file system options (using top to determine what was going on)....
Sigh... they need to recall that 3.0 CLI (and probably all the rest of them)...
Assimilator1
Elite Member
- Nov 4, 1999
- 24,165
- 524
- 126
Poof
I have Taskinfo2000 .I'm running V3.0CLi on Win95c
What should I look for when running a long WU?
I have Taskinfo2000 .I'm running V3.0CLi on Win95c
What should I look for when running a long WU?
actually, from what i've seen observed during loaded units, the speed (Mflops) drops by more than half, but taskinfo still shows that seti@home is using more than 98% of the cpu. also, triplets seem to be the x-factor. the more there are, the longer it takes to process the unit.
Fardringle
Diamond Member
- Oct 23, 2000
- 9,200
- 765
- 126
I had a unit yesterday with 181 spikes, 57 triplets and 28 gaussians... I don't remember the location in the sky, though...I'll have to look it up when I get home tonight.
I don't remember the location in the sky, though...I'll have to look it up when I get home tonight. Tuffguy - that's interesting to know, ie., triplets.
The problem I'm talking about with 9x/ME with the 3.0 CLI is what happens when it processes a very low angle range WU (ie., AR < 0.1) only. Generally all the clients will take a little longer to do "loaded" (lots of spikes, pulses, triplets, gaussians) WUs, but interestingly enough, we have data that shows WU times not greater than 1% diff between each other on the same machine, when you look at all WUs processed with the same angle range, despite the amount of data in them (this is based on a dedicated cruncher... your mileage may vary on machines you use for other stuff).
There is a behavior that is observed with the 3.0 CLI on 9x/ME where the actual CpF drops in half and the rest of the CPU time gets devoted to putzing around with system resources. Neither the Linux 3.0 client nor the Mac 3.0 client with the very same WU, exhibits this behavior and in fact, both those platforms run the VLARs faster than 9x/ME/NT/2K. Loaded WUs that have angle ranges in the mids (eg., 0.4xx) or highs, (>1) don't exhibit that problem either, with VHARs usually processing the fastest. Thing is, once that seti process drops to 50%, it stays that way for the rest of the WU processing...
Assimilator1 & tuffguy - what you'd need to do is somehow get a WU with a really low angle range WU (like 0.016 or something - not that I would want to wish that on anyone...) run it, and about 1/3rd of the way through, check taskinfo to see what might be going on. From the runs I've done, that's around the time I speculate that this behavior starts manifesting itself (eg. having benched a 0.014 on a P3 800 recently and finding after a little over 5 hrs, the WU was only 37% complete! :disgust. If the behavior pans out (and I know others have confirmed it), I would expect you to see the seti executable only running at around 50% of the CPU rather than 99% or whatever. The thing to look for is what other little processes might be taking up the remaining 50%.
Again, this is most pronounced in 9x/ME. NT/2K don't do it to such a degree...
The problem I'm talking about with 9x/ME with the 3.0 CLI is what happens when it processes a very low angle range WU (ie., AR < 0.1) only. Generally all the clients will take a little longer to do "loaded" (lots of spikes, pulses, triplets, gaussians) WUs, but interestingly enough, we have data that shows WU times not greater than 1% diff between each other on the same machine, when you look at all WUs processed with the same angle range, despite the amount of data in them (this is based on a dedicated cruncher... your mileage may vary on machines you use for other stuff).
There is a behavior that is observed with the 3.0 CLI on 9x/ME where the actual CpF drops in half and the rest of the CPU time gets devoted to putzing around with system resources. Neither the Linux 3.0 client nor the Mac 3.0 client with the very same WU, exhibits this behavior and in fact, both those platforms run the VLARs faster than 9x/ME/NT/2K. Loaded WUs that have angle ranges in the mids (eg., 0.4xx) or highs, (>1) don't exhibit that problem either, with VHARs usually processing the fastest. Thing is, once that seti process drops to 50%, it stays that way for the rest of the WU processing...
Assimilator1 & tuffguy - what you'd need to do is somehow get a WU with a really low angle range WU (like 0.016 or something - not that I would want to wish that on anyone...
) run it, and about 1/3rd of the way through, check taskinfo to see what might be going on. From the runs I've done, that's around the time I speculate that this behavior starts manifesting itself (eg. having benched a 0.014 on a P3 800 recently and finding after a little over 5 hrs, the WU was only 37% complete! :disgust. If the behavior pans out (and I know others have confirmed it), I would expect you to see the seti executable only running at around 50% of the CPU rather than 99% or whatever. The thing to look for is what other little processes might be taking up the remaining 50%. Again, this is most pronounced in 9x/ME. NT/2K don't do it to such a degree...
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 23K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter