Possible, but at least some of the crashes seem to occur before even the checkpoint is read or checked or otherwise touched. Looks more like a problem with the progress reporting.
CU
H-B
I think you're better than me at reading and interpreting those error logs. But, what comes to my mind now... the laptop was running on batteries at that moment, which means it would start the BOINC client (because it's running as a daemon) but it wouldn't start crunching at all, since I have not changed the default setting of not doing BOINC while on battery power (way too much of a battery leecher to me, can't afford that with 50+ students and two possibilities to recharge your laptop in some classrooms at Uni). So, if it doesn't crunch, would it read the checkpoint at all? Why should it if it doesn't crunch? Do you know anything about that? It might help with finding out when exactly the problem occurs...
I posted my "Exit status 11" woes in this thread. When I get to that machine next week, I'll try loading the newer app. Currently I have disabled Einstein there.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
I had only a first glance thru a few of Annika's results but noticed that her wingman from Norway also had problems, but on Windows and seemingly unrelated (memory allocation during initialization). I really wonder whether this is just a coincidence. The wingman's problems started when he reached a certain WU frequency range and seems to have stopped now as it went to another frequency range. Crunchers in Norway and Germany should by default get their files from the same download server. Theoretically it's all MD5 checksum secured ..... hmmm.
Still I wonder whether there's some data dependency in the signal 11 issue.
CU
H-B
Interesting idea, maybe it's worth a closer look by the project devs. My latest WUs are from another frequency (you get through them rather quickly when most of the WUs crash instantly) so maybe they should behave differently? They seem to be doing okay atm, but they're not even half done so it's too early to say.
So, if it doesn't crunch, would it read the checkpoint at all? Why should it if it doesn't crunch? Do you know anything about that? It might help with finding out when exactly the problem occurs...
What's your setting of "Leave applications in memory while suspended" (general preferences, possibly own venue)? If the App is to be left in memory, the client will still load the App and suspend it shortly after. Maybe that's what's causing the problem.
Yes, that feature is turned on (meaning the WUs are kept in memory). Prime Grid had problems with checkpointing for a while, and since this box has quite a lot of memory, it usually isn't a performance problem... so I thought it would be more efficient. I could turn it off if it causes problems.
Yes, that feature is turned on (meaning the WUs are kept in memory). Prime Grid had problems with checkpointing for a while, and since this box has quite a lot of memory, it usually isn't a performance problem... so I thought it would be more efficient. I could turn it off if it causes problems.
No, that's not what I meant. I don't think that this setting is causing the problem. It might be that the short time between starting and suspending the App causes trouble on either the App or the OS. For now it's just good to know and may help in further tracking down the problem.
With the new beta app, mine don't crash instantly, either. That was the version before.
And being from Denmark, I think you would use the same download server as Norway and Germany, since you're right "in the middle". In case that matters; we haven't quite figured that out yet ;-) But apparently Bernd has a suspicion where the problem is, so we should just keep our fingers crossed that he can track it down and fix it soon.
Possible, but at least some
)
Possible, but at least some of the crashes seem to occur before even the checkpoint is read or checked or otherwise touched. Looks more like a problem with the progress reporting.
CU
H-B
I think you're better than me
)
I think you're better than me at reading and interpreting those error logs. But, what comes to my mind now... the laptop was running on batteries at that moment, which means it would start the BOINC client (because it's running as a daemon) but it wouldn't start crunching at all, since I have not changed the default setting of not doing BOINC while on battery power (way too much of a battery leecher to me, can't afford that with 50+ students and two possibilities to recharge your laptop in some classrooms at Uni). So, if it doesn't crunch, would it read the checkpoint at all? Why should it if it doesn't crunch? Do you know anything about that? It might help with finding out when exactly the problem occurs...
I posted my "Exit status 11"
)
I posted my "Exit status 11" woes in this thread. When I get to that machine next week, I'll try loading the newer app. Currently I have disabled Einstein there.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
I had only a first glance
)
I had only a first glance thru a few of Annika's results but noticed that her wingman from Norway also had problems, but on Windows and seemingly unrelated (memory allocation during initialization). I really wonder whether this is just a coincidence. The wingman's problems started when he reached a certain WU frequency range and seems to have stopped now as it went to another frequency range. Crunchers in Norway and Germany should by default get their files from the same download server. Theoretically it's all MD5 checksum secured ..... hmmm.
Still I wonder whether there's some data dependency in the signal 11 issue.
CU
H-B
Interesting idea, maybe it's
)
Interesting idea, maybe it's worth a closer look by the project devs. My latest WUs are from another frequency (you get through them rather quickly when most of the WUs crash instantly) so maybe they should behave differently? They seem to be doing okay atm, but they're not even half done so it's too early to say.
RE: So, if it doesn't
)
What's your setting of "Leave applications in memory while suspended" (general preferences, possibly own venue)? If the App is to be left in memory, the client will still load the App and suspend it shortly after. Maybe that's what's causing the problem.
BM
BM
Yes, that feature is turned
)
Yes, that feature is turned on (meaning the WUs are kept in memory). Prime Grid had problems with checkpointing for a while, and since this box has quite a lot of memory, it usually isn't a performance problem... so I thought it would be more efficient. I could turn it off if it causes problems.
RE: Yes, that feature is
)
No, that's not what I meant. I don't think that this setting is causing the problem. It might be that the short time between starting and suspending the App causes trouble on either the App or the OS. For now it's just good to know and may help in further tracking down the problem.
BM
BM
RE: (you get through them
)
Mine weren't crashing instantly, they were running for a while, a few hours sometimes. I have "leave in memory" set.
I'm in Denmark if it matters.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
With the new beta app, mine
)
With the new beta app, mine don't crash instantly, either. That was the version before.
And being from Denmark, I think you would use the same download server as Norway and Germany, since you're right "in the middle". In case that matters; we haven't quite figured that out yet ;-) But apparently Bernd has a suspicion where the problem is, so we should just keep our fingers crossed that he can track it down and fix it soon.