The new generation of ABP2 Apps that should come out today has a couple
of changes to the code:
1. The template bank is written in double precision numbers, but they
are read into single precision variables. Apparently the system routines
of Windows and Linux do a different rounding when doing so. So we now
read them in in double precision and do the rounding explicitly.
2. The resampling code is rewritten to avoid to reach the precision
limit of single precision calculations.
3. For CUDA Apps only: When a client requests GPU work, it is checked
whether the GPU has enough physical ('global') memory to run the App.
However it often happens that this memory isn't available when the Task
is actually started. Previously such tasks would error out (exit code
3), which is by far the most common error of CUDA App on Einstein@home.
David Anderson implemented a way that should avoid this. An App can now
fail temporarily on memory allocation, and will then be started again
later when the memory becomes available. This requires changes to
server, client and app. The server changes are in place now, the new
generation of Apps should feature the app part. It is now up to
participants to upgrade the client, I think 6.10.26+ will do to use this
feature.
There might be additional validation problems between old and new
generation of ABP2 Apps, so I wanted to get as many tasks 'sent' (and
thus consistently assigned to old generation apps) as possible and will
the WUG keep stopped until the new Apps are out and all new workunits
will be calculated by those.
The Linux 1.04 App is meant to fix a library dependency problem of 1.02
that is specific to Linux, it is not a 'new generation' ABP2 App.
and Oliver :
One minor addition to this: the new CUDA releases (all platforms) will
feature dedicated exit codes for all CUDA-related errors (current range:
1001-1013). This way we can get error statistics much easier and focus
on the real issues.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I have some E3200 celeron dual cores which are 45nm wolfdales and cost the princely sum of $AUD48 each. They can do these ABP2 tasks two at a time in less than 40 mins and no GPU. They are rather nicely overclocked though :-). It's rather strange since my Q8400s which are also 45nm wolfdales and are even more overclocked are taking around 50-55 mins or more. I haven't had time to look into this. It was the opposite with ABP1 where the E3200 was slower than the Q8400 per task.
I have some E3200 celeron dual cores which are 45nm wolfdales and cost the princely sum of $AUD48 each. They can do these ABP2 tasks two at a time in less than 40 mins and no GPU. They are rather nicely overclocked though :-). It's rather strange since my Q8400s which are also 45nm wolfdales and are even more overclocked are taking around 50-55 mins or more. I haven't had time to look into this. It was the opposite with ABP1 where the E3200 was slower than the Q8400 per task.
Strange, given that the Q8400 has double the cache per core, and, at least at stock, has a much faster FSB than the E3200. Don't know if Intel put any special "Celeron badness" into this particular model. Some past Celerons have been real dogs, and some have been the economy speed kings of their generation--it has been a markedly inconsistent brand name, with no stable meaning except "less expensive".
The only obvious Q8400 disadvantage is four cores sharing one RAM interface, as opposed to two. Perhaps the ABP2 ap is far more RAM-access bound than most? Were that true, your Q8400 rig would presumable respond to RAM interface timing tweaking more than you are accustomed to see on other aps.
Just musing aloud. As it happens, I have a matched 2-core, 4-core pair of Conroe-class hosts, so once the ABP2 revisions settle down enough to get work on both, I can look for a similar effect there, though they differ from your Wolfdales profoundly enough that a difference would not surprise me. On existing workloads over the last couple of years on multiple SETI and Einstein aps, they have seldom differed appreciably in typical CPU seconds per result--certainly not by the amount you see. I've believe them not generally to be much RAM-bound, and spent no energy on twisting the tail on the RAM settings.
From Bernd : The new
)
From Bernd :
The new generation of ABP2 Apps that should come out today has a couple
of changes to the code:
1. The template bank is written in double precision numbers, but they
are read into single precision variables. Apparently the system routines
of Windows and Linux do a different rounding when doing so. So we now
read them in in double precision and do the rounding explicitly.
2. The resampling code is rewritten to avoid to reach the precision
limit of single precision calculations.
3. For CUDA Apps only: When a client requests GPU work, it is checked
whether the GPU has enough physical ('global') memory to run the App.
However it often happens that this memory isn't available when the Task
is actually started. Previously such tasks would error out (exit code
3), which is by far the most common error of CUDA App on Einstein@home.
David Anderson implemented a way that should avoid this. An App can now
fail temporarily on memory allocation, and will then be started again
later when the memory becomes available. This requires changes to
server, client and app. The server changes are in place now, the new
generation of Apps should feature the app part. It is now up to
participants to upgrade the client, I think 6.10.26+ will do to use this
feature.
There might be additional validation problems between old and new
generation of ABP2 Apps, so I wanted to get as many tasks 'sent' (and
thus consistently assigned to old generation apps) as possible and will
the WUG keep stopped until the new Apps are out and all new workunits
will be calculated by those.
The Linux 1.04 App is meant to fix a library dependency problem of 1.02
that is specific to Linux, it is not a 'new generation' ABP2 App.
and Oliver :
One minor addition to this: the new CUDA releases (all platforms) will
feature dedicated exit codes for all CUDA-related errors (current range:
1001-1013). This way we can get error statistics much easier and focus
on the real issues.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
OK, have just got a wad of
)
OK, have just got a wad of ABP's : (STSP) 3.03 (ABP2cuda23) turning up.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: OK, have just got a wad
)
I see one already returned on your I7. Thanks for promoting them to the top of the queue.
I got around 200 and have multiple quad core machines churning through them at the moment. Should be through the bulk of them in the next few hours.
Cheers,
Gary.
RE: RE: OK, have just got
)
They're quickies on my machine ~ 45 minutes tops.
Cheers, Mike
( edit ) and another has just reported. So far, so good ...
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: They're quickies on my
)
But that's with a GPU as well :-).
I have some E3200 celeron dual cores which are 45nm wolfdales and cost the princely sum of $AUD48 each. They can do these ABP2 tasks two at a time in less than 40 mins and no GPU. They are rather nicely overclocked though :-). It's rather strange since my Q8400s which are also 45nm wolfdales and are even more overclocked are taking around 50-55 mins or more. I haven't had time to look into this. It was the opposite with ABP1 where the E3200 was slower than the Q8400 per task.
Cheers,
Gary.
RE: I have some E3200
)
Strange, given that the Q8400 has double the cache per core, and, at least at stock, has a much faster FSB than the E3200. Don't know if Intel put any special "Celeron badness" into this particular model. Some past Celerons have been real dogs, and some have been the economy speed kings of their generation--it has been a markedly inconsistent brand name, with no stable meaning except "less expensive".
The only obvious Q8400 disadvantage is four cores sharing one RAM interface, as opposed to two. Perhaps the ABP2 ap is far more RAM-access bound than most? Were that true, your Q8400 rig would presumable respond to RAM interface timing tweaking more than you are accustomed to see on other aps.
Just musing aloud. As it happens, I have a matched 2-core, 4-core pair of Conroe-class hosts, so once the ABP2 revisions settle down enough to get work on both, I can look for a similar effect there, though they differ from your Wolfdales profoundly enough that a difference would not surprise me. On existing workloads over the last couple of years on multiple SETI and Einstein aps, they have seldom differed appreciably in typical CPU seconds per result--certainly not by the amount you see. I've believe them not generally to be much RAM-bound, and spent no energy on twisting the tail on the RAM settings.
RE: They're quickies on my
)
so what is advantage of using GPU in that case? cuda apps. crunches in the same time.
RE: RE: They're quickies
)
Doh! Gets out eye chart .... 'C' is for Cat, 'G' is for Gorilla .... :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: RE: They're quickies
)
My C2D E8500 with a GTX260 needs for a CPU-tasks 35 minutes and for GPU 25 minutes. I think this is a clear advantage for GPU.
RE: CPU-tasks 35 minutes
)
for the same type of tasks? ok, i see now. thanks.