The 1.07GB binaries load at just ~39 KBps.

Should I wait a few days or cancel directly?

Yes, same situation here. So far trying to download for over 16 hours elapsed now with only 9% completion

Today the deadline might be reached before the calculation starts.
Is the project server connected via ISDN oder 56k Modem line?

Is the project server connected via ISDN oder 56k Modem line?

The Internet is not a homogeneous entity.
There may be a dozen telecom operators from you to GPUGRID, each of which, in turn, has dozen of routes.
No one can control or choose a specific route along its entire length.
There may have been a problem somewhere and you were unlucky.

Personally, I have not noticed serious problems with upload and download speed for a long time.

Updload:
28/03/2023 17:52:49 | GPUGRID | Computation for task Bace_protein_nH_13j_4o_2-QUICO_TEST_ATM-0-1-RND1584_0 finished
28/03/2023 17:52:51 | GPUGRID | Started upload of Bace_protein_nH_13j_4o_2-QUICO_TEST_ATM-0-1-RND1584_0_0
28/03/2023 17:57:34 | GPUGRID | Finished upload of Bace_protein_nH_13j_4o_2-QUICO_TEST_ATM-0-1-RND1584_0_0
28/03/2023 17:57:42 | GPUGRID | Sending scheduler request: To report completed tasks.

28/03/2023 23:33:17 | GPUGRID | Computation for task e00002a03085-ABOU_rnd_ppod_expand_demos29_2_exp6-0-1-RND1747_0 finished
28/03/2023 23:33:20 | GPUGRID | Started upload of e00002a03085-ABOU_rnd_ppod_expand_demos29_2_exp6-0-1-RND1747_0_0
28/03/2023 23:33:49 | GPUGRID | Finished upload of e00002a03085-ABOU_rnd_ppod_expand_demos29_2_exp6-0-1-RND1747_0_0
28/03/2023 23:33:54 | GPUGRID | Sending scheduler request: To report completed tasks.

Download:
28/03/2023 17:57:45 | GPUGRID | Started download of p38_2u_2k_3_3A-QUICO_TEST_ATM-0-input
28/03/2023 17:59:17 | GPUGRID | Finished download of p38_2u_2k_3_3A-QUICO_TEST_ATM-0-input
28/03/2023 17:59:18 | GPUGRID | Starting task p38_2u_2k_3_3A-QUICO_TEST_ATM-0-1-RND7131_2

28/03/2023 23:33:57 | GPUGRID | Started download of PTP1B_new_23477_23482_OFF_2-QUICO_ATM_OPENFF-0-input
28/03/2023 23:34:00 | GPUGRID | Finished download of PTP1B_new_23477_23482_OFF_2-QUICO_ATM_OPENFF-0-input
29/03/2023 00:33:57 | GPUGRID | Sending scheduler request: Requested by project.

As you can see, both took no more than a few minutes.
So I doubt that the problem is at the GPUGRID level, and no need blindly blame them : )

By the way, I also have a very slow download and upload. The units can be seen on my computer, but have not yet been downloaded.

Greetings from Daniel

As a general comment on BOINC projects, not directly linked with this problem, there can be an issue every time a new application version is released - and we're going through a period of significant testing at the moment.

When there's a new application version, everyone has to download the new program and all the associated support files. At GPUGrid, those downloads can be very, very, big - and they will congest the internet link connecting the project's servers to the outside world.

It would be technically possible for the project to outsource the downloads to an external caching server: after all, everyone will be downloading the exact same files (unlike normal task downloads, where every one is different). But it would complicate the scientists' testing procedure, and probably would be too much trouble. We'll just have to grin and bear it.

This is the most unresponsive web site I've ever visited. I wonder if they'll ever make it respond at normal rates?

This site can’t be reached www.gpugrid.net took too long to respond.
Try:
Checking the connection
Checking the proxy and the firewall
Running Windows Network Diagnostics
ERR_CONNECTION_TIMED_OUT

This is the most unresponsive web site I've ever visited.

Before blaming project, just do mtr(or WinMTR for Win), and find where drops/high latency rise.
The problem may have nothing to do with the infrastructure of the project itself.

If your goal is not just to vent your discontent on the forum, but to pay attention to real project's problems, then instead of words, post here traces, your public IP and time of test.

Or:

This is a well-known problem at this project if you run more than one host on the same internet connection: it's a form of DDoS protection. If a different host on the same IP address has contacted the project recently, the new connection won't be accepted immediately. Windows computers tend to be more impatient, and give up quicker with this error message.

Or:

I strongly doubt that the project's web server has such a low threshold (or rather a large time window for tracking new connections) to limit the occasional connections from BOINC-clients, even if you have a dozen computers "sitting" on one public IP-address.
When receiving repeated response with absence of tasks, BOINC-client increases delay before contacting the server again, so I don't see any notable prerequisites for DoS (not DDoS. Distributed DoS = requests from multiple addresses).
And if your number of computers has exceeded half a hundred, then I am sure that you will have the means to rent a small IP-pool (/28 subnet = 12 IPs) of public addresses to ensure the normal operation of such farm :)
And finally: how will just whining on the forum help the cause?
And this appeal is not from beginner, who has encountered such problem for the first time.
If the problem is really so acute and really on the side of the project, then all the old-timers are already aware that the project has never had enough IT resources to deal with such technical problems and implement some optimizations or upgrades.
So if everything is clear, then why pour empty words on the forum over and over again? *sigh*

Except as Richard has posted, we 'old-timers' who have crunched the project for half a dozen years or more have observed the behavior consistently and correlated the severity of the issue with the number of hosts contacting the project from the same external IP address.

Also have proven that reducing the number of hosts contacting the project to just one instantly removes the problem.

So either accept the conventional thought on the matter or ignore it.

Your choice.

So either accept the conventional thought on the matter or ignore it.

So I did not deny the existence of the problem itself.
I only doubted its sources or methods of its diagnosis.

And still the question remains open - what for to shake the air to no avail? -_-

Here is some traceroute
$ tracert www.gpugrid.net

Routenverfolgung zu www.gpugrid.net [84.89.134.145]
über maximal 30 Hops:

1 6 ms 10 ms 3 ms fritz.box [192.168.178.1]
2 8 ms 9 ms 7 ms p3e9bf684.dip0.t-ipconnect.de [62.155.246.132]
3 9 ms 9 ms 21 ms f-eh1-i.F.DE.NET.DTAG.DE [217.5.85.162]
4 * * * Zeitüberschreitung der Anforderung.
5 48 ms 48 ms 50 ms ae1.3102.edge1.Madrid1.level3.net [4.69.140.2]
6 52 ms 51 ms 40 ms SERVEISWEB.bar2.Barcelona1.Level3.net [213.242.114.122]
7 35 ms 40 ms 40 ms CIEMAT.RT2.AE1-0.telmad.rt4.mad.red.rediris.es [130.206.245.2]
8 49 ms * 58 ms anella-router.red.rediris.es [130.206.214.98]
9 * * * Zeitüberschreitung der Anforderung.
10 43 ms 44 ms 43 ms 84.89.159.147
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * 47 ms * grosso.upf.edu [84.89.134.145]
14 44 ms * 46 ms grosso.upf.edu [84.89.134.145]

Does it mean, there are two servers withe the same ip?

ping shows often timeout.

With me, the Windows computers no longer get updates, only the one Linux computer. After what I have read above, I will turn off my router and turn it on again to get a new IP. It is renewed every night but maybe it will help if I restart the router.

Greetings from Daniel

Does it mean, there are two servers withe the same ip?

No, not in this case.
It seems that its some kind of glitch.
I can't reproduce that.


I suggest you to use WinMTR Redux as replacement for standard Windows tracert tools, as WinMTR much more fast, flexible and useful.

And try to do more and longer(10-15 min) traces in different time of day, because network load may vary very much(in your ISP network, in transit and in GPUGRID project network).