Message boards : Number crunching : Stuck at 100%
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3

AuthorMessage
Peter Hucker

Send message
Joined: 12 Aug 06
Posts: 43
Credit: 80,111
RAC: 0
Message 32294 - Posted: 5 Sep 2017, 21:52:17 UTC

I've noticed that although my config file says 5GB, that's it's still using 4.2GB for 2C and 5.8GB or the 3C (if you believe the "working set size" in the task's properties). Seems to be making it work though....
ID: 32294 · Report as offensive     Reply Quote
Profile Yeti
Volunteer moderator
Avatar

Send message
Joined: 2 Sep 04
Posts: 321
Credit: 44,448,633
RAC: 5,353
Message 32296 - Posted: 5 Sep 2017, 22:47:49 UTC - in response to Message 32294.  

I've noticed that although my config file says 5GB, that's it's still using 4.2GB for 2C and 5.8GB or the 3C (if you believe the "working set size" in the task's properties). Seems to be making it work though....

Settings in app_config.xml don't affect "working set size", but memory settings inside the VM


Supporting BOINC, a great concept !
ID: 32296 · Report as offensive     Reply Quote
Harri Liljeroos
Avatar

Send message
Joined: 28 Sep 04
Posts: 260
Credit: 8,142,150
RAC: 13,891
Message 32300 - Posted: 6 Sep 2017, 6:25:44 UTC - in response to Message 32296.  

I've noticed that although my config file says 5GB, that's it's still using 4.2GB for 2C and 5.8GB or the 3C (if you believe the "working set size" in the task's properties). Seems to be making it work though....

Settings in app_config.xml don't affect "working set size", but memory settings inside the VM

Which means that you can not trust Boinc to control used memory correctly if you want to reserve some memory for programs running outside Boinc.
ID: 32300 · Report as offensive     Reply Quote
Profile Yeti
Volunteer moderator
Avatar

Send message
Joined: 2 Sep 04
Posts: 321
Credit: 44,448,633
RAC: 5,353
Message 32301 - Posted: 6 Sep 2017, 6:35:16 UTC - in response to Message 32300.  

Which means that you can not trust Boinc to control used memory correctly if you want to reserve some memory for programs running outside Boinc.

Nope

The Scheduler sets the "WorkingSetSize", but the app_config.xml may override this on the client. So, "WorkingSetSize" is a clear defined value that always can be calculated.

You are changing / overriding the config with the app_config and now it is your responsibility to keep an eye on the memory.


Supporting BOINC, a great concept !
ID: 32301 · Report as offensive     Reply Quote
computezrmle

Send message
Joined: 15 Jun 08
Posts: 522
Credit: 5,480,938
RAC: 19,292
Message 32302 - Posted: 6 Sep 2017, 7:11:09 UTC - in response to Message 32301.  

A deeper explanation regarding working set size and rsc_memory_bound can be found in the BOINC wiki:
https://boinc.berkeley.edu/trac/wiki/MemoryManagement

It also explains (section: Client CPU scheduler) why sometimes a "waiting for memory" situation occurs.
ID: 32302 · Report as offensive     Reply Quote
Harri Liljeroos
Avatar

Send message
Joined: 28 Sep 04
Posts: 260
Credit: 8,142,150
RAC: 13,891
Message 32401 - Posted: 12 Sep 2017, 19:56:38 UTC

A 2 core Atlas task is running on my computer now and the Working set size in Boinc is showing 5300.00 MB. So this is good.
ID: 32401 · Report as offensive     Reply Quote
Peter Hucker

Send message
Joined: 12 Aug 06
Posts: 43
Credit: 80,111
RAC: 0
Message 32403 - Posted: 12 Sep 2017, 20:09:00 UTC - in response to Message 32401.  

Should I eventually remove the config.xml I created as instructed above, once the programmers correct the error? Otherwise it'll prevent any changes from the server side?
ID: 32403 · Report as offensive     Reply Quote
Toby Broom
Volunteer moderator

Send message
Joined: 27 Sep 08
Posts: 413
Credit: 108,248,295
RAC: 154,346
Message 32404 - Posted: 12 Sep 2017, 21:14:08 UTC

If you set your web config to 3cores, then the working set size in boinc will be 5GB, you could try 4 core on the web. The calculation for the web 2.6 GB + N * 0.9 GB. (it waas just updated)

Since you have an app_config it's just for BOINC's calacualtions.

They will make some changes as per discussion in the other threads
ID: 32404 · Report as offensive     Reply Quote
Peter Hucker

Send message
Joined: 12 Aug 06
Posts: 43
Credit: 80,111
RAC: 0
Message 32405 - Posted: 12 Sep 2017, 21:18:05 UTC - in response to Message 32404.  

f changes are be5ng 0ade, '33 d5sab3e the c6nf5g f6r n6w and see 5f the s c60-3ete -r6-er3y Wthey were fa535ng after 1* 05n4tes bf6re*

ARGH! Numlock left on!

If changes are being made, I'll disable the config for now and see if the WUs complete properly (they were failing after 10 minutes before).
ID: 32405 · Report as offensive     Reply Quote
hvtl

Send message
Joined: 6 Jan 16
Posts: 1
Credit: 55,208
RAC: 76
Message 33212 - Posted: 5 Dec 2017, 9:16:36 UTC - in response to Message 32196.  

I have the same thing lot of times. It begin well then at the end it indicate something like 30 seconds remain the an hour after 29 secondes then one our after 28 etc. to 0 secondes then the limit date pass over and the task still take CPU. So if I understand what has been said my computer worked for nothing rather than using power for an other project. Could you fix it a the LHC@Home project ? when it fails then stop it and get back the result.


Yes it's Atlas.

Enormous differences:
CPU time at last checkpoint: 9m5s
CPU time: 9m5s
Elapsed time: 1d6h34m50s

I've noticed these multicore tasks never use all 4 cores anywhere near fully (probably about 30% overall CPU usage), but those figures look vastly out, so I guess it's not doing anything. However, although I didn't check the above last night, the runtime was about 15 hours, and the CPU time must have been 9 minutes or less, and the percentage was still climbing slowly (around 99.5%).

Computer: Black
Project LHC@home

Name tbdMDm4QV6qnSu7Ccp2YYBZmABFKDmABFKDmXNGKDmyecKDmhyp1bn_0

Application ATLAS Simulation 1.01 (vbox64_mt_mcore_atlas)
Workunit name tbdMDm4QV6qnSu7Ccp2YYBZmABFKDmABFKDmXNGKDmyecKDmhyp1bn
State Running High P.
Received Mon 28/08/2017 3:34:35 pm
Report deadline Mon 04/09/2017 3:34:35 pm
Estimated app speed 2.32 GFLOPs/sec
Estimated task size 16,020 GFLOPs
Resources 4 CPUs
CPU time at last checkpoint 00:09:05
CPU time 00:09:05
Elapsed time 01d,06:34:50
Estimated time remaining 00:00:00
Fraction done 100.000%
Virtual memory size 127.18 MB
Working set size 5,800.00 MB
Directory slots/1
Process ID 7104
ID: 33212 · Report as offensive     Reply Quote
Previous · 1 · 2 · 3

Message boards : Number crunching : Stuck at 100%


©2018 CERN