That sounds like the expected behaviour if the communications channel - end-to-end, anywhere along the line - has an intermediate device which is dropping packets.

If a packet is dropped in the middle of the transfer, there's a 'hole' in the received data where the missing packet should be, and I think BOINC's progress meter only shows data acknowledged without holes.

When the server requests a resend of the missing packet, and finally acknowledges it, the hole is filled in and the 'progress so far' jumps to include the later packets which have already been received out of order.

I've just watched task 16759934 uploading from the north of England. 107 MB, showing ~445 KB/sec steady speed, completed in 246 seconds (at that speed, it should have been 240 seconds, so a little loss).

I have a FTTC optical connection, with ~10 Mbit/sec uplink. (Router is currently showing 9.999 Mbps). So I was getting ~90% theoretical maximum. Nothing obviously wrong there.

I think that, like last time, the problem isn't the GPUGrid server, but some link, switch, or router in the international connector between your ISP and Spain.

since yesterday, the upload speed is back to what it normally is:

on my WinXP machines, the upload speed to GPUGRID normally is between 280 and 380 KBps.
On my Windows10 machines it normally is between 600 and 700 KBps.

so let's see for how long this will last.

Hi all,

I rejoined this project after a long brake as my old GPUs were not powerful enough to support it.
The new one is fast enough and it finished a few WUs in the past days.

Like Erich56 I noticed intermittent download/upload problems but today it all seems to work at full speed.

Based on Richard Haselgrove's comments I suggest to post some traceroute paths.
If there is a common network node in the traces of affected users that is missing in the traces of other users this may be a hint to identify the bottleneck.


My traces (LAN and local ISP hops removed):

traceroute -I www.gpugrid.org
traceroute to www.gpugrid.org (84.89.134.145), 30 hops max, 60 byte packets
 4  87.186.200.142 (87.186.200.142)  25.197 ms  25.216 ms  25.416 ms
 5  f-ed8-i.F.DE.NET.DTAG.DE (217.5.95.114)  27.937 ms  28.805 ms  28.823 ms
 6  te0-0-0-5-4.agr41.fra03.atlas.cogentco.com (130.117.14.149)  28.825 ms  24.536 ms  24.509 ms
 7  be3186.ccr41.fra03.atlas.cogentco.com (130.117.0.1)  24.495 ms  24.475 ms  24.454 ms
 8  be2799.ccr41.par01.atlas.cogentco.com (154.54.58.234)  37.299 ms  37.221 ms  37.146 ms
 9  be3325.ccr21.bio02.atlas.cogentco.com (130.117.48.205)  49.148 ms  49.379 ms  49.283 ms
10  be3357.ccr31.mad05.atlas.cogentco.com (130.117.1.21)  54.259 ms  54.088 ms  54.006 ms
11  be3375.agr22.mad05.atlas.cogentco.com (130.117.50.202)  55.501 ms  55.724 ms  55.645 ms
12  be2853.rcr11.b015537-1.mad05.atlas.cogentco.com (154.54.56.62)  51.609 ms  53.262 ms  53.184 ms
13  149.11.68.2 (149.11.68.2)  56.547 ms  55.245 ms  55.159 ms
14  CIEMAT.AE2.telmad.rt4.mad.red.rediris.es (130.206.245.2)  52.929 ms  52.273 ms  52.207 ms                                                                                     
15  TELMAD.AE4.uv.rt1.val.red.rediris.es (130.206.245.89)  58.730 ms  58.265 ms  58.181 ms                                                                                        
16  anella-val1-router.red.rediris.es (130.206.211.70)  66.893 ms  68.186 ms *                                                                                                    
17  * * *                                                                                                                                                                         
18  84.89.159.147 (84.89.159.147)  63.540 ms  63.841 ms  63.673 ms
19  * * *
20  * * *
21  grosso.upf.edu (84.89.134.145)  67.743 ms  68.738 ms  68.571 ms

Cheers

104MB Upload this morning looked fine until about 70%, then:

12/14/2017 7:33:32 AM | GPUGRID | [error] Error reported by file upload server: [e46s4_e1s74p1f193-PABLO_p27_wild_0_sj403_IDP-1-2-RND2605_0_9] locked by
file_upload_handler PID=112630
12/14/2017 7:33:32 AM | GPUGRID | Temporarily failed upload of e46s4_e1s74p1f193-PABLO_p27_wild_0_sj403_IDP-1-2-RND2605_0_9: transient upload error
12/14/2017 7:33:32 AM | GPUGRID | Backing off 00:00:46 on upload of e46s4_e1s74p1f193-PABLO_p27_wild_0_sj403_IDP-1-2-RND2605_0_9

Then it went into a backoff/retry loop for several minutes, then picked up again at the "normal" 130-140KBps and completed.

Win

Based on Richard Haselgrove's comments I suggest to post some traceroute paths.

Mine looks like this (using Windows):

tracert www.gpugrid.org

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

  5    13 ms    13 ms    12 ms  core1-hu0-17-0-5.colindale.ukcore.bt.net [195.99.127.150]
  6    14 ms    14 ms    14 ms  peer6-hu0-6-0-2.telehouse.ukcore.bt.net [62.172.103.13]
  7    13 ms    13 ms    12 ms  gi3-0.lonth-inter-1.interoute.net [195.66.224.53]
  8    28 ms    28 ms    26 ms  ae1-0.par-gar-score-1-re0.interoute.net [212.23.42.21]
  9    34 ms    35 ms    34 ms  ae1-0.mad-001-score-1-re0.interoute.net [89.202.161.21]
 10    35 ms    35 ms    34 ms  206.pool1.dialup.cybernet-ag.de [195.143.124.206]
 11    42 ms    42 ms    41 ms  TELMAD.AE4.uv.rt1.val.red.rediris.es [130.206.245.89]
 12     *       56 ms    56 ms  anella-val1-router.red.rediris.es [130.206.211.70]
 13     *        *        *     Request timed out.
 14     *       55 ms    55 ms  84.89.159.147
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17    48 ms    49 ms    47 ms  grosso.upf.edu [84.89.134.145]

Why on earth do I go via a dialup pool in Germany?

Here's my tracert from Nebraska, USA. Looks like I wander in atlas.congentco] system for quite a distance, but have the same timeouts near grosso.upf.edu, including that device with no DNS entry.
http://www.cogentco.com/files/images/network/network_map/2017web_networkmap_page.jpg

5 31 ms 31 ms 32 ms dalsbprj01-ae1.0.rd.dl.cox.net [68.1.2.109]
6 23 ms 23 ms 24 ms lag-105.ear4.Dallas1.Level3.net [4.16.234.37]
7 * * * Request timed out.
8 32 ms 30 ms 31 ms Cogent-level3-200G.Dallas1.Level3.net [4.68.72.34]
9 24 ms 23 ms 23 ms be2764.ccr32.dfw01.atlas.cogentco.com [154.54.47.213]
10 34 ms 34 ms 33 ms be2433.ccr22.mci01.atlas.cogentco.com [154.54.3.214]
11 46 ms 45 ms 45 ms be2832.ccr42.ord01.atlas.cogentco.com [154.54.44.170]
12 70 ms 71 ms 71 ms be2718.ccr22.cle04.atlas.cogentco.com [154.54.7.130]
13 62 ms 63 ms 63 ms be2879.ccr22.alb02.atlas.cogentco.com [154.54.29.174]
14 65 ms 64 ms 64 ms be2302.ccr32.bos01.atlas.cogentco.com [154.54.43.13]
15 129 ms 129 ms 128 ms be2983.ccr42.lon13.atlas.cogentco.com [154.54.1.177]
16 134 ms 133 ms 134 ms be12489.ccr42.par01.atlas.cogentco.com [154.54.57.70]
17 147 ms 146 ms 146 ms be3324.ccr22.bio02.atlas.cogentco.com [130.117.2.65]
18 154 ms 153 ms 152 ms be3358.ccr32.mad05.atlas.cogentco.com [130.117.1.97]
19 160 ms 161 ms 161 ms be3378.agr21.mad05.atlas.cogentco.com [154.54.36.174]
20 151 ms 151 ms 151 ms be2852.rcr11.b015537-1.mad05.atlas.cogentco.com [154.54.36.166]
21 155 ms 155 ms 164 ms 149.11.68.2
22 168 ms 166 ms 167 ms CIEMAT.AE1.cica.rt1.and.red.rediris.es [130.206.245.38]
23 188 ms 194 ms 217 ms CICA.AE1.uv.rt1.val.red.rediris.es [130.206.245.34]
24 175 ms 174 ms 176 ms anella-val1-router.red.rediris.es [130.206.211.70]
25 * * * Request timed out.
26 175 ms 175 ms 174 ms 84.89.159.147
27 * * * Request timed out.
28 * * * Request timed out.
29 193 ms 194 ms 192 ms grosso.upf.edu [84.89.134.145]

Win

From Northern Virginia VZ FiOS.

4    10 ms     6 ms     7 ms  B3361.WASHDC-LCR-21.verizon-gni.net [100.41.128.16]
  5     *        *        *     Request timed out.
  6    10 ms     8 ms     9 ms  0.et-5-1-0.BR2.IAD8.ALTER.NET [140.222.239.85]
  7    13 ms    12 ms    12 ms  be3018.ccr41.iad02.atlas.cogentco.com [154.54.10.197]
  8    12 ms    11 ms     9 ms  be3084.ccr42.dca01.atlas.cogentco.com [154.54.30.65]
  9    16 ms    17 ms    15 ms  be2807.ccr42.jfk02.atlas.cogentco.com [154.54.40.109]
 10    82 ms    81 ms    82 ms  be2490.ccr42.lon13.atlas.cogentco.com [154.54.42.86]
 11    92 ms    92 ms    93 ms  be12489.ccr42.par01.atlas.cogentco.com [154.54.57.70]
 12   104 ms   104 ms   105 ms  be3324.ccr52.bio02.atlas.cogentco.com [130.117.2.65]
 13   104 ms   106 ms   106 ms  be3358.ccr32.mad05.atlas.cogentco.com [130.117.1.97]
 14   106 ms   106 ms   106 ms  be3378.agr21.mad05.atlas.cogentco.com [154.54.36.174]
 15   105 ms   107 ms   106 ms  be2852.rcr11.b015537-1.mad05.atlas.cogentco.com [154.54.36.166]
 16   112 ms   113 ms   112 ms  149.11.68.2
 17   113 ms   113 ms   115 ms  CIEMAT.AE2.telmad.rt4.mad.red.rediris.es [130.206.245.2]
 18   123 ms   124 ms   122 ms  TELMAD.AE4.uv.rt1.val.red.rediris.es [130.206.245.89]
 19   123 ms   118 ms   118 ms  anella-val1-router.red.rediris.es [130.206.211.70]
 20     *        *        *     Request timed out.
 21   127 ms   126 ms   124 ms  84.89.159.147
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24   138 ms   142 ms   140 ms  grosso.upf.edu [84.89.134.145]

And using a VPN with a Swiss location.

  1   118 ms   118 ms   118 ms  10.69.10.1
  2   118 ms   119 ms   120 ms  5.157.7.81
  3   120 ms   121 ms   119 ms  5.157.4.25
  4   119 ms   120 ms   119 ms  83.231.187.177
  5   140 ms   139 ms   138 ms  ae-16.r24.frnkge08.de.bb.gin.ntt.net [129.250.7.16]
  6   152 ms   151 ms   150 ms  ae-5.r24.londen12.uk.bb.gin.ntt.net [129.250.3.12]
  7   238 ms   171 ms   175 ms  ae-6.r01.mdrdsp03.es.bb.gin.ntt.net [129.250.4.138]
  8   182 ms   174 ms   174 ms  rediris.baja.espanix.net [193.149.1.26]
  9   185 ms   186 ms   185 ms  CIEMAT.AE1.cica.rt1.and.red.rediris.es [130.206.245.38]
 10   200 ms   200 ms   203 ms  CICA.AE1.uv.rt1.val.red.rediris.es [130.206.245.34]
 11   206 ms   206 ms   207 ms  anella-val1-router.red.rediris.es [130.206.211.70]
 12     *        *        *     Request timed out.
 13   204 ms   203 ms   202 ms  84.89.159.147
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *      205 ms   206 ms  grosso.upf.edu [84.89.134.145]

half an hour ago, a finished task got uploaded with "normal" speed; a few minutes later, the next one goes with about a tenth of the "normal" speed.
I made ping and tracert, results as follows:

Pinging gpugrid.net [84.89.134.145] with 32 bytes of data:

Reply from 84.89.134.145: bytes=32 time=77ms TTL=44
Reply from 84.89.134.145: bytes=32 time=77ms TTL=44
Reply from 84.89.134.145: bytes=32 time=77ms TTL=44
Reply from 84.89.134.145: bytes=32 time=76ms TTL=44

Ping statistics for 84.89.134.145:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 76ms, Maximum = 77ms, Average = 76ms


C:\Documents and Settings\Administrator>tracert gpugrid.net

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

1 1 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 7 ms 7 ms 7 ms 84.116.26.237
4 30 ms 30 ms 32 ms at-vie15a-rd1-ae24-2098.aorta.net [84.116.229.12
9]
5 32 ms 31 ms 31 ms at-vie05d-rc1-ae39-0.aorta.net [84.116.145.142]

6 * * * Request timed out.
7 29 ms 30 ms 28 ms uk-lon01b-ri1-ae23-0.aorta.net [84.116.135.30]
8 30 ms 30 ms 30 ms 195.66.225.24
9 30 ms 30 ms 29 ms ndn-gw.mx1.lon.uk.geant.net [109.105.102.98]
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 51 ms 50 ms 50 ms ae1.mx1.mar.fr.geant.net [62.40.98.72]
14 64 ms 64 ms 63 ms rediris-ias-rediris-gw.mar.fr.geant.net [83.97.8
8.130]
15 70 ms 70 ms 70 ms TELMAD.AE4.uv.rt1.val.red.rediris.es [130.206.24
5.89]
16 78 ms 76 ms 76 ms anella-val1-router.red.rediris.es [130.206.211.7
0]
17 * * * Request timed out.
18 76 ms 76 ms 77 ms 84.89.159.147
19 * * * Request timed out.
20 * * * Request timed out.
21 77 ms 76 ms 88 ms grosso.upf.edu [84.89.134.145]
Trace complete.

As can be seen, quite a lot of timeouts :-(

Merry Christmas to everybody!

"Request Timed Out" is not necessarily a problem or fault as there is a lot of hardware on the internet which doesn't respond to pings.

Again, big upload problems all day long. Now the uploads even come to a halt and change to "retry" status.

At the same time, as already done before, I opened SpeedtestNet and chose servers in Barcelona. No problems at all.
So, my guess is that the failure is with GPUGRID.

The couple times I have caught an upload recently it had been much improved. Sometimes over 1gig. It still had the jump up in upload speed, a gradual fall off and jump back up but from 150m to 1g is a nice jump.

again, upload is extremely slow (this has also been the case several time within the past days) - about 20 KB/s (normally, it's between 250 and 350 KB/s).

today, once more major problems with the upload server. Uploads take forever.

I am wondering how come that no one at GPUGRID is able to get this repaired. A really annoying situation :-(

I am unable to reach the GPUGrid website (forums, etc.) several times a day. It is annoying when you are trying to change settings, or post a comment. But since the uploads retry often enough, it is not really a problem for that.

I am surprised there are not more comments about it however.

But since the uploads retry often enough, it is not really a problem for that.

except that when the crunching time before was - say - 23 hours (which is often the case with my two GTX750ti's), and the upload takes, as happened today, 1 1/2 hours. Thus you loose 20% of the credit points.

I am surprised there are not more comments about it however.

so am I

except that when the crunching time before was - say - 23 hours (which is often the case with my two GTX750ti's), and the upload takes, as happened today, 1 1/2 hours. Thus you loose 20% of the credit points.

You have reminded me that I have a GTX 750 Ti sitting on the shelf, and I just converted a machine to Ubuntu 16.04, where I think it would get in under the 24 hour limit with the new Linux app. It is still about the most efficient card out there, and should get me through the summer, since I have had to shut down my GTX 970 and 980. It should work.

You should try Ubuntu. It is awful to learn, but once you get it then it is actually faster to install than Windows now.

You have reminded me that I have a GTX 750 Ti sitting on the shelf, and I just converted a machine to Ubuntu 16.04, where I think it would get in under the 24 hour limit with the new Linux app.

My first Pablo_IDP came it at 10 hours, and Adria_FOLDT0986 came in at 10 1/2 hours, so it works.
http://www.gpugrid.net/results.php?hostid=433866

For a card with a TDP of 60 watts, that will do.

EDIT: The Adria was about what I would expect, based on my GTX 970 and 980, but the Pablo was unusually fast. I would expect about 20 to 22 hours. We will see.

[quote]My first Pablo_IDP came it at 10 hours, and Adria_FOLDT0986 came in at 10 1/2 hours, so it works.

:-) :-) :-)

I knew you would like it.

It is the standard non-overclocked ASUS card. I don't do anything to boost it, but according to Nvidia X Server, the Graphics Clock is running at 1346 MHz.