???So slow under windows??? I have an AMD system very similiar to Kirstins and I have had to end my association with E@Home as well due to the fact that upon startup E@H gobbled close to 100% of my CPU time, severely slowing my system. When I first began using E@H I did not have this issue but for the last month or so it has been an annnoying problem Deleting BOINC and E@H resolved this issue. It was E@H that was robbing my CPU time to extremes. Perhaps I will use boinc with another project that is less cpu intensive. By the way, I have had absolutely no issues with my AMD system under windows before or after E@H was on my system. Its too bad, it was such a worthy project,
--Terry N.
Quote:
Hi!
I wonder if Kirsten is still around here, now that we figured out why the AMDs are so slow under Windows.
Well, I have detached the project. My temperament is not for 100 hours long work units, which should not be running for more than around 30 hours on my type of machine: an AMD 64 3200+.
This machine is quite fast and in SETI@home a 9.704 second WU (=2 hour 41 min) is 'rewarded' with 64,20 credits. Even if I am not in BOINC for the credits, I would not like to waste my idle CPU cycles on a questionable work.
That is a lot. My Athlon 64 3700+ takes about 44 CPU hours/WU maximum. It errored out after processing for over 40 hours one time, and that's another story.
What I would like to know is how I just got allocated 8 WU's that are supposed to take 31 hours each, with a deadline of June 6, when the resource allocation for E@H is a little under 16.5%?
I wondered, of course, whether BOINC made a correct estimation of time to completion or not, as the estimation at first was 67 hours. After 36 hours of crunching the estimation was only reduced to 62 hours, though. Therefore my question as I smelled a bug.
Off topic: It would have been nice to know that the estimated runtimes could be inaccurate *before* I detached the project and thereby wasted 36 hours of crunching. IMO I might have received a faster (and probably the quoted correct) answer to my original question if I have had the right to ask questions in the correct forum. To me a bug and problems forum is meant for newbies and/or beta testers.
I run several BOINC projects, and they're all pessimistic about processing times, especially before you've processed a few WU's What I often see is that, as each WU is processed, the estimated completion time for remaining WU's trends downward. The estimated time never seems to go as low as the actual processing time, and this makes sense to me to allow for some "wiggle room" for unexpected outages. If the "real" times were used, it would be far more likely that your system might download more WU's than it can process in the allotted time.
Does the project have the servers, manpower, etc. to do it as a traditional? Think about the project resources, etc. They may not be able to do things the way other people may think they should.
I personally do not have any problems with Einstein on any of my 5 machines. No errors have occurred, the data is getting done, and I am getting credit.
I have had considerable trouble (at one point, two WU's errored out, out of four total, one of which errored out after processing for about 40 hours) with my one machine, and it is beginning to appear that it is because it is an AMD machine.
[snip] It was E@H that was robbing my CPU time to extremes. Perhaps I will use boinc with another project that is less cpu intensive. By the way, I have had absolutely no issues with my AMD system under windows before or after E@H was on my system. Its too bad, it was such a worthy project,
--Terry N.
Terry,
On my AMD box, SETI takes about 2.5 CPU hours/WU. If you want something really speedy, PrimeGrid only takes about 10 CPU minutes per WU!
I had a few 40+ hour E@H WU's, one of which errored out shortly before it was finished processing (to my considerable annoyance). Somehow or another Rosetta gives you credit, even if the WU errors out.
I wonder if Kirsten is still around here, now that we figured out why the AMDs are so slow under Windows.
CU
BRM
I'll bite. Just why are "AMDs so slow under Windows"? My <$100 (brand new, before the prices went down) single core AMD processor manages 2555.91 MIPS floating point, and 4777.84 MIPS integer on Windows XP.
I wonder if Kirsten is still around here, now that we figured out why the AMDs are so slow under Windows.
CU
BRM
I'll bite. Just why are "AMDs so slow under Windows"? My Pentium III"). Athlon 64 and Operons under Windows suffer a ~ 30% performance penalty for E@H under Windows because of this bug.
Look at the list of top computers. The first AMD box under Windows is ranked at position 180 or something like this at the time of writing. All hosts up to that rank are either Intel or AMD under Linux!
The bug in the math library is relatively easy to correct so I guess we will see an improved Windows app at least as a beta test app in the near future.
???So slow under windows???
)
???So slow under windows??? I have an AMD system very similiar to Kirstins and I have had to end my association with E@Home as well due to the fact that upon startup E@H gobbled close to 100% of my CPU time, severely slowing my system. When I first began using E@H I did not have this issue but for the last month or so it has been an annnoying problem Deleting BOINC and E@H resolved this issue. It was E@H that was robbing my CPU time to extremes. Perhaps I will use boinc with another project that is less cpu intensive. By the way, I have had absolutely no issues with my AMD system under windows before or after E@H was on my system. Its too bad, it was such a worthy project,
--Terry N.
--Terry photostuff.org
RE: Well, I have detached
)
That is a lot. My Athlon 64 3700+ takes about 44 CPU hours/WU maximum. It errored out after processing for over 40 hours one time, and that's another story.
What I would like to know is how I just got allocated 8 WU's that are supposed to take 31 hours each, with a deadline of June 6, when the resource allocation for E@H is a little under 16.5%?
RE: I wondered, of
)
I run several BOINC projects, and they're all pessimistic about processing times, especially before you've processed a few WU's What I often see is that, as each WU is processed, the estimated completion time for remaining WU's trends downward. The estimated time never seems to go as low as the actual processing time, and this makes sense to me to allow for some "wiggle room" for unexpected outages. If the "real" times were used, it would be far more likely that your system might download more WU's than it can process in the allotted time.
RE: Does the project have
)
I have had considerable trouble (at one point, two WU's errored out, out of four total, one of which errored out after processing for about 40 hours) with my one machine, and it is beginning to appear that it is because it is an AMD machine.
RE: [snip] It was E@H that
)
Terry,
On my AMD box, SETI takes about 2.5 CPU hours/WU. If you want something really speedy, PrimeGrid only takes about 10 CPU minutes per WU!
I had a few 40+ hour E@H WU's, one of which errored out shortly before it was finished processing (to my considerable annoyance). Somehow or another Rosetta gives you credit, even if the WU errors out.
RE: Hi! I wonder if
)
I'll bite. Just why are "AMDs so slow under Windows"? My <$100 (brand new, before the prices went down) single core AMD processor manages 2555.91 MIPS floating point, and 4777.84 MIPS integer on Windows XP.
RE: RE: Hi! I wonder if
)