Every task is failing at line 330 ... halt the madness ...

ERROR: [ERROR] Unable to open constraints file: .pdb.distances.csts.bounded_1.0
ERROR:: Exit from: ....srccorescoringconstraintsConstraintIO.cc line: 330
BOINC:: Error reading and gzipping output datafile: default.out
called boinc_finish

Every task is failing at line 330 ... halt the madness ...

ERROR: [ERROR] Unable to open constraints file: .pdb.distances.csts.bounded_1.0
ERROR:: Exit from: ....srccorescoringconstraintsConstraintIO.cc line: 330
BOINC:: Error reading and gzipping output datafile: default.out
called boinc_finish

Another workunit that failed at that line both for me and my wingman:

https://ralph.bakerlab.org/result.php?resultid=1302770

In 1.58 at least for me.

I've attempted to set them both locally and remotely, both at less than 100%. I'm not sure if I've found the correct way to set them locally, though, and I'll want to know the difference when I get the new computer I'm planning to order.

Advanced menu/preferences ... make the setting ... click "Ok" button ...

To go back to the web settings:

Advanced menu/preferences ... click "Clear" button ...

You should be able to tell if the setting has taken, assuming you set it to less than 100% by watching the CPU trend-line and there will be periodic dips in the level ... the way BOINC does "throttling" is to halt operation on a periodic basis. If you set it lower the dips should be more dramatic.

Thank you - finally, a method that works. Now set at 90%, so when I get another workunit, I can look for any effects that causes, or maybe faster if Rosetta@home workunits are affected also.

I've never used that function before, so I suspect that one of the other BOINC projects I participate in set it at 100% without providing any way to reverse that action.

I've attempted to set them both locally and remotely, both at less than 100%. I'm not sure if I've found the correct way to set them locally, though, and I'll want to know the difference when I get the new computer I'm planning to order.

Advanced menu/preferences ... make the setting ... click "Ok" button ...

To go back to the web settings:

Advanced menu/preferences ... click "Clear" button ...

You should be able to tell if the setting has taken, assuming you set it to less than 100% by watching the CPU trend-line and there will be periodic dips in the level ... the way BOINC does "throttling" is to halt operation on a periodic basis. If you set it lower the dips should be more dramatic.

Thank you - finally, a method that works. Now set at 90%, so when I get another workunit, I can look for any effects that causes, or maybe faster if Rosetta@home workunits are affected also.

I've never used that function before, so I suspect that one of the other BOINC projects I participate in set it at 100% without providing any way to reverse that action.

THe only project that "poisoned" the well that I know of was QCN where a debug action set the date to a very bad value. So, you had to do lots of stuff to try to get the settings right. The problem is that the setting with the latest date is the one that prevails ... and in the case of QCN the server got the date 2030 or something like that ... so, any computer with the settings from that set would keep "updating" all the old projects with the settings you no longer wanted.

They have directons on the site to fix the issue though you have to touch all projects affected for some reason ...

Anyway,

*MY* experience is that it is an intermittent problem, that is to say, that it will not affect all tasks run. It caused me problems on only about 40% of the tasks run ... I have no idea what is the other issue in the mix that gives rise to the problem. And, to a large extent I am too production oriented to spend much time and energy I don't have to poke and prod the systems looking for these problems.

I posted a note on the BOINC Dev list where it vanished without a comment or even a gurgle as it sank out of sight about the fact that the preferences pane does not really show that you are on local settings vice global settings ...

I've attempted to set them both locally and remotely, both at less than 100%. I'm not sure if I've found the correct way to set them locally, though, and I'll want to know the difference when I get the new computer I'm planning to order.

Advanced menu/preferences ... make the setting ... click "Ok" button ...

To go back to the web settings:

Advanced menu/preferences ... click "Clear" button ...

You should be able to tell if the setting has taken, assuming you set it to less than 100% by watching the CPU trend-line and there will be periodic dips in the level ... the way BOINC does "throttling" is to halt operation on a periodic basis. If you set it lower the dips should be more dramatic.

Thank you - finally, a method that works. Now set at 90%, so when I get another workunit, I can look for any effects that causes, or maybe faster if Rosetta@home workunits are affected also.

I've never used that function before, so I suspect that one of the other BOINC projects I participate in set it at 100% without providing any way to reverse that action.

THe only project that "poisoned" the well that I know of was QCN where a debug action set the date to a very bad value. So, you had to do lots of stuff to try to get the settings right. The problem is that the setting with the latest date is the one that prevails ... and in the case of QCN the server got the date 2030 or something like that ... so, any computer with the settings from that set would keep "updating" all the old projects with the settings you no longer wanted.

They have directons on the site to fix the issue though you have to touch all projects affected for some reason ...

Anyway,

*MY* experience is that it is an intermittent problem, that is to say, that it will not affect all tasks run. It caused me problems on only about 40% of the tasks run ... I have no idea what is the other issue in the mix that gives rise to the problem. And, to a large extent I am too production oriented to spend much time and energy I don't have to poke and prod the systems looking for these problems.

I posted a note on the BOINC Dev list where it vanished without a comment or even a gurgle as it sank out of sight about the fact that the preferences pane does not really show that you are on local settings vice global settings ...

I've never tried to run QCN. The only project I know of that even offers the chance of setting device-specific parameters is WCG, and their method of changing them to 90% CPU time didn't work.

I didn't try to change these settings on a few projects I try to participate in that look unlikely to offer any workunits soon. One of them, Cels@home, is no longer even reachable online.

I've never seen it when I was using 100% CPU time. However, I'm now using 90% CPU time, and it may be related to the problem I just posted over in the hard-to-find thread for 1.58 problems.

I've never tried to run QCN. The only project I know of that even offers the chance of setting device-specific parameters is WCG, and their method of changing them to 90% CPU time didn't work.

I didn't try to change these settings on a few projects I try to participate in that look unlikely to offer any workunits soon. One of them, Cels@home, is no longer even reachable online.

I've never seen it when I was using 100% CPU time. However, I'm now using 90% CPU time, and it may be related to the problem I just posted over in the hard-to-find thread for 1.58 problems.

I have sensors on the way so that I can try QCN as another non-cpu intense project. Living in California, though away from where most of the fault lines are ... still ... it is a topic of interest ...

Cels@Home has changed their URL so that there is now a Cels@Home (old) and a Cels@Home that is in Alpha state ...

Now to the other thread ...

Hi all,

sorry i've been quiet on the boards recently. Been away last week and focusing on some other projects.

SOrry about the bunch of work units that went out with a faulty file reference - my bad. More today that should actually work.

The error rate has been excellent recently, there a couple of minor fixes coming soon. Then we'll start focusing on scientific improvements again. woo!

Mike,

You should change the link on the front page to point to the latest bug thread ...