Yes, I use a 0.2 day buffer out of respect for wingmen. However, when there are server problems I get nailed immediately.
Generally I just switch to another project until the problems are solved. If the servers are struggling, they don't need me hammering them for more work.
Thank you. I bumped mine up from .2 to .6 because it was taking so long to download that I had a lot of dead time waiting.
This is the only project I'm involved in since I don't feel I have enough resources to do much and this one interests me the most.
This is the only project I'm involved in since I don't feel I have enough resources to do much and this one interests me the most.
Joe
Yes, I prefer helping here most of the time, but I do enjoy finding Prime numbers as well. It helps that they have a well-behaved 32bit CUDA app for Linux for when BRP4 is down.
Just a positive personal experience status update:
I spotted the Technical News alert that BRP4 delivery had resumed early this morning (USA Mountain time). As I has a hungry GTX 460 host which had gone completely empty for half a day, I've had the chance to watch the download behavior to that host all day, and to another for quite a bit.
Using the individual file download Kbps as reported by boincmgr (and in my case relying on the version relayed by BoincTasks) as a measure, the day started at just about 20 (far better than 0.3 seen near the nadir of the trouble, but only modestly above the break-even level to keep these rigs fed), and somewhat irregularly but steadily has improved since to current typical values of 80 to 100.
The response to work requests has differed from the typical behavior before the down time. Back then, a request for a substantial number of seconds of work would often be partially met with an award of a few (or many) units and a 60 second postponement. After the 60 seconds, a new request would be made, for fewer seconds reflecting that already awarded (but generally not yet downloaded). Not infrequently the response to a particular request would be no work--as the buffer used by the award process had been emptied by other awards since the most recent refill).
Today, I've never seen a "second chance" request after a 60 second delay. On the other hand, first awards have tended to be larger--often more than 20, and on once case as high as 33. But whatever size was awarded, the 14400 second delay (related to my use of the app_info anonymous platform mechanism) would kick in.
Possibly this lack of second chance requests is a result of an intentional adjustment by staff hoping to avert excess simultaneous requests by a multitude of hosts with depleted queues.
If today's behavior for me is typical, things are really looking up. Of course, if I get good service because much of the world sees the problem user Paris reports three posts earlier in this thread, then all is not well at all.
***,but I've felt a quick turn around is a polite way to run.
That´s right. But you have exactly 14 days time to finish the work and send back the results. So I set "Maintain enough work for an additional" in my computing preferences to 4 days. That´s a good compromise, as I have sufficient buffer of work, time to finish the work and an acceptable turnaround time. Most server problems don´t last very long. So also in this case, which was a somewhat longer shutdown, I had sufficient work for another day in spare.
RE: RE: What kind of
)
Thank you. I bumped mine up from .2 to .6 because it was taking so long to download that I had a lot of dead time waiting.
This is the only project I'm involved in since I don't feel I have enough resources to do much and this one interests me the most.
Joe
RE: This is the only
)
Yes, I prefer helping here most of the time, but I do enjoy finding Prime numbers as well. It helps that they have a well-behaved 32bit CUDA app for Linux for when BRP4 is down.
Just a positive personal
)
Just a positive personal experience status update:
I spotted the Technical News alert that BRP4 delivery had resumed early this morning (USA Mountain time). As I has a hungry GTX 460 host which had gone completely empty for half a day, I've had the chance to watch the download behavior to that host all day, and to another for quite a bit.
Using the individual file download Kbps as reported by boincmgr (and in my case relying on the version relayed by BoincTasks) as a measure, the day started at just about 20 (far better than 0.3 seen near the nadir of the trouble, but only modestly above the break-even level to keep these rigs fed), and somewhat irregularly but steadily has improved since to current typical values of 80 to 100.
The response to work requests has differed from the typical behavior before the down time. Back then, a request for a substantial number of seconds of work would often be partially met with an award of a few (or many) units and a 60 second postponement. After the 60 seconds, a new request would be made, for fewer seconds reflecting that already awarded (but generally not yet downloaded). Not infrequently the response to a particular request would be no work--as the buffer used by the award process had been emptied by other awards since the most recent refill).
Today, I've never seen a "second chance" request after a 60 second delay. On the other hand, first awards have tended to be larger--often more than 20, and on once case as high as 33. But whatever size was awarded, the 14400 second delay (related to my use of the app_info anonymous platform mechanism) would kick in.
Possibly this lack of second chance requests is a result of an intentional adjustment by staff hoping to avert excess simultaneous requests by a multitude of hosts with depleted queues.
If today's behavior for me is typical, things are really looking up. Of course, if I get good service because much of the world sees the problem user Paris reports three posts earlier in this thread, then all is not well at all.
RE: ***,but I've felt a
)
That´s right. But you have exactly 14 days time to finish the work and send back the results. So I set "Maintain enough work for an additional" in my computing preferences to 4 days. That´s a good compromise, as I have sufficient buffer of work, time to finish the work and an acceptable turnaround time. Most server problems don´t last very long. So also in this case, which was a somewhat longer shutdown, I had sufficient work for another day in spare.
Kind regards
Martin