The problem as I see it... Oh wait, I see so MANY problems that it is pretty much impossible to pick one as "the problem" to focus on.

The BOINC server software is old, but works fine (it lacks a few features but that's it).

One of YOUR major problems is that few people are noticing problems. I think that is related to a pretty large lack of concern on the side of the people "managing" this system. Indifference transmitted, indifference returned.
[/quote]
I'm on here all the time and don't notice many "problems".

Case in point is the implicit complaint addressed in the "increasing the default run time" discussion. They say the "problem" is a waste of bandwidth at their end. Okay, so maybe they could stop sending me hundreds (more likely thousands) of work units that my machines can't process before their deadlines?

I don't pay any attention to the deadlines. The work will still be of use after the deadline - it's not like they're waiting until bang-on the deadline to review it.

I have wasted a lot of time and energy trying to set the parameters to avoid such waste.

Don't - you don't need to micro-manage it, barring a recent run of dodgy tasks and an issue with a missing file on Linux machines for a few days.

In spite of my best efforts, right now this machine has received several screens of pending work units, but it's a relatively slow machine that only handles two at a time and can only finish about 6 per day, so I know that most that downloaded data will be discarded. A couple of my machines run 4 at a time, and one of them will only store a few extra work cycles at a time, so sometimes it runs out and does nothing. My most powerful machine runs 8 at a time, but I mostly run it on weekends, so it "loses" a large chunk of its work.

BOINC is probably all over the place because you keep aborting tasks.

---

I had the same problem and installed freeglut3, but the units still end in a computation error.

One of YOUR major problems is that few people are noticing problems. I think that is related to a pretty large lack of concern on the side of the people "managing" this system. Indifference transmitted, indifference returned.

The exact opposite: no admins on forum to interact, no interest of volunteers.
Here (and on Ralph) only one - dekim - participates to threads, and NOT very often. :-(

---

I'm pretty sure I have a fix for the glut/GL library issues that I am currently testing on Ralph. This is only related to the linux platform. I'm waiting a bit before we do another application update because one of the members in our group has been working on a cyclic peptide modeling protocol that he wants to push out as soon as possible. It is ready to test now so I'll be building the apps for testing on ralph today and hopefully, we'll push out the glut/GL fix on R@h later this week soon along with the other updates.

Related to wasted bandwidth, in our recent application update, I've added a new fragment file format that should significantly reduce bandwidth in the long run. The rb_ jobs are using these compressed fragment files (with the exception of a large benchmark we are currently running) and we will slowly transition the use of these fragments here for the whole lab.

It is ready to test now so I'll be building the apps for testing on ralph today and hopefully, we'll push out the glut/GL fix on R@h later this week soon along with the other updates.

We are ready on Ralph!!! :-)

---

It is ready to test now so I'll be building the apps for testing on ralph today and hopefully, we'll push out the glut/GL fix on R@h later this week soon along with the other updates.

We are ready on Ralph!!! :-)

I pushed out the glut/GL fix a couple days ago and am still waiting for the new protocol to be ready to test on Ralph. Should be soon.

Should be soon.

"soon" means??

---