I don't know much about the configuration of the Seti db, but right now I only get 10 wu's at a time and when the servers shutdown, that only leaves me a day and a half of work for my dual processor. I have to sit doing nothing for the other day and a half. Anything that I can do about that?

Allen

Allen:

To help prevent database/server crashes due to overload after the 3-day outage, there are TEMPORARY limits in place for downloads, based on how many WUs your computers already have in progress. Last time I checked, they were at 8 per cpu core, 48 per gpu, and 1000 per host. Since (per the public data on your S@H profile page) you have more than 8 WUs in progress on each of your cpu's, that's all you can get right now. You may get some more as you complete WUs, or as Jeff raises the limits.

Jeff has been raising the limits periodically since the servers came up on Friday morning, and he has said he will remove all temporary limits by Monday morning. Then you should be able to load up for the next 3-Day outage.

More current info is available in several threads running in the Number Crunching section of the Forum.

The problem people were having was from the combined limit. The seperate cpu and gpu limits seem to have functioned admirably, and raising them as you see fit sounds like a great plan. It keeps demands manageable.

First, thanks for the hard work and for keeping us updated! All of my cores are now running hot, straight, and normal and so of course I'm content for now.

I would like to add my voice to two requests already made here and in other threads:

- It has been suggested that it should be possible to set up the scheduler so as to NOT assign VLAR work to GPU's. If so it would go a long way toward keeping the gears greased even with the current somewhat lower limits. Not having to reschedule VLAR's from GPU to CPU on the local client would be a big help keeping the GPU's running during the 3 day outages and should also keep the Application Details on your servers much more accurate.

- Would it not be reasonable to raise limits or drop them altogether SOONER than 24 hours before the outage? As I'm sure you noticed last week the bandwidth was totally saturated from Mon to Tues A.M. and many WU's that had been scheduled were never able to come down before the outage began. They did DL quickly after the outage but by that time some machines were out of work. If necessary to help with bandwidth limits (and if it doesn't mean an unreasonable extra workload for your team) you might increase limits in stages starting 48 hours or even more before Tuesday.

Thanks Jeff
My main bitch all along has not been the outages, lack of work, download limits etc. etc. It has been the lack of information and updates from SAH HQ as to just WTF is going on down in the Berkeley bunker.

The information and feedback you have posted over the last 2 weekends goes a long way towards filling that void and has been greatly appreciated.

Better. Thanks very, very much. It's been a hassle manually rescheduling little bits at a time. It got to the point that I would download 3 WU, reschedule, then download 3 more; over and over. The good news is I now have as many CUDA WU's as I did when the outage started last Tuesday. That's a definite improvement.

VLARs are back, so all 40 of my allowed CPU WU's are VLAR again. Although I'm allowed 320 GPU WU, I was only able to download and reschedule 240 before hitting the CPU threshold. Unfortunately, that's 80 WU's I'll have to fight for on the buffet line tomorrow. :(

I think the cricket shape we are trying for is that of a bath tub. High during the Friday opening and the Monday queue filling but less than max on the weekend. How deep that tub is is where the tuning comes in.

A few thoughts (The Server Stats being down for a while means a fair bit more guesswork than usual).

The intial limits of
CPU 5
GPU 40
Total 140
resulted in about a 4 hour period of full bandwidth being used.

changing them to
CPU 6
GPU 48
Total 150
resulted in another 4-5 hour burst.

The change of the total limit to 1,000 didn't appear to have much of an effect, about an hour or 2 (if that) of heavy traffic.

changing them to
CPU 10
GPU 80
Total 2000
resulted in a 3 hour period of heavy traffic.

changing them to
CPU 20
GPU 160
Total 4000
resulted in a 4-5 hour burst of heavy traffic (just dropping off now).

Depending when the servers are fired up, and whether the system for adjusting the limits can be automated, it should be possible to be at the present settings (CPU 20, GPU 160, Total 4000) by Friday night. Ideally the limits would be tweaked gradually over the weekend to top up caches in small bursts so come Monday when the limits are removed all caches (even the largest of the large) would be full by the time the next outage is due.
And as the change in total limit only from 150 to 1,000 had such a small effect it'd be worth trying things without it in place from the start after the next outage.

The only thing i find odd is the AstroPulse behaviour. I can't remember who pointed it out during the last outage, but the short bursts of network traffic that occur after everyone has reached the limits set at that time is due to AP downloads (Scarecrow's graphs show the AP Ready to Send queue slowly building up, then draining rapidly at the same time as the bursts in network traffic).Grant
Darwin NT