> Problems can be hard for Projects to track down, It is usually some form of compiling problem between platforms or the compiler used discriminates against processors (such as Intels compiler not liking AMD).
I have had to stop using my Windows AMD 4800+ on Einstein not so much for the time taken (it was doing around 15-16 hours/WU) but the new credit system reduced the points awarded to less than 13 for this machine.
My Linux AMD Opterons (285 and 275) do Einstein in 18 to 20 hours/WU respectively and get only a slightly reduced cr/h compared to before.
On Docking@home I have the opposite problem, when they recently updated WUs the once fast Linux AMD Opterons (same as used on Einstein) when from 2.5 to 3 hours/WU to over 7 hours for the same amount of points (droping from 18-20/H to 6-8/H).
But my Windows machines (including the same AMD 4800 as above) now down the same job in only 1.5 to 2.5 hours and a corrosponding gain in cr/h.
So it is not just Einstein with Processor and OS problems.
I do Linux on Einstein and Windows on Docking to balance things out.
Yes!!! Akos' computers are now hidden, but what we saw earlier was promising indeed.
However, I guess before we will see the optimized app the validation problem (esp. for WU sent to three participants) will be addressed, because you don't want to see this problem escalated by yet another variant of the software. The traditional way to do floating point math on x86 processors uses high precisoon 80 bits floating point numbers for intermediate results, however the SSE(2?) instructions used for the optimization use registers of only 32 or 64 bits width. So it can't be avoided that optimized and un-optimized apps can produce slightly different results. The validator will have to take this into consideration.
Akos, Bernard or anybody from the team... What happens with the AMD problem? Somebody here made a very simple patch a week ago (to fix a string in a modf function, I think), which fixes most of the AMD problems. Seems to me that such a minor correction could be applied right away to the running applications, and benefit from the large base of AMD CPUs thay are running at leas 30% slower now... What hasn't anything be done about it yet??
Akos, Bernard or anybody from the team... What happens with the AMD problem? Somebody here made a very simple patch a week ago (to fix a string in a modf function, I think), which fixes most of the AMD problems. Seems to me that such a minor correction could be applied right away to the running applications, and benefit from the large base of AMD CPUs thay are running at leas 30% slower now... What hasn't anything be done about it yet??
That fix came from me. But distributing an application with a modified version of the Microsoft C runtime lib would probably violate the EULA for the MS compiler. There are much better ways to fix this problem which are currently investigated. Only Bernd can tell when this will be ready, tho.
The change sounds good to me.
The amount of credits make it fun for myself and the team I belong to, but..if the R2's help the science end of this project more, then that's what has to be done. What can be learned and accomplished from this is what we have to look at.
Any changes made to the work units to help attain this end is a definite plus.
I've noticed a trend lately, that's a bit disturbing.
According to the Server Status page, the number of active hosts with this project is steadily dropping. On my own machines, it seems like it's taking longer than usual to get my results validated. Additionally, I receive quite a few units that don't get sent out to a wingman until quite a while after I've begun to crunch on my copies. It seems like we're running short of project participants.
I have to wonder. . .
Are people getting discouraged with the project and leaving, or are they leaving for other reasons? (For example, could it have to do with the warm weather in the northern hemisphere?) If people are leaving because they're discouraged, then they're creating a vicious circle. The more who leave, the longer validation takes, which will in turn cause more people to leave, which will cause validation to take even longer.
Anyway, I just thought I'd throw that out and see what everyone thinks.
> Problems can be hard for
)
> Problems can be hard for Projects to track down, It is usually some form of compiling problem between platforms or the compiler used discriminates against processors (such as Intels compiler not liking AMD).
I have had to stop using my Windows AMD 4800+ on Einstein not so much for the time taken (it was doing around 15-16 hours/WU) but the new credit system reduced the points awarded to less than 13 for this machine.
My Linux AMD Opterons (285 and 275) do Einstein in 18 to 20 hours/WU respectively and get only a slightly reduced cr/h compared to before.
On Docking@home I have the opposite problem, when they recently updated WUs the once fast Linux AMD Opterons (same as used on Einstein) when from 2.5 to 3 hours/WU to over 7 hours for the same amount of points (droping from 18-20/H to 6-8/H).
But my Windows machines (including the same AMD 4800 as above) now down the same job in only 1.5 to 2.5 hours and a corrosponding gain in cr/h.
So it is not just Einstein with Processor and OS problems.
I do Linux on Einstein and Windows on Docking to balance things out.
Hey folks! We're one-third
)
Hey folks!
We're one-third of the way through with the S5R2's now. Whoa-whoa!
RE: Hey folks! We're
)
Yeah that is good, but I think progress will slow a bit now that Seti is back up.
Waiting for Godot & salvation :-)
Why do doctors have to practice?
You'd think they'd have got it right by now
...or get quicker once we get
)
...or get quicker once we get an optimized app.
RE: Yeah that is good, but
)
...and back down again.
Reno, NV Team: SETI.USA
RE: ...or get quicker once
)
Yes!!! Akos' computers are now hidden, but what we saw earlier was promising indeed.
However, I guess before we will see the optimized app the validation problem (esp. for WU sent to three participants) will be addressed, because you don't want to see this problem escalated by yet another variant of the software. The traditional way to do floating point math on x86 processors uses high precisoon 80 bits floating point numbers for intermediate results, however the SSE(2?) instructions used for the optimization use registers of only 32 or 64 bits width. So it can't be avoided that optimized and un-optimized apps can produce slightly different results. The validator will have to take this into consideration.
CU
BRM
Akos, Bernard or anybody from
)
Akos, Bernard or anybody from the team... What happens with the AMD problem? Somebody here made a very simple patch a week ago (to fix a string in a modf function, I think), which fixes most of the AMD problems. Seems to me that such a minor correction could be applied right away to the running applications, and benefit from the large base of AMD CPUs thay are running at leas 30% slower now... What hasn't anything be done about it yet??
RE: Akos, Bernard or
)
That fix came from me. But distributing an application with a modified version of the Microsoft C runtime lib would probably violate the EULA for the MS compiler. There are much better ways to fix this problem which are currently investigated. Only Bernd can tell when this will be ready, tho.
CU
BRM
The change sounds good to
)
The change sounds good to me.
The amount of credits make it fun for myself and the team I belong to, but..if the R2's help the science end of this project more, then that's what has to be done. What can be learned and accomplished from this is what we have to look at.
Any changes made to the work units to help attain this end is a definite plus.
Hi all! I've noticed a
)
Hi all!
I've noticed a trend lately, that's a bit disturbing.
According to the Server Status page, the number of active hosts with this project is steadily dropping. On my own machines, it seems like it's taking longer than usual to get my results validated. Additionally, I receive quite a few units that don't get sent out to a wingman until quite a while after I've begun to crunch on my copies. It seems like we're running short of project participants.
I have to wonder. . .
Are people getting discouraged with the project and leaving, or are they leaving for other reasons? (For example, could it have to do with the warm weather in the northern hemisphere?) If people are leaving because they're discouraged, then they're creating a vicious circle. The more who leave, the longer validation takes, which will in turn cause more people to leave, which will cause validation to take even longer.
Anyway, I just thought I'd throw that out and see what everyone thinks.