• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Project 6318 upload problems

A

APOLLO

[H]ard|DCer of the Month - March 2009
Joined
Sep 17, 2000
Messages
9,089
The P6318 WUs recently completed are not uploading and I get the following lines of error. Does anyone know what this could be?

[08:38:19] Loaded queue successfully.
[08:38:19] + Benchmarking ...
[08:38:22]
[08:38:22] - Error: Length of work/wuresults_01.dat (6948912) exceeds packet limit set (5241856)
[08:38:22] + Processing work unit
[08:38:22] - Error: Could not transmit unit 01 (completed January 20) to work server.
[08:38:22] Core required: FahCore_78.exe
[08:38:22] - Error: Length of work/wuresults_01.dat (6948912) exceeds packet limit set (5241856)
[08:38:22] Core found.
[08:38:22] Could not transmit unit 01 to Collection server; keeping in queue.
[08:38:22] Working on Unit 02 [January 22 08:38:22]
[08:38:22] + Working ...
 
For some reason, this WU generated results that exceeded the 5MB limit for the return packet size. You can try running qfix on this, it has corrected issues like this before.

Unfortunately, I can't get the download link for qfix to work at the moment. Which platform is this on?
 
is this the gpu or SMP client? if its the GPU you can try checking the allow receipt of work assignments and return of results greater then 10mb.. see if that helps..
 
sirmonkey1985 said:
is this the gpu or SMP client? if its the GPU you can try checking the allow receipt of work assignments and return of results greater then 10mb.. see if that helps..
Click to expand...
6318 is a uniprocessor GROMACS project.
 
Tobit said:
Apollo, the website for the qd-tools is working once again:

http://linuxminded.xs4all.nl/?target=software-qd-tools.plc

Scroll down to the "Binaries of qfix" section, choose your platform, and give it a try. qfix has definitely solved this problem in the past and worthy of trying it.
Click to expand...
OK thanks, Tobit. I'll give it shot and report later. I hope it works because I have several more of these coming up.
 
6318 shouldn't really be causing problems. It may have just been a fluke. We never experienced any issue like this while it was in beta testing.
 
Apollo, one other thing to check. Do you have small or normal work sizes set in the config on this client? You may need to reconfigure for "big". I've had a couple 6318's exceed the 5MB limit but I have "big" set on all my clients and they uploaded fine as a result. qfix can fix the current queue but to avoid the problem in the future, "big" will likely need to be set in the config.

Stop the client, run -configonly to set big work, run qfix, restart the client
 
Apollo, one more, one more, thing. ;) Which version of the client software are you running? Please tell me it isn't a 5.x client. There are some recent reports the same as yours with this project and the consistency with everyone thus far is they are running on a 5.x version of the classic client.
 
Tobit said:
Apollo, one more, one more, thing. ;) Which version of the client software are you running? Please tell me it isn't a 5.x client. There are some recent reports the same as yours with this project and the consistency with everyone thus far is they are running on a 5.x version of the classic client.
Click to expand...
Yes I am!! :eek: :(
 
There ya go, you should really be using the v2.63 classic client. 5.0x is no longer supported by Stanford and, although many projects may still run on 5.0x, one is really tempting fate especially when new uniprocessor projects come out such as 6318.
 
Tobit said:
There ya go, you should really be using the v2.63 classic client. 5.0x is no longer supported by Stanford and, although many projects may still run on 5.0x, one is really tempting fate especially when new uniprocessor projects come out such as 6318.
Click to expand...
I have only a few standard clients left running and just didn't get around to updating them. They have never given me issues and because of the lack of problems, it just didn't draw my attention until now. What do I need to do? Is it a drop in executable replacement?
 
APOLLO said:
I have only a few standard clients left running and just didn't get around to updating them. They have never given me issues and because of the lack of problems, it just didn't draw my attention until now. What do I need to do? Is it a drop in executable replacement?
Click to expand...
Finish your current project with a -oneunit flag. Run qfix to see if it can fix that one packet. After qfix, run the client with '-send all' to see if it can send that broken unit. 6.23 for Windows is available on the main download page as a .zip file so you should be able to dropin the replacement but you will want to do a -configonly to generate a new config file as I believe there are some differences between the two versions. Make sure the file name and so forth is still the same if you are running it as a service. You can set it up a new service from the respective prompt, if needed, when you run -configonly. Make sure you disable the old service if you are running as a service and you choose to install a new service. Normal disclaimers apply with all of this. :D You should be ok though. :cool:
 
Tobit said:
Apollo, one more, one more, thing. ;) Which version of the client software are you running? Please tell me it isn't a 5.x client. There are some recent reports the same as yours with this project and the consistency with everyone thus far is they are running on a 5.x version of the classic client.
Click to expand...

I had this problem running the v5 client also. Setting the 'big' units switch and running 'qfix' didn't work for me. I dumped the 6318 unit (sorry EA, no choice here) and upgraded to the v6 client. It's possible v5 clients pulled 6318 units incorrectly during the server outage. I was running 1 v5 client and 5 v6 clients when the server outage occurred. The v6 clients always pulled 63xx units and the v5 clients always pulled 44xx/46xx units. It seemed strange at the time to get a 6318 unit with the v5 client. This is the first time I've been burned running older client versions.
 
Last edited:
Thanks for the input AgrFan. Interestingly enough, Vijay took notice of this issue and is looking into server side stuff. If Vijay takes notice like this, you know something goofed somewhere. :rolleyes: Still Apollo, please upgrade to v6 if you can. There really is little reason to keep hanger-on-er-ing to v5 unless one has a system that is simply incapable of running v6 and if you do.. well.. you know. ;)
 
Tobit said:
There really is little reason to keep hanger-on-er-ing to v5 unless one has a system that is simply incapable of running v6 and if you do.. well.. you know. ;)
Click to expand...

I have a Sempron 2500+ (skt-A) system still in service. I was running the v5 client to get Amber units (46xx) since they don't take much time and use limited resources.

I've been looking to retire it for some time. It's the wife/family computer. I was going to give her the system in my sig and either build a quad-core or install a GPU in my Dell Dimension E521 to run the GPU client. I really need to reduce the number of machines I'm maintaining. Unfortunately, I don't have the time right now to switch stuff around.
 
Last edited:
Just to update everyone, all this required was an exe replacement and the results uploaded fine. Thought I post this to confirm it for anyone else experiencing the same problem. :)
 
You must log in or register to reply here.
Back
Top