Downloaded and changed... at least it starts the WUs now without crashing them at once, so there seems to be hope. I have suspended the other projects again and I'll let the laptop run overnight, so we get results as soon as possible.
In addition it will stop trying to immediately sync the checkpoint file after five successive failures (which should help e.g. on XFS). And in contrast to the 4.14 will still keep the checkpoint if syncing failed.
On my XFS systems checkpointing now works (what a relief!). There are no messages about inability to sync, as if it even didn't try to sync at all ...
Quote:
I intend to make this one the "official" Linux App soon, we should at least get some more information about the computing errors we still get of the 4.02 App.
The other issue I've had on my ancient machine, namely that it doesn't record CPU time consumed (see this post) is still present. Might be a show-stopper? It is naughty as it screws-up client scheduler because it can't predict when to fetch new WUs or how long is it going to take to finish the current one (and thusly running in EDF mode). Any chance to fix it?
I guess it depends on the number of machines affected... any chance to predict that? All I can say is it seems to be working okay on my laptop. Maybe a vintage box problem? Would be doubly evil since they tend to be overcommited anyway...
The other issue I've had on my ancient machine, namely that it doesn't record CPU time consumed (see this post) is still present. Might be a show-stopper? It is naughty as it screws-up client scheduler because it can't predict when to fetch new WUs or how long is it going to take to finish the current one (and thusly running in EDF mode). Any chance to fix it?
What system (glibc, Kernel) is this?
I don't want to go into too much detail here, but recent changes to BOINC affected the handling of CPU time. The old way was violating standards and caused some trouble (e.g. the "hang" problem on MacOS), while the new may not work correctly on ancient systems (that have a non-standard behavior of the pthread library).
I think that with the next generation of Apps & Clients (major version number 6) there is a way around this, but for now we had to make a decision between inconvenience on old and showstoppers on new systems.
The other issue I've had on my ancient machine, namely that it doesn't record CPU time consumed (see this post) is still present. Might be a show-stopper? It is naughty as it screws-up client scheduler because it can't predict when to fetch new WUs or how long is it going to take to finish the current one (and thusly running in EDF mode). Any chance to fix it?
What system (glibc, Kernel) is this?
I have the same issue on two rather old systems. Details of one of them are in this post (addition: kernel is 2.6.10), the other one is as follows:
* OS is Gentoo something like 1,5 years old
* Kernel is 2.6.7-gentoo-r11
* Glibc version: 2.3.5
* BOINC CC: 5.10.7 official
* CPU: Pentium III (Tualatin) @ 1.133GHz
* RAM: 4GB
* Disk 17GB free on BOINC installation partition
Yep, now I look more closely it also resembles the results I crashed with the previous beta app very much. What surprised me, though, was that both WUs crashed at the same moment (I think it was directly after booting my laptop), so I wondered if sth went wrong with the box as such. Nothing crashed, froze or showed otherwise unusual behaviour, so it might still be a BOINC problem- maybe it has to do with checkpointing or so?
Downloaded and changed... at
)
Downloaded and changed... at least it starts the WUs now without crashing them at once, so there seems to be hope. I have suspended the other projects again and I'll let the laptop run overnight, so we get results as soon as possible.
Much better :-) Starts up
)
Much better :-) Starts up fine and crunches along smoothly on my Knoppix 5.2 notebook.
CU
H-B
Finished 2 on the vmware
)
Finished 2 on the vmware Debian.
http://einsteinathome.org/host/1041649/tasks
Changed to 4.16 on main rig just now, the results in progress with 4.14 resumed using 4.16 without problems.
Team Philippines
RE: In addition it will
)
On my XFS systems checkpointing now works (what a relief!). There are no messages about inability to sync, as if it even didn't try to sync at all ...
The other issue I've had on my ancient machine, namely that it doesn't record CPU time consumed (see this post) is still present. Might be a show-stopper? It is naughty as it screws-up client scheduler because it can't predict when to fetch new WUs or how long is it going to take to finish the current one (and thusly running in EDF mode). Any chance to fix it?
Metod ...
I guess it depends on the
)
I guess it depends on the number of machines affected... any chance to predict that? All I can say is it seems to be working okay on my laptop. Maybe a vintage box problem? Would be doubly evil since they tend to be overcommited anyway...
RE: The other issue I've
)
What system (glibc, Kernel) is this?
I don't want to go into too much detail here, but recent changes to BOINC affected the handling of CPU time. The old way was violating standards and caused some trouble (e.g. the "hang" problem on MacOS), while the new may not work correctly on ancient systems (that have a non-standard behavior of the pthread library).
I think that with the next generation of Apps & Clients (major version number 6) there is a way around this, but for now we had to make a decision between inconvenience on old and showstoppers on new systems.
BM
BM
RE: RE: The other issue
)
I have the same issue on two rather old systems. Details of one of them are in this post (addition: kernel is 2.6.10), the other one is as follows:
* Kernel is 2.6.7-gentoo-r11
* Glibc version: 2.3.5
* BOINC CC: 5.10.7 official
* CPU: Pentium III (Tualatin) @ 1.133GHz
* RAM: 4GB
* Disk 17GB free on BOINC installation partition
Metod ...
I got two more signal 11
)
I got two more signal 11 errors and don't have a clue where they come from, sorry, I'm not sure if it's relevant here but it might be...
Hi Annika! Too bad, this
)
Hi Annika!
Too bad, this looks exactly as the problem that was supposed to get fixed, e.g.
this one. I guess there's still an issue with the BOINC lib.
CU
H-B
Yep, now I look more closely
)
Yep, now I look more closely it also resembles the results I crashed with the previous beta app very much. What surprised me, though, was that both WUs crashed at the same moment (I think it was directly after booting my laptop), so I wondered if sth went wrong with the box as such. Nothing crashed, froze or showed otherwise unusual behaviour, so it might still be a BOINC problem- maybe it has to do with checkpointing or so?