• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Boinc help

rise

rise

Diamond Member
i got a low disc warning from windows this morning so i checked to see wth could be taking up so much space. it appears i have almost 6 gigs in my boinc slots 😕

trying to send in results via "update" i get these messages.

3/8/2006 11:16:18 AM|rosetta@home|Sending scheduler request to http://boinc.bakerlab.org/rosetta_cgi/cgi
3/8/2006 11:16:18 AM|rosetta@home|Reason: Requested by user
3/8/2006 11:16:18 AM|rosetta@home|Reporting 9 results
3/8/2006 11:16:23 AM|rosetta@home|Scheduler request to http://boinc.bakerlab.org/rosetta_cgi/cgi succeeded
3/8/2006 11:16:23 AM|rosetta@home|No start tag in scheduler reply
3/8/2006 11:16:23 AM|rosetta@home|Can't parse scheduler reply
3/8/2006 11:16:58 AM|BBC Climate Change Experiment|Sending scheduler request to http://bbc.cpdn.org/bbc_cgi/cgi
3/8/2006 11:16:58 AM|BBC Climate Change Experiment|Reason: Requested by user
3/8/2006 11:16:58 AM|BBC Climate Change Experiment|Note: not requesting new work or reporting results
3/8/2006 11:17:03 AM|BBC Climate Change Experiment|Scheduler request to http://bbc.cpdn.org/bbc_cgi/cgi succeeded
3/8/2006 11:17:03 AM|BBC Climate Change Experiment|No start tag in scheduler reply
3/8/2006 11:17:03 AM|BBC Climate Change Experiment|Can't parse scheduler reply
3/8/2006 11:18:58 AM|boincsimap|Sending scheduler request to http://boinc.bio.wzw.tum.de/boincsimap_cgi/cgi
3/8/2006 11:18:58 AM|boincsimap|Reason: Requested by user
3/8/2006 11:18:58 AM|boincsimap|Reporting 2 results
3/8/2006 11:19:03 AM|boincsimap|Scheduler request to http://boinc.bio.wzw.tum.de/boincsimap_cgi/cgi succeeded
3/8/2006 11:19:03 AM|boincsimap|No start tag in scheduler reply
3/8/2006 11:19:03 AM|boincsimap|Can't parse scheduler reply
3/8/2006 11:19:24 AM|rosetta@home|Sending scheduler request to http://boinc.bakerlab.org/rosetta_cgi/cgi
3/8/2006 11:19:24 AM|rosetta@home|Reason: Requested by user
3/8/2006 11:19:24 AM|rosetta@home|Reporting 9 results
3/8/2006 11:19:29 AM|rosetta@home|Scheduler request to http://boinc.bakerlab.org/rosetta_cgi/cgi succeeded
3/8/2006 11:19:29 AM|rosetta@home|No start tag in scheduler reply
3/8/2006 11:19:29 AM|rosetta@home|Can't parse scheduler reply

whats all this mean? in particular the bolded.
 
i dunno, i guess i gotta move some stuff around. figured i'd restart but got this that i'm posting only so i don't lose the messages when i shut down again.

restarted client-
3/8/2006 11:25:10 AM||Starting BOINC client version 5.3.1 for windows_intelx86
3/8/2006 11:25:10 AM||libcurl/7.14.0 OpenSSL/0.9.8 zlib/1.2.3
3/8/2006 11:25:10 AM||Data directory: C:\BoincOriginal\BOINC
3/8/2006 11:25:10 AM||Missing open tag in state file.
3/8/2006 11:25:10 AM||Processor: 2 AuthenticAMD AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
3/8/2006 11:25:10 AM||Memory: 2.00 GB physical, 4.00 GB virtual
3/8/2006 11:25:10 AM||Disk: 14.89 GB total, 0 bytes free
3/8/2006 11:25:10 AM||Version change detected (0.0.0 -> 5.3.1); running CPU benchmarks
3/8/2006 11:25:10 AM|BBC Climate Change Experiment|Computer ID: not assigned yet; location: ; project prefs: default
3/8/2006 11:25:10 AM|rosetta@home|Computer ID: not assigned yet; location: home; project prefs: home
3/8/2006 11:25:10 AM|boincsimap|Computer ID: not assigned yet; location: home; project prefs: home
3/8/2006 11:25:10 AM|climateprediction.net|Computer ID: not assigned yet; location: home; project prefs: default
3/8/2006 11:25:10 AM||General prefs: from boincsimap (last modified 2006-02-16 10:44:20)
3/8/2006 11:25:10 AM||General prefs: using separate prefs for home
3/8/2006 11:25:10 AM||Remote control not allowed; using loopback address
3/8/2006 11:25:10 AM|BBC Climate Change Experiment|Fetching master file
3/8/2006 11:25:11 AM||Attempting to write to a file failed [failed writing received data to disk/application]
3/8/2006 11:25:12 AM||Running CPU benchmarks
3/8/2006 11:25:15 AM|BBC Climate Change Experiment|Master file fetch failed
3/8/2006 11:25:20 AM|rosetta@home|Fetching master file
3/8/2006 11:25:23 AM||Attempting to write to a file failed [failed writing received data to disk/application]
3/8/2006 11:25:25 AM|rosetta@home|Master file fetch failed
3/8/2006 11:25:31 AM|boincsimap|Fetching master file
3/8/2006 11:25:36 AM|boincsimap|Master file download succeeded
3/8/2006 11:25:41 AM|climateprediction.net|Fetching master file
3/8/2006 11:25:46 AM|climateprediction.net|Master file download succeeded
3/8/2006 11:25:51 AM|boincsimap|Sending scheduler request to http://boinc.bio.wzw.tum.de/boincsimap_cgi/cgi
3/8/2006 11:25:51 AM|boincsimap|Reason: Requested by user
3/8/2006 11:25:51 AM|boincsimap|Requesting 345600 seconds of new work
3/8/2006 11:25:56 AM|boincsimap|Scheduler request to http://boinc.bio.wzw.tum.de/boincsimap_cgi/cgi succeeded
3/8/2006 11:25:56 AM|boincsimap|No start tag in scheduler reply
3/8/2006 11:25:56 AM|boincsimap|Can't parse scheduler reply
3/8/2006 11:26:01 AM|climateprediction.net|Sending scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi
3/8/2006 11:26:01 AM|climateprediction.net|Reason: Requested by user
3/8/2006 11:26:01 AM|climateprediction.net|Requesting 345600 seconds of new work
3/8/2006 11:26:06 AM||request_reschedule_cpus: project op
3/8/2006 11:26:06 AM|climateprediction.net|Scheduler request to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi succeeded
3/8/2006 11:26:06 AM|climateprediction.net|Message from server: No work sent
3/8/2006 11:26:06 AM|climateprediction.net|Message from server: (there was work but you don't have enough disk space allocated)
3/8/2006 11:26:06 AM|climateprediction.net|Message from server: No disk space (YOU must free 100.0 MB before BOINC gets space). Review preferences for minimum disk free space allowed.
3/8/2006 11:26:11 AM||request_reschedule_cpus: project op
3/8/2006 11:26:12 AM||Benchmark results:
3/8/2006 11:26:12 AM|| Number of CPUs: 2
3/8/2006 11:26:12 AM|| 2571 double precision MIPS (Whetstone) per CPU
3/8/2006 11:26:12 AM|| 5305 integer MIPS (Dhrystone) per CPU
3/8/2006 11:26:12 AM||Finished CPU benchmarks
3/8/2006 11:26:13 AM||Resuming computation and network activity
3/8/2006 11:26:13 AM||request_reschedule_cpus: Resuming activities
3/8/2006 11:26:22 AM|BBC Climate Change Experiment|Master file download succeeded
3/8/2006 11:26:27 AM|BBC Climate Change Experiment|Sending scheduler request to http://bbc.cpdn.org/bbc_cgi/cgi
3/8/2006 11:26:27 AM|BBC Climate Change Experiment|Reason: Requested by user
3/8/2006 11:26:27 AM|BBC Climate Change Experiment|Requesting 345600 seconds of new work
3/8/2006 11:26:32 AM|BBC Climate Change Experiment|Scheduler request to http://bbc.cpdn.org/bbc_cgi/cgi succeeded
3/8/2006 11:26:32 AM|BBC Climate Change Experiment|Message from server: No work sent
3/8/2006 11:26:32 AM|BBC Climate Change Experiment|Message from server: (there was work but you don't have enough disk space allocated)
3/8/2006 11:26:32 AM|BBC Climate Change Experiment|Message from server: No disk space (YOU must free 100.0 MB before BOINC gets space). Review preferences for minimum disk free space allowed.
3/8/2006 11:26:42 AM|rosetta@home|Master file download succeeded
3/8/2006 11:26:47 AM|rosetta@home|Sending scheduler request to http://boinc.bakerlab.org/rosetta_cgi/cgi
3/8/2006 11:26:47 AM|rosetta@home|Reason: Requested by user
3/8/2006 11:26:47 AM|rosetta@home|Note: not requesting new work or reporting results
3/8/2006 11:26:57 AM|rosetta@home|Scheduler request to http://boinc.bakerlab.org/rosetta_cgi/cgi succeeded
3/8/2006 11:26:57 AM|rosetta@home|No start tag in scheduler reply
3/8/2006 11:26:57 AM|rosetta@home|Can't parse scheduler reply
3/8/2006 11:27:02 AM|boincsimap|Sending scheduler request to http://boinc.bio.wzw.tum.de/boincsimap_cgi/cgi
3/8/2006 11:27:02 AM|boincsimap|Reason: Requested by user
3/8/2006 11:27:02 AM|boincsimap|Note: not requesting new work or reporting results
3/8/2006 11:27:07 AM|boincsimap|Scheduler request to http://boinc.bio.wzw.tum.de/boincsimap_cgi/cgi succeeded
3/8/2006 11:27:07 AM|boincsimap|No start tag in scheduler reply
3/8/2006 11:27:07 AM|boincsimap|Can't parse scheduler reply
 
great, its a single file STDERR. howe the hell do i get 5.53gb of errors in a text file? is it safe to just delete the thing as i can't seem to open it?
 
I'd say CPDN/BBC are the culprits, at least for the disk space. Check the projects folder for remnants of CPDN. When my last model crashed after 200 hours, it left about 1.5 GB of data in its folder.

If have no idea abou the "start tag" thing, though 🙁 .
 
Where is the stderr loacted at? I remember somebody - was it Smoke? - having had the same problem with Rosetta once. It should be save to delete it but I'd defintely reset Rosey afterwards.
 
well, i have like 0 space on c right now so nothing wants to start 😛

i think i'll just delete the thing and then watch if it comes back. maybe i'll be able to read it then 🙁
 
Originally posted by: BlackMountainCow
Where is the stderr loacted at? I remember somebody - was it Smoke? - having had the same problem with Rosetta once. It should be save to delete it but I'd defintely reset Rosey afterwards.
Click to expand...

its in the boinc slot 1, along with a bunch of .rar results. when i was looking to move stuff i noticed nothing that large. then noticed a damn text file at 5 gig, lol.

thanks BMC
 
Well, for a starting-point, BOINC v5.3.1 was never released at all, it's only available if you compiled yourself, or if downloaded from someone else that has compiled it.

v5.3.1 is actually older than v5.2.6, so my recommendation is to upgrade to latest "stable" build, v5.2.13.

As for disk-usage, CPDN doesn't clean-out after you've finished or aborted a model, so can be your problem. Also, atleast the Sulphur-cycle model is using serveral GB during it's progress...
BBC/CPDN should clean-out disk-usage...


... but, is it one of the Slots-directories that is using so much? Not sure if it's Rosetta or someone else I've seen this problem reported for... If so, try nuking this result...


Hang on... "0 bytes free"...

If you don't have any free disk-space, this means there isn't any available space for BOINC to write scheduler-reply to, and this is the reason for "Can't parse scheduler reply"...



edit - Is apparently a slow typer... :beer:
 
thanks RD. i think it was rosey actually. i had just restarted it last nite and it was only in the slot one directory.

i knew you'd say:
Well, for a starting-point, BOINC v5.3.1 was never released at all, it's only available if you compiled yourself, or if downloaded from someone else that has compiled it.
Click to expand...
😛 but i see your point. 5.31 has been running well for me but who knows, its not actually official.

i moved the stderr file to another drive before i delete it all together and reset all my projects. so far so good with one problem.

i had also moved a few .rar'd files before i realized which file was killing me. i moved them back but cpdn and bbc cpdn can't seem to find the wu's they were working on before the problem.

either i screwwed up the location or are those units borked?
 
If you reset a project, you'll delete it's files from disk, delete any of it's running results from slots-directory, and also remove all info of any downloaded but not yet reported results from client_state.xml.

So, if you don't have a backup-copy of client_state.xml from before you reset a project, you're screwed.
 
yeah, i tried not resetting them but when they wouldn't start back up i reset it. i suppose i should have tried moving the files again first 🙁

edit , well the files are all still there and i have a "client state" and a "client state previous" xmls but i don't know if that will help.

edit edit- after reinstalling boinc, i think it was rosetta that borked me. i went back to the original, official client and it immediately tried running a couple rosetta units that were sending the error message "units may be bad, you may want to abort" or some such thing. i've seen it before.

anyway, its all over. i'm on an official client. for now 😛
 
Sorry to read about you CPDN loss Paul, that really sux, especially 'cause it wasn't CPDN itself but Rosey that killed your model. :evil:🙁
 
yeah, LMOA, one of us has to finish one of these damn units 😛

anyway, i started a new bbc wu. i can't not try again 😛 as p!ssed off as i am. i had almost 400 hours into the damn thing.
 
I just found this thread Rise

Is there something us Rosey participants should check in our files to avoid the issue you had?

I am glad you got stuff running now, but it sucks that you lost that big chunk 🙁

-Sid

PS: /me eyes Rosey and BBC-CCE...... "Don't EVEN think about it..." :disgust:

I just looked at my disk usage and BBC-CCE is the only one using a lot of spave (1.6GB).

I did have 3 crashes of BBC.... is there some stuff I can clear out manually? How can I tell what is OK to remove? Or should I just leave 'good enough' alone?
 
i dunno man. i just decided to start rosetta up yesterday after about a month layoff. the projet had been cleared out with the "no new work" so there were no wu's just hanging about. everything seemed fine through the first 20 odd wu's then i awoke to this.

and once Christian and RD mentioned it, i do remember someone else having this issue or something similar with rosetta.

Peter says that stderr whould write like 4 lines each wu for the project to see how it crunched. i had over 5 gigs :Q i can't imagine what 5 gigs of text looks like 😛

 
Originally posted by: Insidious
I just looked at my disk usage and BBC-CCE is the only one using a lot of spave (1.6GB).

I did have 3 crashes of BBC.... is there some stuff I can clear out manually? How can I tell what is OK to remove? Or should I just leave 'good enough' alone?
Click to expand...

The coupled model should normally clean-up after itself, but it's not always doing it...

... Hmm, there was a change added just in time for the customized BBC/BOINC-client, so also when users aborted results it should clean-up... so would guess it's the 3 results you've aborted that still fills-up the disk. 😉


If you looks under projects\bbc.cpdn.org you'll see all Tasks you've started shows-up with it's own sub-directory, example hadcm3l_3zi9_00186439
So, it's just to look on Tasks-tab and see if you've got this listed, remember that here it will also show-up with _0 or _1 or something at the end.

If you've got more sub-directories listed than you've currently got work for, just delete the sub-directories starting with hadcm3l_* you don't find any corresponding under Tasks-tab.

There is one small sub-directory named txf, this should not be deleted.



 
Thanks RD and Rise! :beer:

It looks like I'm OK here. (several extra 'slot' directories, but they're empty)

-Sid
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top