I can download the cufft64_80.dll file in few seconds without problem. In windows or Linux.

Finally a positive report. However, there is no reason to use the ps3grid host name, it's obsolete. Whoever wants, please try both http and https.

Can anybody confirm (e.g. with netstat or similar tool) whether or not the boinc client is going through SSL?

T

I found it interesting that the positive report came from Trotador: his account page self-declares his country to be Spain. That might lend some weight to my suspicion that other people's delays are related to international peering problems.

On my computers, I see that two alternative scheduler addresses are listed:

    <scheduler_url>http://www.ps3grid.net/PS3GRID_cgi/cgi</scheduler_url>
    <scheduler_url>https://www.gpugrid.net/PS3GRID_cgi/cgi</scheduler_url>

A scheduler contact (project update) suggests that SSL is at least attempted:

03/12/2016 15:21:58 | GPUGRID | [http] [ID#1] Info:  SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
03/12/2016 15:21:58 | GPUGRID | [http] [ID#1] Info:  ALPN, server did not agree to a protocol
03/12/2016 15:21:58 | GPUGRID | [http] [ID#1] Info:  Server certificate:
03/12/2016 15:21:58 | GPUGRID | [http] [ID#1] Info:  	 subject: CN=www.ps3grid.net
03/12/2016 15:21:58 | GPUGRID | [http] [ID#1] Info:  	 SSL certificate verify ok.

but I'm not enough of a security expert to confirm that all SSL requirements are met.

What is clear, however, is that none of the GPUGrid files have a <download_url>https: prefix, so I sincerely doubt that SSL would be used for file downloads. It might be worth a try (depending over what distance your personal tests have been run?) - BOINC can certainly handle it if specified.

I have some ideas on how we might overcome the cufft64_80.dll download problem (which wouldn't apply to the individual task files), but I'll save them until later in the diagnostic process.

I can also download without issues

https://www.gpugrid.net/download/cufft64_80.dll

http://www.gpugrid.net/download/cufft64_80.dll

No issues here either (FI), cufft64_80.dll or BOINC DL/UL.

Both http and https (cufft64_80.dll) completed within 3,5 min.


Here is my tracert (win10):

1 <1 ms <1 ms <1 ms router.asus.com [192.168.1.1]
2 9 ms 9 ms 8 ms host-109-204-128-1.tp-fne.tampereenpuhelin.net [109.204.128.1]
3 12 ms 12 ms 11 ms host-109-204-193-1.tp-fne.tampereenpuhelin.net [109.204.193.1]
4 11 ms 11 ms 11 ms host-109-204-196-129.tp-fne.tampereenpuhelin.net [109.204.196.129]
5 12 ms 11 ms 11 ms 87.236.158.3
6 16 ms 15 ms 16 ms te4-2.cr9.mt.ax.as3238.net [194.112.2.174]
7 18 ms 18 ms 18 ms te3-4.cr1.kn7.sth.se.as3238.net [194.112.2.208]
8 * * * Request timed out.
9 32 ms 32 ms 32 ms dk-uni.nordu.net [109.105.97.10]
10 48 ms 48 ms 48 ms uk-hex.nordu.net [109.105.102.97]
11 48 ms 48 ms 48 ms ndn-gw.mx1.lon.uk.geant.net [109.105.102.98]
12 69 ms 69 ms 69 ms ae0.mx1.lon2.uk.geant.net.geant.net [62.40.98.79]
13 56 ms 56 ms 56 ms ae0.mx1.par.fr.geant.net [62.40.98.77]
14 63 ms 63 ms 63 ms ae2.mx1.gen.ch.geant.net [62.40.98.153]
15 71 ms 71 ms 71 ms rediris-ias-geant-gw.mar.fr.geant.net [83.97.88.129]
16 76 ms 76 ms 76 ms rediris-ias-rediris-gw.mar.fr.geant.net [83.97.88.130]
17 82 ms 82 ms 82 ms TELMAD.AE4.uv.rt1.val.red.rediris.es [130.206.245.89]
18 90 ms 90 ms 100 ms anella-val1-router.red.rediris.es [130.206.211.70]
19 * * * Request timed out.
20 97 ms 97 ms 97 ms grosso.upf.edu [84.89.134.145]
21 98 ms 97 ms 97 ms grosso.upf.edu [84.89.134.145]
22 98 ms 97 ms 97 ms grosso.upf.edu [84.89.134.145]


-timon

On attaching to GPUGrid for the first time on a new reinstall of Win7 64-bit, it took 2 hours 10 minutes to get two shorts, after they became available. And the stalls are of a different type than before. They usually can't be manually restarted; they have to do their thing automatically after timing out, usually more than once. I am in the eastern U.S. and have a 20 Mbps/2 Mbps cable modem connection that normally does fine. But now that all the needed files are downloaded, maybe things will go more smoothly. I will not try my Linux machines for a while.

I'm in Canada,Québec
Using http://ping.eu/traceroute/


1 * * *


2 core21.hetzner.de 213.239.229.129 0.211 ms 0.215 ms
core22.hetzner.de 213.239.229.133 0.234 ms


3 core1.hetzner.de 213.239.245.177 4.853 ms
core4.hetzner.de 213.239.245.18 4.830 ms
core1.hetzner.de 213.239.245.177 4.853 ms


4 fra-ix.geant.net 80.81.192.173 de 5.240 ms 5.252 ms 5.144 ms


5 ae1.mx1.gen.ch.geant.net 62.40.98.108 gb 14.075 ms 14.072 ms 14.064 ms


6 rediris-ias-geant-gw.mar.fr.geant.net 83.97.88.129 gb 19.921 ms 19.992 ms 19.920 ms


7 rediris-ias-rediris-gw.mar.fr.geant.net 83.97.88.130 gb 45.506 ms 45.510 ms 45.648 ms


8 TELMAD.AE4.uv.rt1.val.red.rediris.es 130.206.245.89 es 51.917 ms 52.093 ms 52.085 ms


9 anella-val1-router.red.rediris.es 130.206.211.70 es 66.895 ms 66.674 ms 66.619 ms


10 * * *


11 grosso.upf.edu 84.89.134.145 es 65.079 ms 65.156 ms 65.063 ms


12 65.415 ms 65.117 ms 65.307 ms


13 65.799 ms

My tracert output


2 ms 2 ms 2 ms 92.red-80-58-67.staticip.rima-tde.net [80.58.67.92]
3 ms 2 ms 3 ms 21.red-81-46-6.customer.static.ccgg.telefonica.net [81.46.6.21]
2 ms 2 ms 2 ms 114.red-81-46-8.customer.static.ccgg.telefonica.net [81.46.8.114]
3 ms 3 ms 3 ms rediris.alta.espanix.net [193.149.1.154]
4 ms 4 ms 4 ms CIEMAT.AE2.telmad.rt4.mad.red.rediris.es [130.206.245.2]
19 ms 19 ms 19 ms TELMAD.AE4.uv.rt1.val.red.rediris.es [130.206.245.89]
17 ms 15 ms 19 ms anella-val1-router.red.rediris.es [130.206.211.70]
* * * Tiempo de espera agotado para esta solicitud.
16 ms 16 ms 15 ms grosso.upf.edu [84.89.134.145]
16 ms 16 ms 16 ms grosso.upf.edu [84.89.134.145]
16 ms 16 ms 16 ms grosso.upf.edu [84.89.134.145]

OK, while we are doing tracert, from eastern Pennsylvania USA:

Tracing route to www.gpugrid.net [84.89.134.145] over a maximum of 30 hops:

1    <1 ms    <1 ms    <1 ms  192.168.0.1
2     7 ms     7 ms     8 ms  bdl1.tlg-ubr1.atw-tlg.pa.cable.rcn.net 10.50.48.1]
3    10 ms    11 ms    11 ms  bdle8-sub201.aggr2.phdl.pa.rcn.net[207.172.196.203]
4    16 ms     9 ms    17 ms  xe-7-0-2.bar2.Philadelphia1.Level3.net [4.30.46.33]
5   106 ms   111 ms   119 ms  ae-1-3101.bar1.Madrid2.Level3.net [4.69.210.222]
6   109 ms   107 ms   105 ms  ae-1-3101.bar1.Madrid2.Level3.net [4.69.210.222]
7   108 ms   106 ms   107 ms  213.242.113.78
8   113 ms   124 ms   116 ms  TELMAD.AE4.uv.rt1.val.red.rediris.es [130.206.245.89]
9   120 ms   119 ms   119 ms  anella-val1-router.red.rediris.es [130.206.211.70]
10     *        *        *     Request timed out.
11   118 ms   118 ms   119 ms  grosso.upf.edu [84.89.134.145]
12   119 ms   119 ms   117 ms  grosso.upf.edu [84.89.134.145]
13   118 ms   121 ms   119 ms  grosso.upf.edu [84.89.134.145]

It looks like a pretty direct route to me, and I don't see any problems.
I think the problem is more subtle than mere routing or speed. The network experts will need to find it.

I don't really understand... You're downloading projects through a website and not through BOINC and able to do the project?

I just used the general URL shown in Boinc Manager, but could try anything else if you think it will make a differnce.

Found this...

traceroute to www.gpugrid.net (84.89.134.145), 30 hops max, 60 byte packets
1 172.20.10.1 (172.20.10.1) 4.123 ms 4.123 ms 4.116 ms
2 * * *
3 10.222.132.97 (10.222.132.97) 41.415 ms 245.630 ms 246.112 ms
4 10.222.132.105 (10.222.132.105) 37.274 ms 40.748 ms 37.860 ms
5 10.222.133.85 (10.222.133.85) 46.518 ms 219.441 ms 219.198 ms
6 10.222.143.246 (10.222.143.246) 46.099 ms 36.896 ms 37.121 ms
7 10.170.180.130 (10.170.180.130) 37.117 ms 38.415 ms 10.170.168.237 (10.170.168.237) 33.618 ms
8 10.170.183.93 (10.170.183.93) 41.105 ms 216.113.123.166 (216.113.123.166) 41.849 ms 10.170.183.93 (10.170.183.93) 36.298 ms
9 216.113.126.222 (216.113.126.222) 36.675 ms 37.101 ms ix-et-9-1-0-0.tcore1.MTT-Montreal.as6453.net (64.86.31.61) 37.343 ms
10 if-ae-5-2.tcore2.N0V-New-York.as6453.net (64.86.226.58) 41.958 ms if-ae-0-2.tcore2.MTT-Montreal.as6453.net (216.6.115.90) 40.412 ms if-ae-5-2.tcore2.N0V-New-York.as6453.net (64.86.226.58) 41.591 ms
11 if-ae-5-2.tcore2.N0V-New-York.as6453.net (64.86.226.58) 44.245 ms if-ae-2-2.tcore1.N0V-New-York.as6453.net (216.6.90.21) 39.135 ms 43.093 ms
12 if-ae-2-2.tcore1.N0V-New-York.as6453.net (216.6.90.21) 43.831 ms 44.601 ms 44.119 ms
13 if-ae-7-2.tcore1.NTO-New-York.as6453.net (63.243.128.25) 40.093 ms 39.076 ms if-ae-7-5.tcore1.NTO-New-York.as6453.net (63.243.128.141) 40.064 ms
14 ae9.edge1.NewYork.Level3.net (4.68.62.185) 39.897 ms if-ae-9-2.tcore1.N75-New-York.as6453.net (63.243.128.122) 44.537 ms ae9.edge1.NewYork.Level3.net (4.68.62.185) 40.853 ms
15 ae9.edge1.NewYork.Level3.net (4.68.62.185) 40.346 ms ae-1-3101.bar1.Madrid2.Level3.net (4.69.210.222) 134.813 ms 138.787 ms
16 ae-1-3101.bar1.Madrid2.Level3.net (4.69.210.222) 134.964 ms 135.806 ms 136.246 ms
17 ae-1-3101.bar1.Madrid2.Level3.net (4.69.210.222) 133.954 ms 136.430 ms 135.717 ms
18 213.242.113.78 (213.242.113.78) 136.559 ms 136.123 ms TELMAD.AE4.uv.rt1.val.red.rediris.es (130.206.245.89) 143.533 ms
19 anella-val1-router.red.rediris.es (130.206.211.70) 147.432 ms 150.963 ms TELMAD.AE4.uv.rt1.val.red.rediris.es (130.206.245.89) 143.690 ms
20 anella-val1-router.red.rediris.es (130.206.211.70) 149.055 ms 145.821 ms *
21 * grosso.upf.edu (84.89.134.145) 147.493 ms 148.057 ms
22 grosso.upf.edu (84.89.134.145) 147.337 ms 147.315 ms 147.422 ms
23 grosso.upf.edu (84.89.134.145) 145.822 ms !X 148.899 ms 145.689 ms !X


!X means "communication administratively prohibited" and !Z "communication with destination host administratively prohibited" As far as I remember, you get !X on ipv4 and !Z on ipv6 and it should be documented in the man (8) pages.

Since Linux uses UDP for trace-routes, this can originate from a --reject-with icmp-host-prohibited rule at the destination. Some Linux distros have this as a default configuration. To fix this you need to reply with --reject-with icmp-port-unreachable on UDP ports 33434 through 33534.

I don't really understand... You're downloading projects through a website and not through BOINC and able to do the project?

I believe I've read that BOINC uses the same download method normally used for websites, on the same port, but then does something rather different with the files it downloads.

What is clear, however, is that none of the GPUGrid files have a <download_url>https: prefix, so I sincerely doubt that SSL would be used for file downloads. It might be worth a try (depending over what distance your personal tests have been run?) - BOINC can certainly handle it if specified.

That is to allow download files to be cached by proxies and lift some weight from the server. HTTP proxies can't cache httpS requests, by design. And downloading this files by HTTP is equally secure, because they are checked against checksum from scheduler reply. I hope this does not change.

Problem repeated again, now host connects, but does not get the job :(

http://www.gpugrid.net/results.php?hostid=170640

05.12.2016 12:52:40 | GPUGRID | Sending scheduler request: Requested by project.
05.12.2016 12:52:40 | GPUGRID | Requesting new tasks for NVIDIA GPU
05.12.2016 12:52:44 | GPUGRID | Scheduler request completed: got 0 new tasks
05.12.2016 12:52:44 | GPUGRID | No tasks sent
05.12.2016 12:52:44 | GPUGRID | No tasks are available for Long runs (8-12 hours on fastest card)
05.12.2016 12:52:44 | GPUGRID | Project has no tasks available

---

Problem repeated again, now host connects, but does not get the job :(

what your event log shows is quite normal these days.
There are simply no new tasks available.
From an information I read here in the Forum, the GPUGRID people are waiting until the server migration problems are solved, before new tasks are being made available.

The few tasks which can be downloaded once in a while are the ones which are created "dynamically" by returned WUs etc.

Unable to upload this one last file. All the other files from this task were successfully uploaded and this is a reoccurring issue for this one file.


Wed 30 Nov 2016 09:06:33 PM EST | GPUGRID | Started upload of e40s17_e30s13p0f6-PABLO_SH2TRIPEP_K_TRI_2-0-1-RND0874_0_9
Wed 30 Nov 2016 09:06:35 PM EST | GPUGRID | [error] Error reported by file upload server: can't open file
Wed 30 Nov 2016 09:06:35 PM EST | GPUGRID | Temporarily failed upload of e40s17_e30s13p0f6-PABLO_SH2TRIPEP_K_TRI_2-0-1-RND0874_0_9: transient upload error
Wed 30 Nov 2016 09:06:35 PM EST | GPUGRID | Backing off 05:32:01 on upload of e40s17_e30s13p0f6-PABLO_SH2TRIPEP_K_TRI_2-0-1-RND0874_0_9

I have a similar task that won't upload.

Thu 01 Dec 2016 08:51:49 AM EST | GPUGRID | Started upload of e9s10_e1s6p0f56-GERARD_ENDOPEP_AMB_frag29_UP_2-0-1-RND7786_0_9
Thu 01 Dec 2016 08:51:51 AM EST | GPUGRID | [error] Error reported by file upload server: can't open file
Thu 01 Dec 2016 08:51:51 AM EST | GPUGRID | Temporarily failed upload of e9s10_e1s6p0f56-GERARD_ENDOPEP_AMB_frag29_UP_2-0-1-RND7786_0_9: transient upload error
Thu 01 Dec 2016 08:51:51 AM EST | GPUGRID | Backing off 03:00:35 on upload of e9s10_e1s6p0f56-GERARD_ENDOPEP_AMB_frag29_UP_2-0-1-RND7786_0_9

5 days with no response on the "Error reported by file upload server: can't open file" issues.

Is there a possible fix, or should we just Abort the Transfers?

EDIT: Never mind, I just realized it timed out. I'll abort transfer.

I think I've encountered the "[error] Error reported by file upload server: can't open file" message before on other BOINC projects, and found it a difficult one to decipher.

IIRC, it's basically in two parts:

"Error reported by file upload server" - it's the upload component of the BOINC server suite that's telling you there's a problem.

"[error] can't open file" - but the problem is that *your computer* can't open the file, so there's nothing that can be uploaded.

In the cases I remember looking at, the named file couldn't be found on the user's computer (it would be in the project directory, if present).

That can be a project problem - maybe the job template says that the named file is essential, but the application doesn't create it - or it can be a local problem (file has been deleted in a power or hardware failure, or by an over-enthusiastic anti-malware or security program).

Worth checking the named file on your local machine if it ever happens again.

Tasks won't download, they only download 2% every time BOINC is restarted. Then when they finish they don't start the task it still says downloading. I just started computing on that computer last night on WGC, which works fine. My laptop won't get new tasks but is currently computing one from a few days ago.

My laptop just finished the task and is now stuck at downloading on one of them, I was going to start running SETI to occupy the GPU, but their servers are down too. -.-

WUs are created dynamically on the basis of the ones returned. We are not creating more yet because we are still testing.

T

It is good that you are doing testing, but if we go too long testing and not creating new WUs, than this project will come to a screeching halt, with no more WUs.


And one more thing, those people with download problems, try doing this:

Open Boinc Manager, make sure under View it is set to Advanced View, if it isn't set to it already.

At the top, click Activity, then click Suspend network activity, wait a few seconds and click Network activity always.

That will get the download to continue, if it stalls again, repeat this procedure until the files finish downloading.

(I saw this in one of the other threads, and I can't remember which one.)

And another thing, my windows xp computer, which has a 100 Mb/s network connection, has a higher tendency of stalled downloads than my windows 10 computer, which has a 1 Gb/s network connection. I hope this helps in solving this problem.

WUs are created dynamically on the basis of the ones returned. We are not creating more yet because we are still testing.

T

Testing is before an upgrade not after...
It is really nice you make your distributed project. But now, you seems to be, "not professional". One week after it isn't working.
It's seems like in France, research don't have money or underestimate the need for a team of info tech... Because in the real world, like an ISP, commercial compagny or any private compagny, 1 week offline is just not possible !

But, I least, you made one. I am french and I don't see a lot of french institute here ! (public or private).
Yet, a long way to make....
So, good luck ! My CUDA's will be here when you will.

All of your services are on the same host (status page): don't use VM or Docker ?