Check the state of PROCHOT and/or THERMTRIP of your CPUs if you have such an erratic behavior.
It is obvious that with 4.01 the results were within 2.5% variation and with 4.07 there was a 5% longer runtime than the previous average for both calculated WUs.
Check the state of PROCHOT and/or THERMTRIP of your CPUs if you have such an erratic behavior.
It is obvious that with 4.01 the results were within 2.5% variation and with 4.07 there was a 5% longer runtime than the previous average for both calculated WUs.
Thats not erratic behavior, errors will not spread out in predictable curves. Im seeing the same as archae, very consistent variations. You will see the same when you have enough results from the same data file.
I'm just starting to get the first 4.07 results back on host 1001564 - the pink curve in message 75697. I'm now working at 464.35Hz - just the minimum 0.05 offset from the 464.30Hz plot - and it's been tracking almost exactly the same curve: even the kinks (which I had taken to be computer erratics) are in the same place.
4.07 seems to be ever so slightly slower (100 seconds in 38,700 for the most recent result 118), but the variation between 4.01 and 4.07 is much less than the variation between adjacent results.
I wasn't able to see a performance increase with 4.07 yet. Since I disabled graphics about half into the WU there may still be some room for improvement, though... Still, I can hardly wait for the new beta app.
Yep, it's a feature of the current Windows app. I think you can easily disable graphics in Linux, anyway, but I don't know about Macs. Maybe one should ask Bernd to include this feature in the next Mac app, too.
Question: Is the new "checkpointing mechanism" designed to survive the "System Restore" process (as I reported here and here)? If so, would you like me to test it?
It isn't designed for doing so, and I doubt that it will make any difference in that situation from the previous version. Would be nice to know, though.
BM
You were correct. The new checkpointing does NOT survive System Restore, although, for a moment, I thought was going to. That is, it's previous "percent complete" was displayed in the "Progress" meter while the app went through the "start-up" process again. But, when "start-up" was finished, "Progress" went back to zero. However, once again, SETI worked like a charm and picked up right where it had been.
I do wish they'd do something about it. It is very annoying to lose many hours of work just because one had to do a system restore. Happened to me several times now. The other person working on the same unit can't be too pleased either since a third party now has to take several days running through it.
I do wish they'd do something about it. It is very annoying to lose many hours of work just because one had to do a system restore. Happened to me several times now. The other person working on the same unit can't be too pleased either since a third party now has to take several days running through it.
Honestly I don't know what to do more about that.
The 4.15 App now forced to sync its checkpoints to disk, there shouldn't be a delay anymore even there.
On a correct filesystem I don't know which files a 'system restore' should touch that affect the work of BOINC (anyone any clue?).
Your last error is quite interesting. Accoding to stderr_out the App has finished the work correctly and isn't called again; i.e. everything looks fine from the App side. Yet still the task is reported as a Client error. This rather looks like a problem with the core client than with the App, e.g. if the client_state.xml was affected by the system restore, but not the data in the slots directories.
If SETI on the same machine and Client isn't affected, I'd rather consider this pure accident, maybe made more likely by project-specific differences (task runtimes, deadlines etc.).
If anyone got a clue what happens or what to improve in the App, I'd be glad to hear.
Check the state of PROCHOT
)
Check the state of PROCHOT and/or THERMTRIP of your CPUs if you have such an erratic behavior.
It is obvious that with 4.01 the results were within 2.5% variation and with 4.07 there was a 5% longer runtime than the previous average for both calculated WUs.
RE: Check the state of
)
Thats not erratic behavior, errors will not spread out in predictable curves. Im seeing the same as archae, very consistent variations. You will see the same when you have enough results from the same data file.
Team Philippines
RE: The natural variation
)
I'm just starting to get the first 4.07 results back on host 1001564 - the pink curve in message 75697. I'm now working at 464.35Hz - just the minimum 0.05 offset from the 464.30Hz plot - and it's been tracking almost exactly the same curve: even the kinks (which I had taken to be computer erratics) are in the same place.
4.07 seems to be ever so slightly slower (100 seconds in 38,700 for the most recent result 118), but the variation between 4.01 and 4.07 is much less than the variation between adjacent results.
I wasn't able to see a
)
I wasn't able to see a performance increase with 4.07 yet. Since I disabled graphics about half into the WU there may still be some room for improvement, though... Still, I can hardly wait for the new beta app.
RE: ... even with graphics
)
How do you do this? How can I disable the graphics?
Thanks in advance!
RE: RE: ... even with
)
It's described in the opening post in this thread: by putting a file EAH_NO_GRAPHICS into the BOINC directory.
RE: RE: RE: ... even
)
Thanks, it worked with my Windows client but not on my Mac.
Yep, it's a feature of the
)
Yep, it's a feature of the current Windows app. I think you can easily disable graphics in Linux, anyway, but I don't know about Macs. Maybe one should ask Bernd to include this feature in the next Mac app, too.
RE: RE: RE: Question:
)
I do wish they'd do something about it. It is very annoying to lose many hours of work just because one had to do a system restore. Happened to me several times now. The other person working on the same unit can't be too pleased either since a third party now has to take several days running through it.
RE: I do wish they'd do
)
Honestly I don't know what to do more about that.
The 4.15 App now forced to sync its checkpoints to disk, there shouldn't be a delay anymore even there.
On a correct filesystem I don't know which files a 'system restore' should touch that affect the work of BOINC (anyone any clue?).
Your last error is quite interesting. Accoding to stderr_out the App has finished the work correctly and isn't called again; i.e. everything looks fine from the App side. Yet still the task is reported as a Client error. This rather looks like a problem with the core client than with the App, e.g. if the client_state.xml was affected by the system restore, but not the data in the slots directories.
If SETI on the same machine and Client isn't affected, I'd rather consider this pure accident, maybe made more likely by project-specific differences (task runtimes, deadlines etc.).
If anyone got a clue what happens or what to improve in the App, I'd be glad to hear.
BM
BM