Finally got around to updating the BIOS on this system. I was wrong about the Apr 2001 BIOS date. That's what CPUz reports and is probably the chip date. Before I did the BIOS update, the MB reported the BIOS date as 3/25/02. After the update it reports the BIOS date as 10/28/02.
CPUz v1.40 still doesn't show SSE. I get approx. the same performance as listed below for Einstein. Don't know what Seti will show as they are DITW (dead in the water) right now. Time will tell. I may need to replace the MB (if I can find one...and in the right price range).
Quote:
BIOS date is Apr 2001 and there are updates into 2002. I'll see about upgrading the BIOS when I get home from work tonight.
Quote:
Quote:
That's a possibility I'll have to check out. The XP2200+ doesn't show SSE either using CPUz or BOINC.
MB is ECS K7S5A
I'm using a Soyo KT880 MB with an AMD 2200+ CPU and CPUz version 1.39 shows it has MMX (+), 3DNow! (+), SSE
WU's are running for 18+ hours and receiving 169 - 170 credits.
Hey!!! one day without anybody posting here!!! Looks like they got it right this time.... no errors with the new application, fair credits and no complains!!!. And the active host graphic is up again!!
At least, the worst is over... Applause for the team!!!!
Hey!!! one day without anybody posting here!!! Looks like they got it right this time.... no errors with the new application, fair credits and no complains!!!. And the active host graphic is up again!!
At least, the worst is over... Applause for the team!!!!
At least part of this spike is probably due to seti being down.
A while ago I promised to post an illustration of the relation between frequency and run-time of the workunits, but got distracted a little - so here it is: PDF. Don't give too much about the absolute run-time mentioned there, which was calculated for a specific machine with an old version of the code and under certain assumptions - this should just give you an idea of the distribution. Note that the workunit generator knows about this relation and will assign credit to a WU proportional to its expected run-time.
Cool graph. PS you could use awarded credit instead of hours, then it would scale to any machine :)
I thought about that, but this graph was made before we knew how much credit to actually grant for each predicted CPU-second, and this factor is still subject to change, too, with the development of the App.
Is there anything special happening at the discontinuities or are those just locations where the number of WUs a given chunk of data is split into changes?
Is there anything special happening at the discontinuities or are those just locations where the number of WUs a given chunk of data is split into changes?
Rather the latter, but not quite.
It's not the data that is split into Workunits, but the "parameter space", which is the set of all possible parameter combinations a signal ("pulsar") can have, and for which we scan the data. The region of the parameter space a particular Task covers is described in the Workunit specification which your machine gets sent from the scheduler, and shows up in the command line the App gets called with when crunching a Task.
The total number of parameter-space points we need to scan increases (more or less continously) with frequency. The workunit genrator tries to split them into workunits of equal size, but it can't make the blocks it splits arbitrary small, their size also depends on the frequency.
Also too with the new algorithm other calculations and the time needed for them depend (non-linear, IIRC) on the frequency, which adds some more curvature to the "blocks" and thus the graph.
Finally got around to
)
Finally got around to updating the BIOS on this system. I was wrong about the Apr 2001 BIOS date. That's what CPUz reports and is probably the chip date. Before I did the BIOS update, the MB reported the BIOS date as 3/25/02. After the update it reports the BIOS date as 10/28/02.
CPUz v1.40 still doesn't show SSE. I get approx. the same performance as listed below for Einstein. Don't know what Seti will show as they are DITW (dead in the water) right now. Time will tell. I may need to replace the MB (if I can find one...and in the right price range).
Seti Classic Final Total: 11446 WU.
Hey!!! one day without
)
Hey!!! one day without anybody posting here!!! Looks like they got it right this time.... no errors with the new application, fair credits and no complains!!!. And the active host graphic is up again!!
At least, the worst is over... Applause for the team!!!!
RE: Hey!!! one day without
)
At least part of this spike is probably due to seti being down.
I noticed my pendings going
)
I noticed my pendings going down, so more people are returning valid results...
A while ago I promised to
)
A while ago I promised to post an illustration of the relation between frequency and run-time of the workunits, but got distracted a little - so here it is: PDF. Don't give too much about the absolute run-time mentioned there, which was calculated for a specific machine with an old version of the code and under certain assumptions - this should just give you an idea of the distribution. Note that the workunit generator knows about this relation and will assign credit to a WU proportional to its expected run-time.
BM
BM
Cool graph. PS you could use
)
Cool graph. PS you could use awarded credit instead of hours, then it would scale to any machine :)
RE: Cool graph. PS you
)
I thought about that, but this graph was made before we knew how much credit to actually grant for each predicted CPU-second, and this factor is still subject to change, too, with the development of the App.
BM
BM
Yep, and sure explains why my
)
Yep, and sure explains why my K6's are sort of 'bogged down' right now, especially with the 298.60 MHz result one of them is running! ;-)
Although if you consider the Y axis as a multiplier instead of absolute time it works as you suggest as well.
BTW, thanks for publishing this, Bernd. It's highly useful Beta run intel. :-)
Alinator
Is there anything special
)
Is there anything special happening at the discontinuities or are those just locations where the number of WUs a given chunk of data is split into changes?
RE: Is there anything
)
Rather the latter, but not quite.
It's not the data that is split into Workunits, but the "parameter space", which is the set of all possible parameter combinations a signal ("pulsar") can have, and for which we scan the data. The region of the parameter space a particular Task covers is described in the Workunit specification which your machine gets sent from the scheduler, and shows up in the command line the App gets called with when crunching a Task.
The total number of parameter-space points we need to scan increases (more or less continously) with frequency. The workunit genrator tries to split them into workunits of equal size, but it can't make the blocks it splits arbitrary small, their size also depends on the frequency.
Also too with the new algorithm other calculations and the time needed for them depend (non-linear, IIRC) on the frequency, which adds some more curvature to the "blocks" and thus the graph.
hth,
BM
BM