SMP WU problems

[APOLLO]

Several of my Linux VMs are experiencing an odd problem of not being able to upload completed WUs. The client makes an attempt to upload results but just freezes at the point after the last frame but before the upload begins. I tried restarting the client, restarting the VM and using flags like -send all, to no avail. The work folder has a 'wuresults.dat' file in there. When I restart the client I get: Error: Could not write local file. Exiting - Shutting down core.

This problem only goes away if I delete the work folder and any associated files to pick up a new WU. Otherwise, the client won't function. Of course, by doing this I lose the completed WU. I have seen this happen on two separate machines so far. Anyone have a clue what might be causing this?

 

[Kendrak]

Do you have enough memory allocated inside the VM?

 

[APOLLO]

Do you have enough memory allocated inside the VM?

Do you think memory amounts could be causing this issue? I have close to 1 GB. These are regular SMP clients.

 

[Kendrak]

Do you think memory amounts could be causing this issue? I have close to 1 GB. These are regular SMP clients.

This is the part that makes me think it: Error: Could not write local file

Dunno, might be worth a try, and a easy fix to boot if it is the problem.

 

[APOLLO]

This is the part that makes me think it: Error: Could not write local file

Dunno, might be worth a try, and a easy fix to boot.

I recently increased the memory size when I moved away from multiple VMs to single VM on my SMP boxes. I don't know how much more I can increase the amount of memory allocated to VMs on these systems since they typically have 2-2.5GB total RAM installed, and I'm running Win XP as a host. I guess I could increase it another couple hundred MB, but in all honesty, when I was running multiple VMs they typically had only ~512MB or even less each, and I never ran into this problem before.

 

[Kendrak]

I recently increased the memory size when I moved away from multiple VMs to single VM on my SMP boxes. I don't know how much more I can increase the amount of memory allocated to VMs on these systems since they typically have 2-2.5GB total RAM and I'm running Win XP as a host. I guess I could increase it another couple hundred MB, but in all honesty, when I was running multiple VMs they typically had only 512MB each, and I never ran into this problem before.

I've got mine set to 1024mb.

Unless you running a bunch of other stuff on them XP should be plenty happy on 1gb of memory. Heck I run Win 7 systems on 1 gig just fine.

 

[APOLLO]

I've got mine set to 1024mb.

Unless you running a bunch of other stuff on them XP should be plenty happy on 1gb of memory. Heck I run Win 7 systems on 1 gig just fine.

Yeah, that's what I figured, so I'll leave it at 1GB then. It must be something else that's causing it.

 

[APOLLO]

OK, this problem occurred on a third system. The only thing I can pin down as a cause is my switching from multiple VMs to a single VM per this thread. There was no problem when I had my VMs configured for two cores each, now I'm getting stalls uploading results and restarts do not help. I'm forced to delete completed data just to DL another WU but it's pointless.

 

[APOLLO]

Anyone know if there's another method to upload a completed Linux SMP WU that a client doesn't seem to detect??

 

[APOLLO]

OK, I seem to have narrowed down the culprits and it appears VM Player 3 is not working well with my Linux installations. Sometimes my Linux distro stalls during start up and believe this issue is likely related to my upload stalls. I have NEVER experienced these kinds of stalls or issues with VMware Server I was using before. So, if anyone else has experienced stalls with VMP 3 and their Linux installs, please post and let me know what you did about it. TIA.

 

[Tigerbiten]

Is this a notfred VM or your own build ??

You could try This
I dont know if qfix will help to upload the work-unit but its work a go if there is a result file in the work folder.

Luck ...............

 

[APOLLO]

Is this a notfred VM or your own build ??

You could try This
I dont know if qfix will help to upload the work-unit but its work a go if there is a result file in the work folder.

Thanks for the heads up. I checked the link and it appears to be exactly what is afflicting my clients. I remember stumbling on this thread a couple of months ago looking for other information but didn't associate it with my problem. It's too late to save my WUs since I restarted the client several times, and I can't fix the problem now. So far I have lost 3-4 WUs in the past day alone.

Will this fix stop the problem from occurring again and why am I receiving a series of this kind of error and never did before??

 

[Tigerbiten]

My normal fix for any folding glitch like this is to delete and then re-download both the latest client and the newest core.
It may not fix the glitch but its worth a try.

Ps.....
How long are you leaving the VM's when they stalled ??
And did you check in Windoze if there's any network traffic ??
If there is network traffic and the last line of the log file is "connecting to http......" then you are just uploading work, just very slowly.
My last standard work-unit took almost 30 mins to upload.
And my first bigadv work-unit has just taken 54 mins to upload .....
I'm uploading at only ~26 kB/sec and it does look like things are hanging.
So the servers at Stanfords end may just be running very slow.

Luck ........

 

[APOLLO]

Ps.....
How long are you leaving the VM's when they stalled ??

The last time this happened, I must have left it alone for close to an hour. I went away to do some chores and when I came back the client was in the same state - nothing changed.

And did you check in Windoze if there's any network traffic ??

When I spotted the problem and I was attempting to try various things to fix it, at that event there was little to no network traffic. I wasn't DL or UL anything during those particular times.

If there is network traffic and the last line of the log file is "connecting to http......" then you are just uploading work, just very slowly.

I figured something like that could be the problem but my switch was not displaying any activity and this is occurring a lot now across several systems. It's definitely the problem in the link you posted because after restarting the client I receive the following line "Project: 0 (Run 0, Clone 0, Gen 0)" and then the client aborts.

My last standard work-unit took almost 30 mins to upload.
And my first bigadv work-unit has just taken 54 mins to upload .....

Those are crazy upload times. I used to get horrendous times as well when I was using DSL over a year ago. I since switched to cable and although it's not that much better it cut the upload times about 20-30% which is better than nothing I suppose. Still, regular SMP WUs take more than 10 minutes, which is too long if you ask me. Honestly, I think it's time to upgrade your ISP. I don't know what your choices are in the UK, but here we have monopolies and it's very bad cost/performance-wise.

I'm uploading at only ~26 kB/sec and it does look like things are hanging.
So the servers at Stanfords end may just be running very slow.

Yep, you need to upgrade. In my case it's confirmed the error I have is the one mentioned in the Folding Forum link. Stanford should just freaking release a new client already (this shouldn't be happening)...!!!