Message boards :
Number crunching :
Problems with K6-2 class processor
Message board moderation
Author | Message |
---|---|
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
I have several older computers running Seti in addition to my main system. They include an AMD Duron 800mhz, a Pentium 3 500mhz, an AMD K6-2 500mhz, and an AMD K6-2 450mhz. I know that the older AMD chips were less efficient at FPU applications than Intel chips, so it's understandable that my K6 machines would be lagging a bit behind their Intel counterparts. However, they do more than lag, they take nearly 3x longer to complete work units than my Pentium 3 500mhz. The BOINC benchmarks say they should do one WU every 20 hours or so, yet they take upwards of 45 or 50. Is this normal? I don't recall this happening before 4.08. At these speeds, it would appear that a 200mhz Pentium 1 chip would perform better. That cant't be right. You will be assimilated...bunghole! |
dbernat Send message Joined: 13 Nov 99 Posts: 39 Credit: 145,132 RAC: 0 |
My K6-2 333 MHz machine (64 MB of RAM, Windows 98) completes a work unit in about 40 hours. I suspect that the bottleneck on AMD K6-2 series CPUs is the amount of RAM in the on-board cache. |
Guido Alexander Waldenmeier Send message Joined: 3 Apr 99 Posts: 587 Credit: 18,397 RAC: 0 |
her you have times that help you to see how fast is it run on windows xp boinc 4.13 seti app.4.46 final release on pentium 3 run at 667 mhz need 8 to 8,5 hours on amd 64 3000+ run 2 -to 2.5 hours -------------- that s it more then 40000 in credits and this question i not unterstand peoples like this it NO Newbie on Boinc |
William Smith Send message Joined: 12 Jul 03 Posts: 10 Credit: 11,645 RAC: 0 |
There is an opitmesed client out check http://www.pperry.f2s.com/downloads.htm but it is for linux, get LINUX windows 98 is very buggy out of date and totally full of security holes. It's Out there........ |
BuenSabor Send message Joined: 17 Jul 00 Posts: 4 Credit: 165,361 RAC: 22 |
I used to run K6-2/500's under 98, it ranged anywhere from 24 to 104 hrs/wu (48 typical) depending on how much my kids were playing their video games. Switched to 2200+ @1.8 ghz under xp, now takes from 3 to 13 hrs/wu (6 typical). More than clock speed, rather, cache size, fsb speed, & disk speed count. yiC steve |
Benher Send message Joined: 25 Jul 99 Posts: 517 Credit: 465,152 RAC: 0 |
Mr Smith, Aren't there only optimized BOINC clients at that link (perry), not seti worker apps at that link? The worker app is the one taking 45 hours... Whenever discussing the two I allways use Client for boinc and worker or worker app to describe the two programs. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13746 Credit: 208,696,464 RAC: 304 |
>windows 98 is very buggy out of date and >totally full of security holes. Windows 98SE, broadband, no firewall, no antivirus programme, Internet Explorer, current patches. Not one virus or trojan or hijack in over 5 years of use. It would appear your knowledge of Windows is some what lacking. Grant Darwin NT |
Alex Send message Joined: 26 Sep 01 Posts: 260 Credit: 2,327 RAC: 0 |
The AMD K6 450mhz runs slower than a PII-266 mhz machine because of the Cache. Comparatively, the P2 would have 128 K of instuctions cached locally, ready to compute, while the AMD K6 would have to go all the way to the ram to get the next instruction. Having a cache increases efficiency. When you get a new machine, look into the Hyperthreading cpu's. Same results linux/windows, the chip with no cache would compute slower. |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
> The AMD K6 450mhz runs slower than a PII-266 mhz machine because of the > Cache. > > Comparatively, the P2 would have 128 K of instuctions cached locally, ready to > compute, while the AMD K6 would have to go all the way to the ram to get the > next instruction. > > Having a cache increases efficiency. > When you get a new machine, look into the Hyperthreading cpu's. > > Same results linux/windows, the chip with no cache would compute slower. > > Just a followup, both of my K6 machines seem to be lagging farther and farther behind what they used to do before the Seti 4.07 / 4.08 apps. In addition, they're pulling validate errors on practically every single result. http://setiweb.ssl.berkeley.edu/results.php?hostid=4010 http://setiweb.ssl.berkeley.edu/results.php?hostid=4055 View the links to see what I mean. Could it be that the most recent versions are simply choked on by K6-2 chips? Seti 4.08 works fine on my other machines (Pentium 4 2.4ghz, AMD Duron 800mhz, Pentium 3 500mhz, Celeron 366mhz, Pentium 200mhz MMX, and even my Pentium 75mhz laptop is more efficient than my K6-2 machines). By the way, I'm aware that these two machines are holding up credits for the rest of you, and I'm sorry. If I can't get this straightened out soon, I'll "upgrade" them to good, ol' Pentium 233mhz MMX chips. Pathetically enough, the 233mhz Pentium seems faster than the K6-2 450mhz. You will be assimilated...bunghole! |
Ingleside Send message Joined: 4 Feb 03 Posts: 1546 Credit: 15,832,022 RAC: 13 |
> > Just a followup, both of my K6 machines seem to be lagging farther and farther > behind what they used to do before the Seti 4.07 / 4.08 apps. In addition, > they're pulling validate errors on practically every single result. > > http://setiweb.ssl.berkeley.edu/results.php?hostid=4010 > > http://setiweb.ssl.berkeley.edu/results.php?hostid=4055 > Since you're returning your results after your 14-day-deadline is over, the wu have been re-issued to someone else. Then the re-issued result is returned, and if wu passes validation, the wu & all result-files is deleted from disk. When you still later returns your result, it's nothing to compare against, and it's marked invalid. To fix this problem, decrease your cache-size, so your results will be returned before the 14-day-deadline is out. |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
> > > > Just a followup, both of my K6 machines seem to be lagging farther and > farther > > behind what they used to do before the Seti 4.07 / 4.08 apps. In > addition, > > they're pulling validate errors on practically every single result. > > > > http://setiweb.ssl.berkeley.edu/results.php?hostid=4010 > > > > http://setiweb.ssl.berkeley.edu/results.php?hostid=4055 > > > > Since you're returning your results after your 14-day-deadline is over, the wu > have been re-issued to someone else. Then the re-issued result is returned, > and if wu passes validation, the wu & all result-files is deleted from > disk. When you still later returns your result, it's nothing to compare > against, and it's marked invalid. > > To fix this problem, decrease your cache-size, so your results will be > returned before the 14-day-deadline is out. > Right, that's what I'm doing, but my point is that these two K6 machines are impossibly slow. A 10 day cache works great on all my machines...but I'd need to set my cache to 2 days on the K6 computers to keep them working. Hmm....let me play around with the work / school / home settings. You will be assimilated...bunghole! |
Benher Send message Joined: 25 Jul 99 Posts: 517 Credit: 465,152 RAC: 0 |
Maybe the poor things had a maximum number of Floating Point ops built into them and you have used them all up ;) |
Ingleside Send message Joined: 4 Feb 03 Posts: 1546 Credit: 15,832,022 RAC: 13 |
> > Right, that's what I'm doing, but my point is that these two K6 machines are > impossibly slow. A 10 day cache works great on all my machines...but I'd need > to set my cache to 2 days on the K6 computers to keep them working. > Hmm....let me play around with the work / school / home settings. > AFAIK K6 have really crappy fpu, and is therefore having terrible performance in seti. It's possible v4.08 is giving even slower performance than before, but regardless they're probably better in heating a room than crunching seti... Taking a look on your other computers, only the p4 seems to barely slip in under the deadline, having an average turnaround time of 13 days. All the other computers seems to be returning after the deadline, the worst have currently average turnaround of 16.57 days, and some results is being marked invalid. Even the p4 seems to slip in under the deadline, would recommend decreasing the cache 1 day. For the other computers, if you really need so big cache, would decrease cache-setting so no computer is using more than 12 days on a wu. The reason to have a little extra time before deadline is in case any computer-problems or connection-problems or for that matter new wu or seti-application being even slower than today is released, and again push you over the deadline. |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
> Maybe the poor things had a maximum number of Floating Point ops built into > them and you have used them all up ;) > > > heh I wouldn't be a bit surprised. You will be assimilated...bunghole! |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
> > > > Right, that's what I'm doing, but my point is that these two K6 machines > are > > impossibly slow. A 10 day cache works great on all my machines...but I'd > need > > to set my cache to 2 days on the K6 computers to keep them working. > > Hmm....let me play around with the work / school / home settings. > > > > AFAIK K6 have really crappy fpu, and is therefore having terrible performance > in seti. It's possible v4.08 is giving even slower performance than before, > but regardless they're probably better in heating a room than crunching > seti... > > > Taking a look on your other computers, only the p4 seems to barely slip in > under the deadline, having an average turnaround time of 13 days. All the > other computers seems to be returning after the deadline, the worst have > currently average turnaround of 16.57 days, and some results is being marked > invalid. > > Even the p4 seems to slip in under the deadline, would recommend decreasing > the cache 1 day. For the other computers, if you really need so big cache, > would decrease cache-setting so no computer is using more than 12 days on a > wu. The reason to have a little extra time before deadline is in case any > computer-problems or connection-problems or for that matter new wu or > seti-application being even slower than today is released, and again push you > over the deadline. > The others had some other CPU-intensive programs taking up processor time, but those programs have been recently terminated. Now they're coming in under the deadline. You will be assimilated...bunghole! |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
And another thing...what could explain the large number of validation errors on my K6-2 machines? Would sending the result in after the deadline cause that? If so, I should probably flush the cache and start over. You will be assimilated...bunghole! |
Ingleside Send message Joined: 4 Feb 03 Posts: 1546 Credit: 15,832,022 RAC: 13 |
> And another thing...what could explain the large number of validation errors > on my K6-2 machines? Would sending the result in after the deadline cause > that? If so, I should probably flush the cache and start over. > If wu already validated and all results accounted for, meaning either reported or passed their deadline, all files for this wu in upload/download-directory is deleted. Any results returned later can't be validated, since there's nothing to compare them against. So it's probably best to report any done work, and empty your cache. |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
> > And another thing...what could explain the large number of validation > errors > > on my K6-2 machines? Would sending the result in after the deadline > cause > > that? If so, I should probably flush the cache and start over. > > > > If wu already validated and all results accounted for, meaning either reported > or passed their deadline, all files for this wu in upload/download-directory > is deleted. Any results returned later can't be validated, since there's > nothing to compare them against. > > So it's probably best to report any done work, and empty your cache. > That's kinda what I thought. I'll do that shortly and see what happens. You will be assimilated...bunghole! |
wrzwaldo Send message Joined: 16 Jul 00 Posts: 113 Credit: 1,073,284 RAC: 0 |
> And another thing...what could explain the large number of validation errors > on my K6-2 machines? Would sending the result in after the deadline cause > that? If so, I should probably flush the cache and start over. > Did you miss this post? quote Since you're returning your results after your 14-day-deadline is over, the wu have been re-issued to someone else. Then the re-issued result is returned, and if wu passes validation, the wu & all result-files is deleted from disk. When you still later returns your result, it's nothing to compare against, and it's marked invalid. /quote <img src="http://boinc.mundayweb.com/seti2/stats.php?userID=2259&team=off"> |
Borgholio Send message Joined: 2 Aug 99 Posts: 654 Credit: 18,623,738 RAC: 45 |
> > And another thing...what could explain the large number of validation > errors > > on my K6-2 machines? Would sending the result in after the deadline > cause > > that? If so, I should probably flush the cache and start over. > > > > > Did you miss this post? > > quote > > Since you're returning your results after your 14-day-deadline is over, the wu > have been re-issued to someone else. Then the re-issued result is returned, > and if wu passes validation, the wu & all result-files is deleted from > disk. When you still later returns your result, it's nothing to compare > against, and it's marked invalid. > > /quote > Actually no, I didn't miss it. I already knew that after 14 days, the server would re-issue the workunit to someone else. I was asking if the error message "Validation error" was caused by this or by some other problem, as I have returned work units past the deadline before and never received that message. You will be assimilated...bunghole! |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.