After months, I just tried Folding@Home, and it's desolate.

[StefanR5R]

it's not my Internet link at home which is at fault individually, as I noted in the other thread. It must be something with the whole route which makes F@H's work servers and collection servers (or F@H's gateways or whatever) break up my uploads randomly.

On third thought, it could also be a router within my ISP's network which cuts me off randomly. Or it could be a combination of some sort of traffic shaping by my ISP, and the F@H servers reacting badly to that. I have no way to know. But so far I never noticed other cases which would indicate that my ISP discriminated certain traffic.

One of the two results from Sunday went through on Monday morning BTW, after a large number of retries by the client of course; I haven't counted. The other result still wasn't uploaded today in the morning.

 

[StefanR5R]

(Continuing this here rather than in the stats thread…)

CPDN's upload server (upload7.cpdn.org) is presumably crowded and I've got two trickle files for each task in the client's upload retry queue by now. (But there are also two successful trickles listed for each of my two tasks on the web site, so it's not completely hopeless.)

Uhm no, it is hopeless for me: While the trickles are listed on the web site and got credit granted normally, the files of these trickles haven't been uploaded yet (one ~95 MB file per trickle). Meanwhile, I've got no so such problems with PrimeGrid (never had). One big difference: PrimeGrid's server is located here in Germany.

traceroute www.primegrid.com shows me 13 hops, and ~41 ms roundtrip times of the TTL probes to the very last one.

traceroute -m 200 upload7.cpdn.org shows me 200 hops (obviously bogus), and ~270…350 ms roundtrip times to the last visible hop, which is the 15th at 141.223.253.61 (upload7.cpdn.org resolves to 141.223.16.156).

sudo traceroute -I upload7.cpdn.org shows me 18 hops, and ~330 ms ICMP roundtrip time to the very last one, which is eawah.postech.ac.kr (141.223.16.156).

That is, I've got issues shipping large files to either the US (Folding@Home) or to South Korea (CPDN, current WAH2 batch).

I'll have to look whether or not client-side settings can reduce the connection losses.

Edit:

I took a traceroute to two work servers and one collection server of F@H, while there was no transfer was going on. The traceroutes showed ~16…20 ms when it got to Frankfurt, and jumped to ~105…110 ms on the very next step when it got to either Boston or Philadelphia. From there, latency practically didn't get any higher when the last responding hosts in the routes were reached

I repeated this with traceroute -I now:
work server 131.239.113.97: 15 hops, ~110 ms
work server 158.130.118.24: 16 hops, ~135…150 ms
collection server 158.130.118.26: 16 hops, ~110 ms

However, neither 110 nor 150 nor even 330 ms seem so bad to me when all what is to be accomplished is a large file transfer without quality of service requirements.

Edit 2:

I'll have to look whether or not client-side settings can reduce the connection losses.

Hmm. The default values of the most relevant transfer related options should already be quite resistant to high latencies during transfers:
<http_transfer_timeout>300</http_transfer_timeout> (Abort HTTP transfers if idle for 300 seconds. 300 is the default according to documentation.)
<http_transfer_timeout_bps>10</http_transfer_timeout_bps> (An HTTP transfer is considered idle if its transfer rate is below 10 bits per second. The default values is not documented, but 10 seems to be it in the initial population in cc_config.xml files.)

 

[Skillz]

Whats your connection look like going to teamanandtech.org and 192.111.155.210 (Both servers I own)

 

[StefanR5R]

I guess I'll check this tomorrow, because right now the link is fully utilized with mass uploads to PrimeGrid, and it's getting late in the day.

 

[StefanR5R]

Oh, and while several PrimeGrid attached hosts are (flawlessly) spamming PG with myriads of result files, the laptop is slowly but steadily working on two active uploads of the CPDN trickle files. The speeds of these two uploads are down to a few KBps each now, but from the looks of it, they are not breaking up!

I am going to configure a transfer speed limit in the CPDN attached client tomorrow and see if it helps with connection stability to South Korea.

Edit:
Nope, the two uploads failed again eventually at different points in time, both with the usual nondescript "transient HTTP error".

 

[StefanR5R]

Whats your connection look like going to teamanandtech.org and 192.111.155.210 (Both servers I own)

teamanandtech.org: 19 hops, ~135…165 ms roundtrip times
192.111.155.210: 20 hops, ~135…200 ms roundtrip times
from three quick tests right now, with moderate PrimeGrid traffic in the background

 

[StefanR5R]

I am happy to report that I succeeded to upload two ~95 MB sized trickle files to upload7.cpdn.org. The conditions under which this happened:
– Circa half of my internet link is used by the PrimeGrid attached hosts for normal PPSE operation. I.e. I am currently not in recovery from a previous internet outage.
– The CPDN client is configured to the default of 2 simultaneous transfers per project, and to a non-default maximum transfer speed of 50 kB/s. That is, the two files were uploaded in parallel at 25 kB/s each.
I am trying 60 kB/s for the next couple of pending files…
Edit: There still remains a chance of transfers failing with "transient HTTP error". But it's better than before when no transfers succeeded at all.

I don't think FAHClient has got a similar option to throttle the upload speed.

As reported in #9, my internet link is performing at ~8 Mbit/s = ~1000 kByte/s for large transfers to German peers.

 

[StefanR5R]

Over night, eight more of CPDN's ~95MB trickle files were uploaded. Just two files remain in retries, waiting for CPDN's upload handler to release file locks.

So it seems as if I can keep my aggregate upstream network utilization somewhere below the limit which my ISP imposes, then BOINC's HTTP errors are reduced to a level which gets me reasonably going with sites at other continents.

I still have no idea how I could test this theory with FAHClient. Maybe a VPN with a server in Germany — or just a SOCKS5 proxy or even just a HTTP proxy located in Germany — could get me going with F@H instead. (Because, as mentioned, large and/or many transfers to PrimeGrid's BOINC server work for me.)

The central mystery remains: I did not have these issues when I was last active at F@H, which was in January 2023. What has changed since then?