Smp

[ccperf721p]

Time is not my friend lately either so I understand.

[dabaerman]

I did manage to find my biggest problem with the 5.92 beta. it was the 5.91 beta. after READING (new concept for me)
the directions, I realized that I hadn't installed the 5.91 SMP client. so I go back to the drawing board tonight and give it a go.


Ron

[ThunderRd]

Yeah, it's actually an upgrade, you have to have the old one there first.

[dabaerman]

they did mention that afresh install version would be out soon. I may cool my jets
and wait for it. it could be easier.

Ron

[dsio]

Anyone tried the SMP client on machines with more than 4 cores?

[ThunderRd]

If you're lucky enough to have a dual cpu board just run two clients. It should work fine. Lots of help on the community forums if you look for it.

[dsio]

Just curious as to whether or not the SMP client scales to more cores with a single instance.

[ThunderRd]

Every.thing I have read indicates using a second client; but since the SMP client works on dual-cores...mebbe.

[ThunderRd]

I've been having massive problems uploading yesterday and today, and it looks like others are too, according to our last few updates. I have about 8 WUs finished and ready to go, and I have lost two already past deadline. The others will most likely expire in the next 12-15 hours as well, and it's nighttime here now. It's a pity, as it's something like 15k points lost if they don't u/l.

Can anyone confirm the problem? It looks like the work servers and not my ISP, and there aren't any current reports that I can see on the community forum.

[Adak]

Originally Posted by dsio

Anyone tried the SMP client on machines with more than 4 cores?

Yes, I have a server currently folding with 2 X Quad's. They're folding native in WindowsXP at the moment, with two SMP clients.

One problem I've run across is that if you stop one FAH smp client, it trashes the other SMP client - making it immediately stop folding and deleting the WU it was working on, and d/l'ing a new (or the same) one, to start over!!

The way you have to do a shutdown, is to turn off the box, w/o shutting down either of the clients, first. It helps if you set the check point timer for 30 minutes, because if you shut off the box WHILE either client is in the middle of writing it's check point data - your WU will be hosed.

It's awkward at best, and shows the problems that the FAH SMP client still has. I can't recommend a dual quad box for folding (and this server won't be folding much in the near future).

[ThunderRd]

Upload problems to 171.64.65.63 and .64.122.76 are continuing - the farm can get work, and it is running, but NOTHING has uploaded from it for nearly two full days.

I have checked the server status chart with some interesting results. .65.63 is on "fail" status...I don't know what that means, but it doesn't sound good any way you cut it. I have posted the problem on the community forum and am waiting for help currently.

Anyone else with problems?

[Adak]

Just finished an SMP wu. It uploaded, but I am sent off to 0.0.0.0 address (meaning the servers are goofed and there is nothing you can do about it).

Refuse connection status means Stanford can't even contact that server.

[ThunderRd]

Well, here's an update: [the news isn't good]
.64.65.63 is unpingable and the server status page indicates *DOWN* now. That was not the case yesterday. I can ping the collection server .64.122.76, but still nothing is going up. That's what I can't figure out. Normally, the client contacts the WS, then if it can't upload or the server is busy, it contacts the CS and delivers. But that isn't happening.

Can you take a look at your log and tell me what server your last WUs went to? I'm curious. It would be the server that your client connected to when it downloaded the work.

The zeroes you got only indicate that you can't get work right now, but it isn't related to uploads, so look back at just before the calculations began, where the client was first assigned to a WS.

Looks like I'm going to lose 'em all unless Stanford gives the servers a kick very soon. I don't think that is likely; it's after business hours in the states now. At best, nothing will be done until the morning; these WUs are dead. The deadlines are going to take them out.

[Adak]

[02:29:03] + Attempting to send results
[02:29:03] - Reading file work/wuresults_03.dat from core
[02:29:03] (Read 5704965 bytes from disk)
[02:29:03] Connecting to http://171.64.65.64:8080/
[02:30:48] Posted data.
[02:30:48] Initial: 0000; - Uploaded at ~52 kB/s
[02:30:50] - Averaged speed for that direction ~52 kB/s
[02:30:50] + Results successfully sent
[02:30:50] Thank you for your contribution to Folding@Home.
[02:30:50] + Number of Units Completed: 12

That's very frustrating - Good luck!

[Samuknow]

No way to change the server it is trying to send to ?

IS this with the new beta?

[ThunderRd]

Originally Posted by Samuknow

No way to change the server it is trying to send to ?

IS this with the new beta?

No, there isn't-the WU is tied to the server it came from. And yes, it is the beta-but that's not the problem. Stanford has a frequently updated server status page you should put in your bookmarks; it's very useful:

Folding@Home server status

If you visit that page, you'll see that the WS is status "DOWN". I have informed the Pande staffers but I'm afraid nothing will be done until they come in the morning, check the problem, and get it going again. As you see Adak was uploading to a different server, and it's ok. The unfortunate part is that ALL of my machines (currently 22+my home boxen, total 25) are tied to the same server at this time. No recourse except to wait it out. I have around 8 more that will be finishing tonight and I'm already getting 0.0.0.0 on machines that need work because the server is down.

Bad situation. I'll let you know if I get any answer from the admins. Sorry Sam.

[Samuknow]

I was just curious. I have checked from time to time and I do notice quite a few of the servers down. And pretty often.

Is there any way to pick which server you DL from. Say split your farm up so all the "eggs" are not in one basket?

[Adak]

In the "old days", with the uni-core FAH client, you could restart FAH, 5 or 6 times in a row, and eventually the client would try to connect you with a back-up server, instead of the main server you'd normally get.

Don't know if that's true anymore, or even if it ever was true with the SMP client. Looking at my logs, I do see where it took 13 tries to get that connection properly made, so I could both return and be given, a WU.

Worth a try, but obviously can't do it with a borg out of reach. Also, a bit of a frustrating pain - you shouldn't find yourself in this fix.

Good news, from Vijay in the Stanford Forum:

One of our servers (vspg1) is down (taking its virtual interfaces with it as well, i.e. vspg1v and vspg1v2). It's been reset remotely and will likely be up in the morning (it is fsck-ing).

[ThunderRd]

I've asked the question in the forum and the general consensus is no, it can't be done. The way the servers are set up now you are at the mercy of the system. I once previously had a similar problem-Sam you prolly remember-when I had 15 or 20 WUs piled up. I PMd Bruce and 7im and asked them if anything special could be done; I didn't care about the points, only that Pande got the results. I felt it was an extraordinary situation, and they agreed, but they answered that after the WU is assigned there isn't anything changeable. And you can't pick an assignment server, either. End result: they all timed out.

@Adak; good news but not good enough. Nearly everything is timed out and the latest finishers are stuck on 0.0.0.0 waiting as well.

Good thing this didn't happen during the Chimp event; how would the captains have handled it?