She walks all over me in the expensive Italian stiletto heels I buy for her. She looks so good and hurts so bad and yes, I love it

Rob,

Thank you for your help. I am using FightAIDS@Home, and I have only had checkpoints at 33% and 66%. It takes hours to get here, and I am using Windows XP Pro.

And secondly (to my embarassment), I didn't know windows had such a feature. I have only seen it on one or two machines in my lifetime and I had forgotten about it. So I thought it was stand-by. So I apologize for my first reply.

One possible remedy for Nuzz604 is to attempt to establish a time frame for when checkpoints will occur on what ever project he is crunching. Because I only have a limited amount of memory I can only crunch on FAAH. My machine is not too fast so the FAAH units take about 24 hours plus/minus a couple to crunch. There are a number of different checkpoints in the FAAH units as Sekerob has so patiently and eloquently explained (16%, 33%, etc. or even no checkpoint at all). By knowing about what kind of wu my machine is crunching and paying a little bit of attention to where it is I can regulate when I can exit the application and lose the least amount of time. Granted, this is not a seamless couchpotato approach, but it only involves a decision a couple of hours prior to my shutting down at night. Sure, it is not like the 24/7 machines and is not applicable to the no checkpoint units, but still gets most of the jobs completed in a timely manner. Hope this is helpful.

Joe

ps to Dagorath: I always heard it as "Grass does not grow on a well used playground"

The reality of the situation is that relatively few machines need more checkpoints, just slow machines that canot be left on long enough. The numbers of those machines decreases steadily. Now with the new, low power consumption CPUs coming onto the market and electricity prices going through the roof, the "average machine" is going to get even faster. It's just not worth spending time writing extremely complex code for just a handful of slow, old CPUs that have 1 foot in the trash bin already. It makes far more sense for those CPUs to be put on projects that have smaller work units or work units with more checkpoints. Hibernation is always an option too and I am working to make the "how to hibernate" information easier to find, easier to read, etc. Look for an article on hibernation at WCGwiki this weeken if not later today.

In terms of getting more work done, it makes far more sense for the programmers to spend their time writing optimised code that takes advantage of features found in new CPUs, SSE2 for example. Yes, WCG can afford to exclude old, slow machines because they have 300 new members joining every day, 9000 per month, every month.

I think those who request more checkpoints in FAAH units don't understand the complexity of what they want. It's a million times more complex than saving a file in a word processor, for example. It would be nice if it were not that complex but it is and that fact isn't going to change. It has absolutely nothing to do with bad programming.

I find WCG listen very well. That doesn't always make it possible for them to meet the demands put to them.

All grid projects have a certain amount of attrition. This is caused by people who never got crunching at all, by devices that go offline and are never corrected, and by systems that are retired or reformatted and never have the grid software replaced. Loss due to actual dissatisfaction is probably very small. Such people usually share their unhappiness, whether there is any logic or sound reason behind their problem or not.

WCG cannot and MUST not compromise the science for the sake of massaging the ego of a few members. That said, they want to keep everyone happy if they can. And I'm sure you have noticed that we are past the large work units, and the current FAAH work units checkpoint a little more often.