Author
|
Message
|
|
What up w/ these? I've lost 10 hours of crunch time on these last two WU:
4/1/2012 10:57:35 PM | Docking | Finished upload of 1ebw1d4h_mod0014crossdockinghiv1_24471_43159_0_2
4/1/2012 10:57:35 PM | Docking |
[error] Error reported by file upload server:
nbytes missing or negative
4/1/2012 10:57:35 PM | Docking | Giving up on upload of 1ebw1d4h_mod0014crossdockinghiv1_24471_43159_0_3:
permanent upload error
4/2/2012 7:12:09 AM | Docking | Finished upload of 1ebz1d4h_mod0014crossdockinghiv1_28403_466959_0_1
4/2/2012 7:12:09 AM | Docking | Finished upload of 1ebz1d4h_mod0014crossdockinghiv1_28403_466959_0_2
4/2/2012 7:12:09 AM | Docking | Started upload of 1ebz1d4h_mod0014crossdockinghiv1_28403_466959_0_3
4/2/2012 7:12:11 AM | Docking |
[error] Error reported by file upload server:
nbytes missing or negative
4/2/2012 7:12:11 AM | Docking | Giving up on upload of 1ebz1d4h_mod0014crossdockinghiv1_28403_466959_0_3:
permanent upload error
|
|
|
I'm going to stop crunching.
I desire a response.
I will NOT crunch any more Docking WU's...
|
|
|
I aborted all existing WU's.
|
|
|
No further WU' will be processed w/out a response.
|
|
|
I just started on this project.
Noticed a few problems earlier this morning but systems seem to be running fine now :)
Try crunchin 1 wu and have it uploaded again, hopefully it works again.
|
|
|
Tried 'nother WU (and lost some 6+ HOURS of crunch time).
This project is now on DOUBLE
Secret
ULTRA
Probation
and is suspended from processing / communication until its learned how to fly right.
|
|
|
Tried 'nother WU ...
As your Tualatin box has similar trouble on SETI but does run on SIMAP without trouble, it might be an optimizer issue, some SSE command that The King doesn't support yet. Otoh. 0xc0000005 isn't a typical error for a command set problem.
RAM problems (SD-RAM ages too), overclocking issues (all single PIIIs/1400 run on liquid nitrogen, right?) - as soon as it's more than one project causing problems you should do some checks on your box or at least try to reset the FSB from 140+ to 133MHz for the next attempt.
p.s.: I'm aware that those CPUs can handle higher FSBs but often RAM is the limiting factor.
|
|
|
Except for one thing: Prime95, Memtest86 & HDAT2 pass w/out issue.
|
|
|
So the upload error by the BOINC server is a misdirect?
So Docking will complete processing - apparently successfully - and then notify the user that computation was unsuccessful - maybe after the first second r two - through notification by the upload server.
That is
so
bass ackwards
on so many different levels I don't even know where to begin refuting that sort of logic.
You mean to tell me that I can crunch 1.5 million sec of Lattice and have some piddlpe-squeak project tell me there's a prollem?
|
|
|
So the upload error by the BOINC server is a misdirect?
So Docking will complete processing - apparently successfully - and then notify the user that computation was unsuccessful - maybe after the first second r two - through notification by the upload server.
That is
so
bass ackwards
on so many different levels I don't even know where to begin refuting that sort of logic.
You mean to tell me that I can crunch 1.5 million sec of Lattice and have some piddlpe-squeak project tell me there's a prollem?
Nobody else has reported suffering this problem so it points towards your system/s having a problem with this project.
|
|
|
I've detached from this project.
|
|
|
Not so fast!
I believe I've ascertained the root of my prollems - chagrinned while scuffin' the dirt - and I've re-'ttached.
It would appear that my TUV4X mobo is particular WHICH particular SDRAM stick is in slot 1.
Despite ALL three 512MB PC-133 SDRAM sticks mfg'd by Crucial, the two 2008 mfg'd sticks caused "issues" if they were on the mobo in either slot 1 or 2 along with the 2004 SDRAM (in either slot 2 or three).
When I put the 2004 mfg'd 512MB PC-133 SDRAM into slot 1 (and the 2008 mfg'd SDRAM sticks into slot 2 & 3), the BIOS reported mem-timing (2-2-2-5) remain constant. I could never finger out why the BIOS reported RAM timings varied between 2-2-2-5 & 2-2-2-6. Not such a big deal in that the system ran 99% of the time. I always attributed this to "latency" on the SDRAM circuit.
One thing I ascertained with MemTest86 - after running test #8 for 2.5 hrs each test - was that if either of the 2008 mfg'd 512 2-2-2-5 sticks where in slot 1, the 2004 mfg 2-2-2-5 PC-133 512MB SDRAM in slot 2 would cause HDAT2 R-W-R-C to FAIL r-w-r-COMPARE - at random cluster/block/sectors.
When each stick individually was tested with HDAT2 R-W-R-C ALWAYS passed with the flying colors. Incidently, I'd already ran Prime95 for 2.5 hrs, and ran MemTest86 - test 1 thru 5 - for as many.
It wasn't until I ran MemTest86 test #8 specifically - taking 2.5hr to complete 1 pass of THAT test - that I discerned that a problem existed.
When I put the 2004 mfg'd Crucial 2-2-2-5 PC-133 SDRAM into slot one that my prllem's were solved.
One qualifier: the 2004 mfg'd SDRAM was purchaseded from Crucial directly. The 2008 Crucial SDRAM was "retail" packaged SDRAM marketed as 2-2-2-5 that I bought "new" - unopened package - from eBay.
|
|
|
Well done for sticking with it.
I recently did a BIOS update on an Asus motherboard which unfortunately resulted in some stability issues - I got quite a few "Compute errors" and despite efforts at tweaking voltages I reverted back to the earlier BIOS and stability returned.
Have also found that running other project WU's at the same time as Docking can result in errors.
My main rig runs Docking + GPUGRID 100% of the time and now have my other rigs runs projects in batches.
|
|
|
We are DONE with this crap.
4/21/2012 6:19:01 AM | Docking | Computation for task 1hbv1d4i_mod0014crossdockinghiv1_20231_16973_0 finished
4/21/2012 6:19:01 AM | Docking | Starting task 1hih1d4i_mod0014crossdockinghiv1_28530_473453_0 using charmm34 version 623
4/21/2012 6:19:03 AM | Docking | Started upload of 1hbv1d4i_mod0014crossdockinghiv1_20231_16973_0_0
4/21/2012 6:19:03 AM | Docking | Started upload of 1hbv1d4i_mod0014crossdockinghiv1_20231_16973_0_1
4/21/2012 6:19:11 AM | Docking | Finished upload of 1hbv1d4i_mod0014crossdockinghiv1_20231_16973_0_0
4/21/2012 6:19:11 AM | Docking | Finished upload of 1hbv1d4i_mod0014crossdockinghiv1_20231_16973_0_1
4/21/2012 6:19:11 AM | Docking | Started upload of 1hbv1d4i_mod0014crossdockinghiv1_20231_16973_0_2
4/21/2012 6:19:11 AM | Docking | Started upload of 1hbv1d4i_mod0014crossdockinghiv1_20231_16973_0_3
4/21/2012 6:19:14 AM | Docking | [error]
Error reported by file upload server: nbytes missing or negative
4/21/2012 6:19:14 AM | Docking | Giving up on upload of 1hbv1d4i_mod0014crossdockinghiv1_20231_16973_0_3: permanent upload error
4/21/2012 6:19:15 AM | Docking | Finished upload of 1hbv1d4i_mod0014crossdockinghiv1_20231_16973_0_2
After 20 hrs of crunching.
I'm permanently detached.
|
|
|
It looks like your problem is down to mismatched memory.
Docking units only require a small amount of memory, and with your problem system only having 1 CPU 512MB would be more than enough for it to run docking. Try running it with just 1 stick, perhaps the 2004 one and see what happens.
|
|
: The MySQL server is running with the --read-only option so it cannot execute this statement