Folding Forum

ChristianVirtual wrote:Since the stats has no direct impact on science the resources are set elsewhere. But yeah, an automatic reboot every day once the stats are pushed to the web server might be a low-cost mitigation action.

While what you say is technically true, you are dealing with a large set of volunteers. These volunteers are motivated by many things, one of which is the feedback they get about their contributions via the stats/points system. If that weren't a motivator, there'd be no need for stats.

One thing that is disheartening then, is the apparent lack of priority to maintaining a steady stats system. My enthusiasm for folding diminishes every time I see a drop in my daily points output, I've got to check up on my system to see:
a) is my hardware functioning well
or
b) is there a sudden drop in availability for WU's for my hardware
or
c) most times lately it's been the stats system being down again.

There are many aspects to the science that is being done by the Folding@Home program. Maybe the Folding@Home program could use some expertise in the fields of social/behavioural/motivational sciences to increase the enlistment and enthusiasm of volunteers to Folding@Home!

peace,
Grant

rickoic wrote:How about in the old tape backup days a guard making his rounds places his magnetic flashlight on the storage cabinet in order to check in at his check in point (which took two hands to do) and erased part of the tapes.

In the late eighties, one of Wang's major City of London clients found that placing tapes on the 600MB disc drives was not a good idea for the same reason. I was second-level engineering support in the City at the time so knew all about it....

To keep things on topic, the outage is now 48 hours old and there are faint signs of life. EOC has had some sort of update but it's only one WU for my team where I expect eight to ten.

snapshot wrote:Knows when a weekend comes up and when there is a shortage of IT personnel to fix the problem quickly.

What really happens is that the cleaner comes in and unplugs the server so she can plug in her vacuum cleaner. I think it was in the mid-eighties when I was at Datapoint in the UK that this actually happened.[/quote]
All outlets except those under the raised floors were removed from our computer room. (Cleaning crew had to get a long extension cord that reached outside.)

Looks like Stanford update to stats happened at mid point when other stats programs were updating and they only managed to pick up first small batch of updated stats. Whole stats update should appear in the next scheduled update.

The latest word I have is that the stats server is back online. It may take a couple hours to run through all of the updates.

Bueno!

Yes, my individual stats had partially caught up after the 11:00 PST run and look pretty much up-to-date after 12:00 so I'm hopeful that EOC will catch up at 13:00.

Joe, is it possible to find out what the actual problem was? I'm sure I'm not the only one who'd like to know.

bruce wrote:

snapshot wrote:

rickioc wrote:Knows when a weekend comes up and when there is a shortage of IT personnel to fix the problem quickly.

What really happens is that the cleaner comes in and unplugs the server so she can plug in her vacuum cleaner. I think it was in the mid-eighties when I was at Datapoint in the UK that this actually happened.

All outlets except those under the raised floors were removed from our computer room. (Cleaning crew had to get a long extension cord that reached outside.)

Of course, the vacuum cleaner should not be in the computer room. They should use a long vacuum hose. Without propping the door open to let in dirty air.

I worked on a project where a rack mounted minicomputer was connected to some development machinery. A hardware mod involving a drill was required. We did manage to suggest that the programmer saved her work and logged off before we started the drill and crashed the minicomputer.

klasseng wrote:

ChristianVirtual wrote:Since the stats has no direct impact on science the resources are set elsewhere. But yeah, an automatic reboot every day once the stats are pushed to the web server might be a low-cost mitigation action.

While what you say is technically true, you are dealing with a large set of volunteers. These volunteers are motivated by many things, one of which is the feedback they get about their contributions via the stats/points system. If that weren't a motivator, there'd be no need for stats.

One thing that is disheartening then, is the apparent lack of priority to maintaining a steady stats system. My enthusiasm for folding diminishes every time I see a drop in my daily points output, I've got to check up on my system to see:
a) is my hardware functioning well
or
b) is there a sudden drop in availability for WU's for my hardware
or
c) most times lately it's been the stats system being down again.

There are many aspects to the science that is being done by the Folding@Home program. Maybe the Folding@Home program could use some expertise in the fields of social/behavioural/motivational sciences to increase the enlistment and enthusiasm of volunteers to Folding@Home!

peace,
Grant

Ditto what klasseng said.

One of my primary roles (in addition to administering this site) seems to have become advocating for the Donors an reminding software developers, scientific researchers, long-range-planners, etc. etc. of what Donors thing is important.

I don't expect you'll get a detailed answer to "What was the problem?"

The discussions above remind us of one part of the answer: Bureaucracy. Molecular Biologists don't administer servers, the IT department does. Bottom line: The stats are working again and the Ticket has been closed.

I'd have to ask the person who opened the ticket to ask his boss to contact the boss of the IT team to find the technician that rebooted the server why it needed rebooting. Getting a detailed answer wouldn't change much of anything, but pointing those same people to this 7 page topic and asking to have something done about the general unreliability of the stats system would be more useful.

I wish they were more reliable. I mean I know they don't go down often, but I use the stats to keep track of my boxen. If I see something not right with my stats then I immediately think something is wrong on my end and I start trying to figuring out the problem is which in most cases it's a crashed client or something else on my end that needs attention. Granted it's relatively easy to spot an issue with the stats (when no one else gets updates) but during the time the stats are down I am mostly blind as to what my setup is doing without physically checking on them individually to make sure they're operating properly. Waiting on the stats to update periodically to spot issues on my end takes long enough as it is. So anytime the stats are down I could have an issue going on for a while and not know about it.

Skillz wrote:So anytime the stats are down I could have an issue going on for a while and not know about it.

You shouldn't have to check them individually by visiting each one.
HFM gives you a quick overview of all your networked systems and contains a lot more information that just your recent total points.
Also, FAHControl can monitor and manage any FAH system that is networked.

If you're participating in a points race, then it's important to monitor your points, but to monitor for troubles, it's a very blunt tool compared to these other two methods.

Note that recent HFM releases do have limited control (per slot stop/finish/fold).
IMO HFM is the best general purpose monitoring tool, but FAHControl is also necessary for configuration and log filtering.

bruce wrote:One of my primary roles (in addition to administering this site) seems to have become advocating for the Donors an reminding software developers, scientific researchers, long-range-planners, etc. etc. of what Donors thing is important.

I don't expect you'll get a detailed answer to "What was the problem?"

The discussions above remind us of one part of the answer: Bureaucracy. Molecular Biologists don't administer servers, the IT department does. Bottom line: The stats are working again and the Ticket has been closed.

I'd have to ask the person who opened the ticket to ask his boss to contact the boss of the IT team to find the technician that rebooted the server why it needed rebooting. Getting a detailed answer wouldn't change much of anything, but pointing those same people to this 7 page topic and asking to have something done about the general unreliability of the stats system would be more useful.

All you should need to do is ask the person who raised the ticket to look at the closure details. If the techs aren't filling them in adequately then that's a different problem.

They sure seem to be acting up a lot as of late...