Anybody else having problems getting WUs?

[Gizmo]

I've been a day now without any work. My log indicates:

Originally Posted by fah

[20:44:18] + Attempting to get work packet
[20:44:18] - Will indicate memory of 1024 MB
[20:44:18] - Connecting to assignment server
[20:44:18] Connecting to http://assign.stanford.edu:8080/
[20:44:18] Posted data.
[20:44:18] Initial: 40AB; - Successful: assigned to (171.64.65.54).
[20:44:18] + News From Folding@Home: Welcome to Folding@Home
[20:44:18] Loaded queue successfully.
[20:44:18] Connecting to http://171.64.65.54:8080/
[20:44:19] Posted data.
[20:44:19] Initial: 0000; - Error: Bad packet type from server, expected work assignment
[20:44:19] - Attempt #1 to get work failed, and no other work to do.
Waiting before retry.

[gedon]

Hi Gizmo,

what client type/version is it?
My guess it's either an old client or server related issue. click

[Gizmo]

Hi Gedon,

I'm running the 6.29 Linux client. I'm inclined to suspect that it's a server issue, but I'm a little concerned because it happened at the same time that I upgraded from Fedora 12 to Fedora 13. Since I tend to not believe in coincidence, I just wanted to see if anyone else was having the same problem.

[dsio]

My fedora 13 laptop isn't folding, only the F12 desktop, so I can't really comment on the potential problem, but I'll pull down the client and give it a whirl just to see if it can pull a WU.

[ThunderRd]

64.65.54 isn't an SMP server [at least not at this time, it may have been in the past], it's a classic client server, so I never see it. Stanford may have a shortage of these WUs, but I don't see any other reports of it at the moment. It probably isn't significant knowing if someone else has the download problem unless it's from the same server.

That particular server is showing that it's fully operational at this time, and it has 388 WUs available. http://fah-web.stanford.edu/serverstat.html

Is your client updatesd with the drop in executable for 6.29? It's on the high performance downloads page. Is the client using the a3 core? Are you using the correct flags to receive SMP WUs? I can take a look at your command line if you post it, but I think that would be like trying to teach a fish how to swim

Offhand, of you are on the correct client version and core, I'd say that the installation of Fed is related to the problem.

[dsio]

Originally Posted by ThunderRd

... I can take a look at your command line if you post it, but I think that would be like trying to teach a fish how to swim ...

The more obvious the problem is, the more easily overlooked

[Gizmo]

sigh

Looks like the folding client is completely borked under Fedora 13 now.....if I don't apply the tear fix, I get the 'Could not CosmHTTPOpen' problem. If I use the tear fix from Fedora 12 with the Fedora 12 libraries, I get the problem I mentioned at the top of the thread, and if I use the tear fix with the Fedora 13 libraries, it just crashes.

[ThunderRd]

Originally Posted by Gizmo

sigh

Looks like the folding client is completely borked under Fedora 13 now.....if I don't apply the tear fix, I get the 'Could not CosmHTTPOpen' problem. If I use the tear fix from Fedora 12 with the Fedora 12 libraries, I get the problem I mentioned at the top of the thread, and if I use the tear fix with the Fedora 13 libraries, it just crashes.

Yeah, I reckoned it was something with F13 if your client was the right one. Are you talking about the fix you got from that guy at the folding forums some months back? There must be a way to adapt it for F13, no?

Back to the drawing board. I'll keep my ears open.

[Gizmo]

Ok, the guys in the folding forums got things sorted out. And it turns out with the new fix, you don't even need to patch the exe using the 'tear fix' that I had been using.

Basically the fix is:




enable nscd


That's it.

chkconfig --add nscd
chkconfig --level 35 nscd

And both F12 and F13 systems will be quite happy using the standard 6.29 client with no patches.

Apparently, the static linking of the 6.29 client breaks some things on systems using glibc 2.12 or newer when it comes to name resolution. However, the client is smart enough to query the name service caching daemon (nscd) before attempting to perform its own resolution. Since nscd is properly linked to the system binaries and all communications is via a socket, this neatly sidesteps the whole static linkage problem and makes things work just famously.

YAHOO!

[ThunderRd]

I don't know if this is related or not, but does anyone have any thoughts on this log from my sidux machine?

I have never had a hint of a problem on it, but today, after finishing a WU, it did this:

Writing final coordinates.
[20:31:38] Completed 500000 out of 500000 steps  (100%)

 Average load imbalance: 2.3 %
 Part of the total run time spent waiting due to load imbalance: 0.9 %


	Parallel run - timing based on wallclock.

               NODE (s)   Real (s)      (%)
       Time:  18397.176  18397.176    100.0
                       5h06:37
               (Mnbf/s)   (GFlops)   (ns/day)  (hour/ns)
Performance:     49.896      3.226      0.709     33.842

Thanx for Using GROMACS - Have a Nice Day

[20:31:38] DynamicWrapper: Finished Work Unit: sleep=10000
[20:31:48] 
[20:31:48] Finished Work Unit:
[20:31:48] - Reading up to 3699216 from "work/wudata_05.trr": Read 3699216
[20:31:48] trr file hash check passed.
[20:31:48] edr file hash check passed.
[20:31:48] logfile size: 66253
[20:31:48] Leaving Run
[20:31:51] - Writing 3800621 bytes of core data to disk...
[20:31:52]   ... Done.
[20:34:19] - Shutting down core
[20:34:19] 
[20:34:19] Folding@home Core Shutdown: FINISHED_UNIT
[20:34:41] CoreStatus = 64 (100)
[20:34:41] Unit 5 finished with 73 percent of time to deadline remaining.
[20:34:41] Updated performance fraction: 0.755146
[20:34:41] Sending work to server
[20:34:41] Project: 6051 (Run 0, Clone 60, Gen 29)


[20:34:41] + Attempting to send results [May 31 20:34:41 UTC]
[20:34:41] - Reading file work/wuresults_05.dat from core
[20:34:41]   (Read 3800621 bytes from disk)
[20:34:41] Connecting to http://171.64.65.54:8080/
[20:35:17] Posted data.
[20:35:18] Initial: 0000; - Uploaded at ~100 kB/s
[20:35:18] - Averaged speed for that direction ~86 kB/s
[20:35:18] + Results successfully sent
[20:35:18] Thank you for your contribution to Folding@Home.
[20:35:18] + Number of Units Completed: 1135

[20:36:05] Trying to send all finished work units
[20:36:05] + No unsent completed units remaining.
[20:36:05] - Preparing to get new work unit...
[20:36:05] Cleaning up work directory
[20:36:05] + Attempting to get work packet
[20:36:05] Passkey found
[20:36:05] - Will indicate memory of 2013 MB
[20:36:05] - Connecting to assignment server
[20:36:05] Connecting to http://assign.stanford.edu:8080/
fah6: relocation error: /lib/libnss_files.so.2: symbol __rawmemchr, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
thunderrd@OPTERON-185:~/FAH6$

Interestingly enough, I ran apt-get dist-upgrade just yesterday, and everything seemed to upgrade flawlessly. I'm wondering if this could be similar to the Fedora13 problem, maybe a version mismatch in glibc or something?

[Gizmo]

Try the 'tear fix' per these instructions: Folding Forum • View topic - Problem with Ubuntu 10.04

[Gizmo]

Another thought is to try enabling nscd (without the 'tear fix') on Sidux and see if that helps.

The 'tear fix' worked to fix Ubuntu 10.04 'Lucid Lynx'. However, since the problem with Ubuntu boiled down to a glibc issue, just as with Fedora, the work-around of using nscd might work as well.

[ThunderRd]

tear contacted me on the forum and indicated that nscd should work. It didn't, at least at first, but he was right. After installing it, hosts caching isn't enabled by default in Debian, and therefore sidux as well, so it needed a bit of editing in /etc/nscd.conf:

sudo apt-get install nscd
# open /etc/nscd.conf with your $EDITOR
# find following line:
#         enable-cache            hosts           no
# change "no" to "yes"
# save & exit the editor

Then restart nscd:

/etc/init.d/nscd restart

Running again as we speak. Thanks for the look, Chris.

[Gizmo]

You've helped me often enough. Least I could do was return the favor.