(Maximum disk usage exceeded)

Hopefully the dramatic reduction in the size of the WUs they made will help your download times to improve and counter balance the negative of the shorter deadlines that are necessary in order to get results back for CASP.

If you describe your proxy situation a little further, perhaps there are some steps people could suggest to make it much easier for you to connect as well.

The percent complete is not necessarily linear. If you change the time setting while the work unit is being processed it will effect the percent complete. ... The time to completion is almost never correct.

My "GUESS" would be that it is more likely a look up table for different machine types and speeds with some kind of correction factor. But that is only a Guess.

I just added more time options as requested.

More often than not, the WUs finish before your preference. The golden exception to that being when it takes longer than your preference to complete model 1.

Well I guess I am having some trouble understanding your situation. If your queue is set to 6 days that is 144 hours assuming your crunch 24/7. 144 divided by your 10 hour time setting is 14.4 WUs. The system should have given you 14 WUs but if it gave you 15, which is possible, then the system would have probably gone into EDF mode right off. But lets assume it gave you 14, and as you say they are all 12 day workunits. All things being equal that should not push the system into EDF mode in and of itself. But change any of those conditions and it could. And yes the crashed WUs would affect a change in the expected run time but it should make it shorter, which might cause you to get more than the 14 WUs and push you into EDF Mode.

On another thread, it was said: 'if a project deadline is less than double the cache size, the box will run in EDF mode'.

That is correct, and that is what I thought had happened in your case as the manual connect you made 2 days after the prior connection would have "reset" the time frame for determining when the 6 day connection setting would apply - basically making boinc think it had to fit 6 + 6 (for 2 normal connections) days worth of work into 2 + 6 (the manual connection plus the next normal connection) days on the calendar. Since it occurred before that manual connection, it's something a bit more complex than that, though.

This can happen if some number of the workunits exceed the expected runtime. For example if a number of 10 hour WUs actually run for 10:45, your system would begin to realize that they might all run that way, and you would then possibly be over committed at the early part of the queue. But as the queue runs, this would change. What changed in this case was a few WUs crashed and reduced the workload in the queue.

This is just one of those weird little oddities that boinc has. Keep in mind that when you give it a "connect every" setting, it assumes that it will actually be restricted exactly to that time frame.

In your case, with a 6 day connect setting, once boinc has gone a couple days into the queue, if it is allowed to actually reconnect again it will determine that it must finish everything that is due in less than about 10 days before the next connection that will occur in 6 more days days - because it assumes that after the next connection it won't be allowed to connect again until 6 days later (and after the expiration of some of the work units).

I see from your results that 2 of the work units downloaded on the 12th were reported on the 14th. At that point, boinc assumes 6 days till the next connection (20th)- then 6 days after that for another (26th). Since that connection was made after the time of day for the workunits due on the 26th, boinc would assume that all work units due on the 26th would now have to be finished before the 20th - otherwise the connection (based on a strict 6 day connect interval) on the 26th would have occured about an hour too late to report those work units due on the 26th.

We have found the problem, and are resubmitting the jobs with a fix. There are still a few workunits with the following prefix out there that you can expect to fail very quickly:

HOMSdt_homDB0??_1dtj

this should not happen with the next batch.

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

The larger the max cpu time setting, the less frequent communications with the project servers, and the less likely the system will be overwhelmed with communications requests such as happened when we were handed out lots of 15 min WUs and we became a distributed denial of service attack on the project servers.