School (Feb 22 2011)

Umm, isn't it time to consider cutting down the mandatory wait time after a scheduler update? (to something less than 5 minutes...)
____________
.

Hmm, someone must be calling into the lab over the weekend and loading new tapes as there are both MB and AP units available, and a few more of each to be split from loaded tapes. May I thank that person for going "above and beyond".
____________
Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Umm, isn't it time to consider cutting down the mandatory wait time after a scheduler update? (to something less than 5 minutes...)

I'm not sure, but I suspect the mandatory wait time is there for limiting bandwidth issues. Regardless, it's something I can live with. (Don't want to hammer the servers too much while things are running as smoothly as they are now, after all.)

I was not suggesting a return to the 11 second delay - just somethin' shorter than 5 minutes! (like 2-3 minutes...)

IIRC, the 5 minute delay was implemented when the project was taking 3 day outages, to (yes) decrease the number of simultaneous connections after the restoration of downloading... but now that the three day outage weeks are over, (we hope!) it should be time to cut back that delay.
____________
.

The 5-minute delay was to reduce the load on jocelyn when we were waiting for the new servers to be spec'ed, ordered, and installed.

I say leave be on the 5 Min delay for another 3-4 weeks to get a better feel on how things work when we have no problems. We have no need to rush into things. I say we take it slow before making changes.
____________

The 5-minute delay was to reduce the load on jocelyn when we were waiting for the new servers to be spec'ed, ordered, and installed.

But given the load we're putting in the system at the moment - with the cricket graph maxxed out for seven of the last eight hours - I'd suggest that it would be wise to keep things tamped down for the time being.

Remember that the problem was scheduler request files fighting their way through the upload and download traffic, and the result - at that time - was ghost WUs, which certainly caused more problems than they were worth. Now, with the more powerful servers proving themselves capable of handling the limited number of 'resend lost results', things are running a lot smoother - but I see no benefit in increasing the number of lost results needing to be resent.

And I haven't seen any sign myself, or heard any complaints from the boards, suggesting that a five-minute delay is too long. Most regular posters will be running caches measured in days, not even hours - having to re-request two or three times isn't going to make any noticable difference to them.

Another here running only a little computer and things couldn't be better. Before boinc would try to connect to the server what seemed like once a minute for HOURS at a time with no success, now if it can't connect to the server it will try again five minutes later and I get another task. Woo and yay.

...
If you really want to connect sooner you can always force the issue manually with the update button.

I'm very happy with the 470 & 480 FERMIs, you can run more then 1 WU at a time,
depending on # of usable 'cores', I run 3 on the 480, whithout it getting too hot or producing errors.
And 2 on the 470, even 3 are possible, but it's getting quite hot, doing so.

Some 'other Projects', like GPUgrid, can (only?) be ran on FERMIs.
(When looking at some results, unfortunatly, most of the 200 series cards, are
producing a lot errors!) Took my GTS250 off GPUgrid, as I did not get any work.
Even when running SETI MB, using the LUNATICs V0.37 Installer, is gets very hot
and needs an additional fan and one side off it's case.

And about the extended, or 5 minutes delay, I haven't noticed, getting less WUs
or other problems and there is always the UPDate Button, but BOINC 6.10.56 & 58 (XP64), is perfectly capable of doing it's job.
(If you just let it run, which is just 1 of it's many functions)

Also haven't noticed any problems, reporting, or UP- and Down-Loading.
And haven't been out of work, still using a 4 day cache and only displaying
active tasks since this can take some extra load on the CPU, sometimes
5% or more, depending on the amount of WU's.
(A CPDN WU, FAMOUS or otherwise, takes, after zipping 4 minutes to UPload,
@ 5 or 6Kbit/sec! and therefore also suited for Dial-Up Connections, my LT, still has a 'Old style' MODEM, which can be very usefull, ofc. also Ethernet and WLAN)
____________


Knight Who Says Ni N!, OUT numbered.................

Here's my situation, and why I'd like that 5 min delay reduced to 2 (or less ;-) )

I only connect to SETI once a day, with three (soon to be 4...) computers in my morning. (which happens to be the same as morning at the SETI labs...) If I get the dreaded "no work sent" when I request work that mean that I'm twiddling my thumbs waiting out the 5 minutes when I could be doing somethin' productive, in a BOINC sense...

This occasionally has made my computer(s) miss getting any WU's on Tuesdays. (yes, I run that close to 9 AM Pacific time... and sometimes the lab starts the outage early, like this week!)

This whole Method of Operations started 5 years ago, when I was connecting to the web (and SETI...) with a dial-up.
____________
.

My 5 machines have a combined RAC of over 80,000, putting me at over 1000 WU's a day on average. I'm having no problem at all keeping their caches full. Even Todd with his 600,000+ RAC (Easily over 7500 WU's a day) never has complained about keeping the cache topped off, even with the 5 min delays. The only thing limited by that 5 minutes is requesting new work.

I notice that you are running a number of GTX 460s.

Are you happy with them, generally? Looks like you are clocking-in at about 20k RAC, which is higher than I thought that card's production would be.