Message boards :
Number crunching :
Progress reverted to zero
Message board moderation
Author | Message |
---|---|
Send message Joined: 13 Jul 05 Posts: 456 Credit: 75,142 RAC: 0 |
I had a problem with this result, it seemed to run for about twice as long as expected, and then the progress went back to zero and it continued crunching. Conjecture: maybe the progress had gone back to zero before? Anyway Jack H had already returned this WU, cliaming just over 1/3 of the credit that I estimated I'd already built up. I therefore aborted the WU on my machine. The website shows it has already been re-issued, so I hope the other crunchers have better luck than me. The OS is Win-ME (yeah, yuk, I know) and the client was 4.45. I have now upgraded the box to the 5.2.13 client, but as it is not my box am stuck with Win-ME. So far this is a one-off on this project, but Rosetta had this kind of issue on Win98 & Win-ME some time ago - maybe that is relevent or maybe not. Anyone else seen this on this project? River~~ ![]() |
Send message Joined: 4 Sep 05 Posts: 112 Credit: 2,171,795 RAC: 0 ![]() ![]() |
I have Win98se and use 5.2.13 on one of my boxes without problem except for the known LHC WU's keep counting CPU cycles when they're paused. I wonder why they say preempted? It's not preempted unles the WU gives the result before it started 8-). I could live with that! I'll check that WU anyway and make sure it's not on any of my PC's. Click here to join the #1 Aussie Alliance on LHC. |
![]() Send message Joined: 8 Mar 06 Posts: 2 Credit: 2,173 RAC: 0 |
I had same problem with Leiden Classical a couple weeks ago. It happen on two different boxes, one was running WinME the other was WinXP. This has happen to other projects too. After a little investigating the problem has to do with the last time it wrote data to a checkpoint file to the disk before it swithches project when applications are not left in memory, blah, blah, blah.... Easy solution was to change my perferences to leave applications in memory. Since I've did that I've had no problems with Leiden. Here's the post at Leiden WU restart at zero I didn't have the time or willingness to investigate further. |
Send message Joined: 13 Jul 05 Posts: 456 Credit: 75,142 RAC: 0 |
... Good suggestion, but in my case I already have this set to "yes" in general prefs so I think I must have a slightly different fault. Oddly now I have several results that I know have not had time to run, but they all show about 12 hours elapsed time. It is not quite the same figure on any two of them, but almost the same. If anyone gets a wu sharing with host 85537 then apols in advance. River~~ |
Send message Joined: 17 Sep 05 Posts: 60 Credit: 4,221 RAC: 0 |
River, I have seen workunits revert to 0, but it has never been a problem. This seems to happen only if I suspend a workunit and it has not been crunching for very long. As soon as I resume the workunit, the percentage reverts from 0 back to where it should be. I am not sure if this helps. Alex ---------------------------------------------------------------------------- ... |
![]() Send message Joined: 8 Mar 06 Posts: 2 Credit: 2,173 RAC: 0 |
Good suggestion, but in my case I already have this set to "yes" in general prefs so I think I must have a slightly different fault. Oddly now I have several results that I know have not had time to run, but they all show about 12 hours elapsed time. It is not quite the same figure on any two of them, but almost the same. If anyone gets a wu sharing with host 85537 then apols in advance. River~~[/quote] Ahh... I got that problem with Predictor@Home on my WinME box, after I've set my perferences to leave apps. in memory. When another application was running the Predictor CPU time kept increasing and the time to completion went higher even though it wasn't runnning. That is a a problem with BOINC scheduler and WinME with apps. in memory. This bug only affect your claimed credits, check this Predictor result for 235744 , the time should have been around 20,000 seconds. As long as it completes the WU's and the results are accurate and there are no errors and I get the proper granted credits I'm not worried about it. Someday I will switch it to XP. |
Send message Joined: 26 Sep 05 Posts: 85 Credit: 421,130 RAC: 0 ![]() ![]() |
Ahh... I got that problem with Predictor@Home on my WinME box, after I've set my perferences to leave apps. in memory. When another application was running the Predictor CPU time kept increasing and the time to completion went higher even though it wasn't runnning. The problem here is that if it really is running longer because of this (and not just an error in book keeping), it keeps one's CPU pre-occupied when it could move on to crunch other WUs... If it's just reporting incorrect times, but not really running longer, then this wouldn't matter quite so bad. And on winME, I hate to be a bearer of bad news as such, but that OS has issues is about all I can say about it. Perhaps some will not know quite what to say (given some betas have faired better then that OS on shipping), but I had it when the thing was in beta :eek: Anyhow, and let me put it this way. I was an MSDN pro sucriber at the time, and one of the things we got was the CDs mailed to us (also for the operating systems when they hit release candidate status, or even sometimes like with winXP, then Whistler when it was in beta 1). Anyhow, winME was considered so bad, that on the MSDN newsgroups, right up on Microsoft's own site, MSDN (Microsoft developers network) subsribers were very voicterious on how bad it was, and insisted they wouldn't load that thing on any of the development machines, even if the CD came to them at no additional cost. Mind you, these were third party computer programmers and the like that were talking about how they wouldn't load it "for free" even (not really free, but no change in subscription costs), it being so horrid in their estimation... BTW, and as an aside, when I backup a CPDN or seasonal attribution WU, and re-start BOINC, it shows the WU at 0% while it loads the app, but recovers once loaded to the last save point. If this is what's happening, it really isn't an issue I don't think... ![]() |
©2025 CERN