unforum

[poozle]

I've finally found the perfect use for the spare time inbetween wu grabs, Folding@Home, I run F@H on low priority, 13thlabour on below normal and neither interrupt normal stuff, 13thlabour has priority when it gets a wu, it works really well as well

GL on cleaning out the 1_1_1 clients.

[chimera245]

I have changed the Retry times to be less agressive - to at least eliminate this from the mix.

A patch featuring this is available in

http://www.e-wire.net.au/~eb_oakla/pxc/13labour_1_2_1_patch.zip OR
http://www.e-wire.net.au/~eb_oakla/pxc/13labour_1_2_1.zip

and in actual fact in the _1_2_0 files for those who don't read this board . I'll get the 13thlabour.tk web site updated as soon as I can.

Once again an appeal to everyone on 1_1_0/1_1_1 - PLEASE UPGRADE.

[arnezami]

I think the idea of sending an short email to all 1.1.x clients sounds very good.

Also maybe its a good idea to put the server behind a dns name (eg using .to domain names). That way you can redirect clients to a different IP/port and ease the pressure on the server connection (in the future). If you create a new dns for every new (major) version of the client you can basicly redirect traffic based on client version. (You could even create several domain names based on the date a client was downloaded from the site giving even more managability.)

Right now you could change the port number on the server and block the old port. That way you would only allow newer clients to really connect to the server.

Just my 2 cents.

arnezami

PS. You could also let the newer clients first try a new port and then try the old port. That way (if you change the port on the server) the new clients will never stop working.

[jazzychad]

Yep, I can confirm through my ethereal trace that the 1.2.1 client doesn't retry quite as often. Now, of course, the problem is that this client has less of a chance of getting through since it doesn't try as often... a catch 22 I suppose... we'll have to weather the bum-rushing 1.1.1 clients until they wake up and switch...

If only the server's IP could be changed and used in the new client... that would certainly "bork" the old clients for sure i'm sure you've thought of that, though.

fwiw, I like the "send everyone an email begging them to update" tactic. I figure that since we're ddos'ing your server you have some license to spam us

[marky1124]

Looking back to before the v1.2.0 client, we had what I thought was a lot of congestion at the time but by my observation every client got a new work unit in less than 10 minutes. Given the massive speed increase of the client this balanced out to still be an overall improvement. So at the time although the system wasn't perfect things were progressing better with v1.1.1.

Since the introduction of the v1.2.x I'm now used to seeing clients sit for over 10 hours without getting a new work unit. Looking more carefully at the network traces I see that the TCP connection is formed without difficulty the problem comes when the client makes requests of the server.

For instance just now looking at the trace of a v1.2.1 client being run I see the client send the server a ValidateClientFullStats.xml request, the server then sends a ValidateClientFullStatsResponse.xml response with ValidateClientFullStatsResult = -1. Admittedly this is one of the better interactions many ValidateClientFullStats.xml requests receive a "403 Access Forbidden".

So presumably the problems are with the Microsoft IIS v5.1 webserver and/or the backend database. I've not had the chance to see a full successfull interaction so I'm not sure exactly what should happen. I'd be happy to send you some network traces if that would help you further investigate what is happening.

Is it possible that our problems are more to do with the v1.2.x client than the previous clients? Since a v1.2 client tries to send/receive 10 work units at a time rather than just one. It might be easier on the server if the next client worked on a 3 character key stem instead of the current 4 character key stem. E.g. Instead of the server sending XXXX and the client iterating over YYYY, have the server send XXX and the client does YYYYY.

This would increase the processing by 62 times and have the benefit of not only reducing how often the server is contacted but also reduce the work the backend sub-systems have to do when they are contacted.

BTW - I like the ideas of IP address and port separation.

[doublecross]

I foolishly terminated the program because it wasn't getting a work unit after many hours - now it can't even verify my identity

If the last suggestion was effectively 'bigger work units rather than more work units at a time' then I agree!

[Seej]

Wow chimera245, you're really working hard on this for us. No-one's said this lately, so thanks for all your effort. Please don't forget to eat and sleep as well

[marky1124]

Thank you

[doublecross]

Hear, hear. Don't get me wrong, you're doing a marvellous job that I would be quite incapable of doing!

[chimera245]

OK - I have disabled 1_1_1 clients. I didn't want to - but the load was just killing the server. They will continue to run, continually doing the same work unit over and over again until the owner upgrades. They are unfortunately still (briefly) troubling the Web Server - but they are not getting near the database.

Sorry for that but it had to be done.

The 1_2_0's are now starting to get some service. Since I shut down the 1_1_1s - 20 1_2_0 clients have got MWUs. This is more than got any in the last 24 hours.

As a bit of information, the various Web Service calls can get congested in two places - in the Web Server - where you would get a 403, 500 or similar message, or in the database - if this happens the Web Service call returns an exception. For ValidateClientFullStats - this is -1.

[Mathematician]

Retrying now

[mac_monkey]

Please read the above posts,

Its not a problem with the client, leave it running and normal service should return soon(ish)

[locqust]

Beat me to this, I have the same problem as well. Done all the usual stuff like disabling firewalls, virus checkers etc but to no avail still sits there either trying to validate the client or retrying to validate nevers seems to succeed. This is happening on both PC's Im running the client on.

[poozle]

[Ashin]