Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
![]() |
World Community Grid Forums
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 25
|
![]() |
Author |
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Albeit, MCM 7.26 being a good testing ground [other sciences too], detecting an amount of bad time keeping. This device runs at about 80-90 efficiency [heavily 'used'], but only after 15 minutes, a 5 hour running MCM shows 98%. The second MCM displays more CPU than Elapsed time.
----------------------------------------7.26 mcm1 MCM1_0000173_1699_0 05:13:14 (05:07:31) 98.176 89.830 00:46:16 21-11-2013 05:42 09d,18:29:47 Running [1] 00:03:57 44.38 MB 81.93 MB World Community Grid 5.10 simap 20130911.833040_1 01:15:02 (01:14:19) 99.052 96.071 00:02:59 21-11-2013 04:26 06d,17:13:38 Waiting to run [0] 00:00:00 7.62 MB 14.05 MB boincsimap 7.26 mcm1 MCM1_0000177_6822_0 00:33:14 (00:36:20) 100.000 9.115 06:11:07 21-11-2013 10:18 09d,23:05:02 Running [1] 00:04:16 42.84 MB 80.37 MB World Community Grid Patience grasshoppers, will keep them running, now 70% CPU time, and await the Result Status page verdict when reported. edit: If this works, could be CEP2 might become viable for more volunteers. Set X percent aside for BOINC, and the other Y percent is always at user instant disposal, without latency... a weak theory. [Edit 1 times, last edit by Former Member at Nov 21, 2013 10:21:42 AM] |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
From the mail list [and now testing]
I have a .32 build I'm putting together that will contain the sub-second CPU throttling and app config changes. .32+ will be part of a second 7.2 public release cycle. WCG wants a new WCG branded client with sub-second CPU throttling and the app config changes. I expect these two changes will be the only major changes going into this next public release. I think we can get it tested and ready for release before next year. The whole second and sub-second throttling turns out to be king of the old whole seconds divided by 10. If entering 90 80 70 60% etc you get a smooth performance graph [at normal update rate]. If you enter 85% e.g. you get a little of running at 90 alternating with a little at 80. |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Nasty side-effect, if it is, suddenly since starting to use the sub-second throttling at 90%, the system clock has started to run fast... every few hours it's set back by 1 minute or more.
----------------------------------------79 23-11-2013 11:56 New system time (1385204125) < old system time (1385204185); clearing timeouts 203 23-11-2013 14:55 New system time (1385214854) < old system time (1385214924); clearing timeouts 307 23-11-2013 18:54 New system time (1385229170) < old system time (1385229253); clearing timeouts 358 23-11-2013 21:52 New system time (1385239899) < old system time (1385239969); clearing timeouts Ever only seen adjustments forward, and only once in a blue moon. edit: added one more 'clock change' record. [Edit 1 times, last edit by Former Member at Nov 25, 2013 9:33:14 AM] |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Well, on Linux with .33 it's still the old behaviour.
|
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Haha, .34 is out... probs with the sub-second throttling [which was barely tested before .33 was declared 'recommended']. Already had 2 fresh build updates of .33 on my Linux-64 sys so... stand back and wait, unless you have the 'must have' urge ;)
|
||
|
|
![]() |