Pretty amazing to sit on a water diet only for the duo and this morning 2 of them are at bottom. Suspended the RTS jobs, but those running, since they need only 2 resp. 33 more minutes and then away they are on their way. Assuming they live by the same 12 hour cut off rule, the TTC shows as 12:30:05 hours.

The bandwidth issue has been discussed by knreed how that will be dealt with. No messages here though, given that the jobs ran generate enough continues traffic to allow BOINC to maintain the bwdown value above the 128mB warning level. (802.11N flies here)

NixChix, presume you meant the Progress percent... whilst typing slow and checking things, the Elapsed time counting started immediate, and after about 4.5 minutes the CPU time counter started too combined with little % progress steps. Did notice that during the model setup the system got slow responsive, so think that I will allow the 2 to run concurrent for a little and observe impact... throttle set at 100%, and after maybe set the ThreadMaster GUI ** to allow 90, 80, 70% to see how impact manifests itself. Will monitor also with Process Explorer on the system uses, PFs Delta etc, how efficiency keeps up. Think with the forewarning by armstrdj, OPT-IN is when really choosing to run them. Process Explorer took 95 seconds to load, so know what you get into ... 12 minutes elapsed, 6 minutes CPU time, 0.892% progress for starters

Lets crunch

:D

** still the best science-app level CPU cycle permission *smooth* throttle controller to be had for BOINC on windows. The default is set to not allow more than 40% of system (80% of core) and that's what it's running at now. Switching up to 100% this moment to see how it impacts browsing and typing messages... update later.

It seems at 25% it takes 3 hours to complete.

12hrs Windows VS 9hrs Linux - what a big difference

To add to the 12 hours showing in TTC, from running many on Linux we know that the % progress is tuned to exactly 12 hours run time, not the real progress. Maybe armstrdj could revisit that bit so it takes number of jobs completed also into consideration. 15 of 16 jobs done after 4 hours does not make 12 hours to be very probable and highly impacts the client scheduler and buffering behavior (and a roller coaster DCF when mixing with other sciences).

6 minutes is quite moderate or 3 minutes per hour aka 95% efficiency. Wish my quad Linux box could show that for CEP2, particular when using the system.

edit: monitoring from remote with 2 running concurrent and 2 DDDT2 on the other cores, showing exactly 30 minutes difference after 5:46 hours wallclock on one job and the other 34 minutes after 5:15... 3 minutes per hour for the moment would be an improvement in my book... my centrino shows 17 minutes gap after the 2:14 hours wallclock, running at 100% throttle and system in use doing multiple things... Firefox ate 2:39 hours since it was last loaded yesterday morning.

Download a couple of HPF2 jobs... that will pump it up. Download speed is highly affected by many short files which really never get to reach max speed, so by forcing a few jobs to come that are known to have bigger downloads, BOINC will adjust, temporarily. Mine is measured 266kB presently off from a recent mix of C4CW and HPF2.