To avoid another "flood" of WUs, as soon as the request (for 256200 seconds of work - that's what I currently have specified in my General preferences) was sent to the server, I *manually* clicked in BOINCmanager for: "No more work from Rosetta". I'm now watching 9 WUs being downloaded (preceded by 4.81). That would be correct if each ran for 8 hours. But earlier than today I had set my "Target CPU run time" value in the Rosetta preferences to 10 hours. Oh, well! Just another example of unexpected behavior, to keep in mind.

I have updated the FAQ on the time setting to try to better explain how this all works in practice. But the system MAY have got it right by giving you only 9 WUs. remember some of them may run longer than the time setting you have, because they will run to the completion time you asked for, but they will also always complete at lest one model. So if your settings would allow 9.9 models to complete, it will run shorter than you expect. But if one model would take 10.5 hours it will run longer.

Assuming you complete a number of WUs ok, the quota will rise very quickly

You did not catch what I was complaining about:
- The client asked for 256200 seconds (72 hours) of work. (correct)
- The SERVER sent 9 WUs (as though each would run for 8 hours; 9 WUs times 8 hours/WU = 72 hours total). IF the server had realized that my "Target CPU run time" was set to 10 hours, 9 WUs represent __90__ hors of work (instead of the 72 hours that had been requested). I had expected the server to send me 8 WUs -- 8 WUs times 10 hours/WU = 80 hours total (the closest multiple of 10 <the hours/WU> that exceeds 72). To me, that total of 9 WUs makes yet another case of TOO MANY WUs DOWNLOADED.
.

For today's download of work, I did NOT interfere in any way. And everything *was* done more or less correctly. Yesterday, I had changed (at the website) my "time between connects" to 5 days. I've drawn the following two conclusions from today's downlad:

(1)
When the client calculates the amount of work to ask for, it only looks at the 'ready to run' WUs on its queue, and DOES NOT factor in already-requested work that is still in the process of being downloaded. This affects me, because I have a slow connection and my downloads take a LONG time -- that's why I started this topic in the first place.

(2)
However, today the client asked for work only twice -- once when the connection was first established (by me manually un-suspending communication); and once when it realized that the "time between connects" at the website had been upped from 3 days to 5 days. (This second request was for slightly too much -- probably because not ALL of the first request had been downloaded by the time the second request was made.)

That is how I *wanted* the client to behave -- NOT to periodically re-request work while downloads were still in progress. The most likely explanation for it behaving properly is that it had now established a "history" that WUs on my system take 10 hours each (as set in Rosetta preferences "CPU time").

On the earlier runs that I complained about, the new WUs had *longer* run times than the WUs for which the client had "history" -- possibly it was having short __"history"__ values that caused the client to repeat and repeat and repeat its (ever diminishing) work request calculations at four minute intervals (each time causing MORE and MORE and MORE work to be scheduled for download).
.