| Author |
Message |
|---|
|
|
|
I have had 4 errors today with error -177. In the BM I am getting the message ''Aborting task .... exceeded disk limit:25.75MB>9.54MB''. The tasks completed seem to be taking longer now too. Seen a few other Linux hosts with this too but no windows? Something changed?
____________
  |
|
|
|
|
I have had 4 errors today with error -177. In the BM I am getting the message ''Aborting task .... exceeded disk limit:25.75MB>9.54MB''. The tasks completed seem to be taking longer now too. Seen a few other Linux hosts with this too but no windows? Something changed?
A new LLR was released using a new gwnum-lib version which should be faster but that is also considerably larger (more FFTs, etc.) than the old application. Currently the PPS LLR and the SGS LLR app for Linux have been updated.
____________
|
|
|
|
|
|
Ah,yes I see the application 6.03->6.06 now. I noticed in the Stderr output that the errors are using 6.03 wrapper! Example. Does that mean all my tasks that were created before the update are going to error?
Also, the 6.06 seems to take about 9-10% longer on my system!
____________
|
|
|
|
|
Ah,yes I see the application 6.03->6.06 now. I noticed in the Stderr output that the errors are using 6.03 wrapper! Example. Does that mean all my tasks that were created before the update are going to error?
Also, the 6.06 seems to take about 9-10% longer on my system!
BOINC needs more space on your hard disc. You should check your settings and/or free up some space on your drive.
By the way: You might get some calculation errors now and then with PPS LLR. There are some old WUs out there which collide with the new app.
____________
|
|
|
|
|
BOINC needs more space on your hard disc. You should check your settings and/or free up some space on your drive.
By the way: You might get some calculation errors now and then with PPS LLR. There are some old WUs out there which collide with the new app.
BOINC has 20GB to play with and is only using 500MB. Looks like there is a problem on SGS LLR older tasks too!
EDIT:seems to be about 6% slower (my bad).
____________
|
|
|
 Sysadm@Nbg Volunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 5 Feb 08
Posts: 1233
ID: 18646
Credit: 917,628,742
RAC: 381,950
                      
|
|
maybe the same issue as here at PPSllr
btw: I can not believe in an local issue because many workunits before and after finished successfully
____________
Sysadm@Nbg
my current lucky number: 113856050^65536 + 1
PSA-PRPNet-Stats-URL: http://u-g-f.de/PRPNet/
 |
|
|
samuel7Volunteer tester
Send message
Joined: 1 May 09
Posts: 89
ID: 39425
Credit: 257,425,010
RAC: 0
                
|
maybe the same issue as here at PPSllr
btw: I can not believe in an local issue because many workunits before and after finished successfully
It's not a client issue. The task-specific disk bound was not immediately adjusted server side to allow for the change in the Linux executable. You can follow my instructions in the linked thread to raise the bound. However, I'm not sure if SGS used to have the same bound of 10,000,000 bytes. You'd have to check client_state and adjust if needed.
____________
 |
|
|
VatoVolunteer tester
Send message
Joined: 2 Feb 08
Posts: 861
ID: 18447
Credit: 869,522,869
RAC: 1,175,087
                         
|
|
Yes, and the way to avoid this for future subprojects migrating to the new LLR is to first increase the diskspace allowed for all newly generated WUs, and later upgrade the app, perhaps with a script to fix all WUs currently in-flight in between those two stages, I don't know if the last bit is possible (though it'll probably be needed for long-running subprojects like SoB), or what the actual plan of action that will be used is.
____________
 |
|
|
|
|
Yes, and the way to avoid this for future subprojects migrating to the new LLR is to first increase the diskspace allowed for all newly generated WUs, and later upgrade the app, perhaps with a script to fix all WUs currently in-flight in between those two stages, I don't know if the last bit is possible (though it'll probably be needed for long-running subprojects like SoB), or what the actual plan of action that will be used is.
All LLR project was changed to 50MB.
Lennart
|
|
|
|
|
|
Yep, I got one too today on a 17-or-bust after days of computation (actually, 189 hours to be exact)! ;(
This is what I got:
Mon 20 Dec 2010 23:56:32 SAST PrimeGrid Aborting task llr_sob_47468853_9: exceeded disk limit: 10.14MB > 9.54MB
Can't they fix this? |
|
|
rroonnaallddVolunteer developer
Volunteer tester
Send message
Joined: 3 Jul 09
Posts: 1213
ID: 42893
Credit: 34,634,263
RAC: 0
              
|
Yep, I got one too today on a 17-or-bust after days of computation (actually, 189 hours to be exact)! ;(
This is what I got:
Mon 20 Dec 2010 23:56:32 SAST PrimeGrid Aborting task llr_sob_47468853_9: exceeded disk limit: 10.14MB > 9.54MB
Can't they fix this?
Is the unit already aborted or not?
If no, stop your boinc client immediately and edit the entry <max_nbytes> in client_state.xml to a bigger value in bytes. I would change this value from 10003415.04 (9.54MByte) to 90003415.04 (85.83MByte)...
____________
Best wishes. Knowledge is power. by jjwhalen
 |
|
|
VatoVolunteer tester
Send message
Joined: 2 Feb 08
Posts: 861
ID: 18447
Credit: 869,522,869
RAC: 1,175,087
|
|
I believe setting max_nbytes to 0.00000 will have the desired effect.
(If this is *not* true, please let me know ASAP!!!)
____________
|
|
|
