gc.com website slow

January 22, 2015

Hi,

i think the Problem is not the Packetloss. I have here 2 different Providers which choose different ways to gc.com.

And in the moment I have no performance issues with the site, but I see loss on the 2 ways.

2. ae0-401.nbg40.core-backbone.com                                               0.0% 14558    0.3   0.3   0.3  21.9   0.7
3. ae3-2003.fra10.core-backbone.com                                              0.0% 14558    4.3   3.4   3.4  25.5   0.6
4. bundle-ether6.r03.frnkge03.de.bb.gin.ntt.net                                  0.0% 14557    4.5   3.9   3.8  14.0   0.5
5. ae-1.r21.frnkge03.de.bb.gin.ntt.net                                           0.0% 14557    3.9   3.7   3.6  94.7   6.7
6. ae-3.r23.nycmny01.us.bb.gin.ntt.net                                           0.0% 14557   94.0  89.3  89.2 198.9   7.7
7. ae-0.r22.nycmny01.us.bb.gin.ntt.net                                           0.0% 14557   89.4  89.3  89.1 163.5   9.2
8. ae-1.r21.sttlwa01.us.bb.gin.ntt.net                                          56.0% 14557  151.9 151.9 151.8 251.7   7.1
9. ae-2.r04.sttlwa01.us.bb.gin.ntt.net                                           0.0% 14557  152.4 152.0 151.9 197.2   0.6
10. ae-0.internap.sttlwa01.us.bb.gin.ntt.net                                      0.0% 14557  154.2 152.2 152.1 167.2   0.5
11. border8.po1-40g-bbnet1.sef.pnap.net                                           0.0% 14557  152.0 154.7 151.8 417.0  28.5
12. 63.251.163.200                                                                0.1% 14557  151.8 151.7 151.7 168.9   0.7


2. 213.95.247.10                                                   0.0% 14617    0.7   0.6   0.4  51.4   2.7
3. po2-603-rt3-nbg3.core.noris.net                                 0.0% 14617    1.1   0.8   0.7  98.4   4.7
4. vl604-rt1-ffm2.core.noris.net                                   0.0% 14617    3.9   3.8   3.6 118.3   5.9
5. s2-3-47.hsa1.lon1.bbnplanet.net                                 0.0% 14617    3.8   3.7   3.6  84.2   5.6
6. ae-4-90.edge5.Frankfurt1.Level3.net                            89.7% 14617    4.8   5.0   3.7 104.4   7.3
7. be3020.rcr21.fra06.atlas.cogentco.com                           0.1% 14617    4.9   4.6   4.2 617.7  22.2
8. be2305.ccr42.fra03.atlas.cogentco.com                           0.0% 14617    5.0   4.4   4.3  27.0   0.6
9. be2262.ccr42.ams03.atlas.cogentco.com                           0.0% 14617   12.1  11.2  11.1 164.2   2.4
10. be2183.ccr22.lpl01.atlas.cogentco.com                           0.0% 14617   21.1  20.8  20.7  36.0   0.5
11. be2385.ccr22.ymq02.atlas.cogentco.com                           0.0% 14617   97.3  96.9  96.8 108.7   0.6
12. be2093.ccr22.yyz02.atlas.cogentco.com                           0.0% 14617   97.2  97.1  97.0 112.8   0.5
13. be2080.ccr42.ord01.atlas.cogentco.com                           0.0% 14617  110.7 109.7 109.2 801.6  15.4
14. be2157.ccr22.mci01.atlas.cogentco.com                           0.1% 14617  131.2 130.1 129.9 831.7  12.8
15. be2130.ccr22.den01.atlas.cogentco.com                           0.0% 14617  142.0 141.6 141.5 600.1   3.8
16. be2127.ccr21.slc01.atlas.cogentco.com                           0.0% 14617  166.6 163.3 160.3 354.9   3.3
17. be2085.ccr21.sea02.atlas.cogentco.com                           0.1% 14617  163.3 162.9 162.8 542.1   4.5
18. be2084.ccr22.sea01.atlas.cogentco.com                           0.1% 14617  163.5 162.8 162.5 309.4   1.4
19. te4-2.ccr01.sea03.atlas.cogentco.com                            0.0% 14617  163.0 188.6 162.8 698.2  59.6
20. 38.122.90.42                                                    0.1% 14617  163.7 162.0 159.8 174.4   2.4
21. border9.po1-40g-bbnet1.sef.pnap.net                             0.1% 14617  163.6 164.3 159.1 467.5  25.9
22. 63.251.163.200                                                  0.0% 14616  162.8 160.5 159.0 169.4   2.5

January 22, 2015

from company network

1 1 ms 4 ms 7 ms

2 9 ms <1 ms <1 ms

3 * * * Zeitüberschreitung der Anforderung.

4 1 ms 11 ms <1 ms

5 2 ms 2 ms 13 ms

6 3 ms 3 ms 3 ms xe-1-2-0.mpr1.fra4.de.above.net [80.81.194.26]

7 7 ms 3 ms 3 ms ae8.mpr1.fra3.de.zip.zayo.com [64.125.26.233]

8 9 ms 10 ms 11 ms ae4.cr1.ams5.nl.zip.zayo.com [64.125.32.106]

9 86 ms 84 ms 84 ms xe-10-1-1.cr2.lga5.us.zip.zayo.com [64.125.20.169]

10 84 ms 84 ms 84 ms ae1.cr1.lga5.us.zip.zayo.com [64.125.29.37]

11 103 ms 113 ms 104 ms ae6.cr1.ord2.us.zip.zayo.com [64.125.24.34]

12 152 ms 152 ms 151 ms ae16.mpr1.sea1.us.zip.zayo.com [64.125.21.138]

13 160 ms 162 ms 160 ms 208.185.125.106.IPYX-072053-008-ZYO.above.net [208.185.125.106]

14 150 ms 150 ms 152 ms border9.po1-40g-bbnet1.sef.pnap.net [63.251.160.19]

15 160 ms 161 ms 159 ms 63.251.163.200

via DSL (Dt. Telekom)

1 3 ms 1 ms 1 ms fritz.box [192.168.178.1]

2 20 ms 20 ms 20 ms 217.0.119.23

3 22 ms 21 ms 21 ms 87.186.254.54

4 25 ms 24 ms 25 ms f-ed4-i.F.DE.NET.DTAG.DE [62.154.15.10]

5 25 ms 24 ms 25 ms 80.156.161.46

6 33 ms 25 ms 25 ms ae-6.r20.frnkge04.de.bb.gin.ntt.net [129.250.6.248]

7 108 ms 117 ms 119 ms ae-3.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.180]

8 104 ms 104 ms 117 ms ae-0.r23.asbnva02.us.bb.gin.ntt.net [129.250.3.85]

9 192 ms 187 ms 195 ms ae-1.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.13]

10 188 ms 188 ms 187 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45]

11 173 ms 173 ms 173 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]

12 250 ms 174 ms 175 ms border9.po1-40g-bbnet1.sef.pnap.net [63.251.160.19]

13 174 ms 173 ms 182 ms 63.251.163.200

January 22, 2015

Hi!

Our network support guy suggested using a ping with bigger packets. In the range of ~ 1400 Bytes as this is close to the packet size of standard DSL routers. He said this probably shows better if there's a big amount of packet losses and speed issues then.

And what we've found out so far in Germany is that mainly Deutsche Telekom seems to be affected. The biggest number of problems happens at their customers DSL lines. Additionally it most of the time happens at times of bigger traffic like weekend evening. Lots of people using the Internet then and speed drops dramatically.

I do use Vodafone and I don't have issues at all!

So lets hope the providers will finally figure out what causes these issues and solve it then!

Bye,

Christian

January 22, 2015

I noticed that the traceroute via command line reports acceptable results:

2 11 ms 13 ms 13 ms 87.*.*.*

3 7 ms 8 ms 7 ms 87.190.190.74

4 12 ms 18 ms 12 ms f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.122]

5 30 ms 30 ms 35 ms 80.157.128.230

6 * 32 ms 39 ms ae-1.r21.frnkge03.de.bb.gin.ntt.net [129.250.6.216]

7 113 ms 120 ms 107 ms ae-7.r22.asbnva02.us.bb.gin.ntt.net [129.250.3.20]

8 100 ms 101 ms 97 ms ae-0.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.72]

9 * 220 ms 226 ms ae-5.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.182]

10 224 ms 226 ms 225 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45]

11 161 ms 166 ms 163 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]

12 161 ms 158 ms 161 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83]

13 164 ms 170 ms 162 ms 63.251.163.200

At the same time, network traffic analyzer of the developer tools in Google Chrome shows the result when in front of the website:

It seems there are some scripts that take very long to load - I got stuck with the brown background and it did not get any further. This is exactly the same behaviour in Firefox.

After that I switched on a proxy in Switzerland using Zenmate in Chrome, and the page loaded without any problems:

1.4k · January 22, 2015

Currently, the site is almost unusable for me (as usual at that time of day, around 2100 CET).

For those that mentioned accessing and tracing seattle.gov when Geocaching was slow to respond, might I suggest tracing origin.rhapsody.com and navigating through their music catalog. Rhapsody is hosted in our space and should have a route much closer to our own.

The trace to rhapsody.com is very similar to that for geocaching.com:

>tracert www.geocaching.com

Routenverfolgung zu www.geocaching.com [63.251.163.200] über maximal 30 Abschnitte:

 1     2 ms     1 ms     1 ms  speedport.ip [192.168.2.1]
 2    18 ms    17 ms    18 ms  87.186.224.121
 3    28 ms    18 ms    18 ms  87.190.177.102
 4    31 ms    31 ms    24 ms  f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.222]
 5    25 ms    25 ms    24 ms  80.157.128.230
 6    28 ms    26 ms    24 ms  ae-6.r20.frnkge04.de.bb.gin.ntt.net [129.250.6.248]
 7   117 ms   119 ms   116 ms  ae-3.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.180]
 8   110 ms   112 ms   121 ms  ae-0.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.72]
 9   259 ms     *      253 ms  ae-1.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.13]
10   251 ms   254 ms   253 ms  ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45]
11   195 ms   190 ms   202 ms  ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]
12   277 ms   199 ms   302 ms  border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83]
13   192 ms   195 ms   191 ms  63.251.163.200

Ablaufverfolgung beendet.

>tracert origin.rhapsody.com

Routenverfolgung zu origin.rhapsody.com [66.150.171.162] über maximal 30 Abschnitte:

 1     2 ms     1 ms     2 ms  speedport.ip [192.168.2.1]
 2    21 ms    18 ms    18 ms  87.186.224.121
 3    18 ms    21 ms   181 ms  87.190.177.110
 4    27 ms    24 ms    23 ms  f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.130]
 5    24 ms    25 ms    24 ms  80.157.128.230
 6    29 ms    25 ms    23 ms  ae-1.r21.frnkge03.de.bb.gin.ntt.net [129.250.6.216]
 7   120 ms   117 ms   117 ms  ae-3.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.180]
 8   116 ms   121 ms   119 ms  ae-0.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.72]
 9   226 ms   229 ms   228 ms  ae-5.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.182]
10   237 ms   232 ms   253 ms  ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45]
11   199 ms   200 ms   199 ms  ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]
12   203 ms   217 ms   203 ms  border1.t8-1-bbnet2.sef003.pnap.net [63.251.160.85]
13   200 ms   196 ms   196 ms  206.191.144.222
14   198 ms   195 ms   197 ms  origin.rhapsody.com [66.150.171.162]

Ablaufverfolgung beendet.

While geocaching.com is in "slow mode", the Rhapsody site didn't respond at all! On the other hand, www.seattle.gov works fine. Trace to seattle.gov:

>tracert www.seattle.gov

Routenverfolgung zu seattle.gov [156.74.251.21] über maximal 30 Abschnitte:

 1     1 ms    <1 ms    <1 ms  speedport.ip [192.168.2.1]
 2    17 ms    17 ms    18 ms  87.186.224.121
 3    27 ms    20 ms    19 ms  87.190.177.102
 4    24 ms    24 ms    28 ms  f-ed8-i.F.DE.NET.DTAG.DE [217.5.95.94]
 5   111 ms    24 ms    24 ms  te0-7-0-10.agr21.fra03.atlas.cogentco.com [130.117.14.105]
 6    25 ms    25 ms    24 ms  be2184.ccr41.fra03.atlas.cogentco.com [130.117.48.70]
 7    33 ms    30 ms    31 ms  be2261.ccr41.ams03.atlas.cogentco.com [154.54.37.29]
 8    42 ms    42 ms    46 ms  be2182.ccr21.lpl01.atlas.cogentco.com [154.54.77.246]
 9   156 ms   157 ms   157 ms  be2384.ccr21.ymq02.atlas.cogentco.com [154.54.44.137]
10   166 ms   168 ms   167 ms  be2090.ccr21.yyz02.atlas.cogentco.com [154.54.30.205]
11   171 ms   168 ms     *     be2079.ccr41.ord01.atlas.cogentco.com [154.54.27.181]
12   187 ms   188 ms   195 ms  be2156.ccr21.mci01.atlas.cogentco.com [154.54.6.85]
13   227 ms   226 ms   228 ms  be2128.ccr21.den01.atlas.cogentco.com [154.54.25.173]
14   230 ms   227 ms   220 ms  be2126.ccr21.slc01.atlas.cogentco.com [154.54.25.66]
15     *      244 ms   243 ms  be2085.ccr21.sea02.atlas.cogentco.com [154.54.2.197]
16   244 ms   241 ms   235 ms  be2084.ccr22.sea01.atlas.cogentco.com [154.54.0.253]
17   239 ms   236 ms   235 ms  154.54.89.38
18   234 ms   232 ms   239 ms  154.24.20.30
19   240 ms   232 ms   234 ms  38.104.124.170
20     *        *        *     Zeitüberschreitung der Anforderung.
21   241 ms   242 ms   239 ms  www.seattle.gov [156.74.251.21]

Ablaufverfolgung beendet.

I also experimented with the HTML source. As I said, the HTML itself loads more or less quickly. I looked into the source header, and found (e.g.) this:

<!DOCTYPE html>
<html lang="en" class="no-js">
<head id="ctl00_Head1"><meta charset="utf-8" /><meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" /><title>
GC5KCBH Am Weiher (Traditional Cache) in Bayern, Germany created by Feuer-Gott
</title><meta name="DC.title" content="Geocaching - The Official Global GPS Cache Hunt Site" /><meta id="ctl00_ogUrl" property="og:url" content="http://www.geocaching.com/seek/cache_details.aspx?wp=GC5KCBH&title=am-weiher" /><meta name="twitter:card" content="summary_large_image" /><meta name="twitter:title" content="Geocaching: the anytime, anywhere outdoor adventure game." /><meta name="twitter:description" content="There are millions of geocaches worldwide and probably even some near you right now. Visit Geocaching.com to see just how many geocaches are nearby and to get the free Official Geocaching app." /><meta name="twitter:image:src" content="https://www.geocaching.com/play/Content/images/preview-lg.jpg" /><meta name="author" content="Geocaching" /><meta name="DC.creator" content="Geocaching" /><meta name="Copyright" content="Copyright (c) 2000-2015 Groundspeak, Inc. All Rights Reserved." /><!-- Copyright (c) 2000-2015 Groundspeak, Inc. All Rights Reserved. --><meta name="description" content="Geocaching is a treasure hunting game where you use a GPS to hide and seek containers with other participants in the activity. Geocaching.com is the listing service for geocaches around the world." /><meta name="DC.subject" content="Geocaching is a treasure hunting game where you use a GPS to hide and seek containers with other participants in the activity. Geocaching.com is the listing service for geocaches around the world." /><meta http-equiv="imagetoolbar" content="no" /><meta name="distribution" content="global" /><meta name="MSSmartTagsPreventParsing" content="true" /><meta name="rating" content="general" /><meta name="revisit-after" content="1 days" /><meta name="robots" content="all" /><meta name="p:domain_verify" content="107f8f596a30ff1ea307df82db696a5e" /><link rel="icon" href="/favicon.ico" /><link rel="shortcut icon" href="/favicon.ico" /><link rel="apple-touch-icon" href="/apple-touch-icon.png" /><link href="/content/coreCSS?v=VM3hS18FFScl2AdFkAaH7UKx0WVbBQlbmc7WXKjRX-g1" rel="stylesheet"/>
<link href="/css/jqueryui1104/jqUI?v=o-CPX73h6gKxCTGUlhe8oKrpdDBkkuBMgkCBfCBI5_A1" rel="stylesheet"/>
<link rel="stylesheet" type="text/css" media="print" href="../css/tlnMasterPrint.css" /><script src="/bundle/modernizer?v=wa97G2fdGaWBnIjKyioUssAWxy8tnYxkV0d-_5ClId01"></script>
<script src="/bundle/coreJS?v=uKjd3XRiFC1C29gkUc0JuDRCF6PuUu7R8PpzGjgXDEc1"></script>

I then tried to load the referenced style sheet and script files one by one "manually". The first four links ...

<link href="/content/coreCSS?v=VM3hS18FFScl2AdFkAaH7UKx0WVbBQlbmc7WXKjRX-g1" rel="stylesheet"/>
<link href="/css/jqueryui1104/jqUI?v=o-CPX73h6gKxCTGUlhe8oKrpdDBkkuBMgkCBfCBI5_A1" rel="stylesheet"/>
<link rel="stylesheet" type="text/css" media="print" href="../css/tlnMasterPrint.css" />
<script src="/bundle/modernizer?v=wa97G2fdGaWBnIjKyioUssAWxy8tnYxkV0d-_5ClId01"></script>

... were rather slow, but loading finished after a while (less than a minute). But the last one ...

<script src="/bundle/coreJS?v=uKjd3XRiFC1C29gkUc0JuDRCF6PuUu7R8PpzGjgXDEc1"></script>

... took an eternity and seems to be the reason, why the page loading time is excessively long.

Regards

Andreas

January 22, 2015

I can confirm _SoP_'s observations. With ZenMate pages on gc.com are loading within seconds, while it hangs completely when using the normal route via T-Online. Even wehen choosing the german server from ZenMate as exit point gc.com is responsive.

Regrettably, I can't do a traceroute over ZenMate to see the difference

January 22, 2015

Working from home (22:00 UTC+1), I usually use Deutsche Telekom. As other users have said, it is awfully slow when accessing Geocaching.com. If I use a VPN and go through my University, everything is good. Here are the reports from MTR (a traceroute variant).

Using the University network:

> sudo /usr/local/sbin/mtr --report -w --report-cycles=20 --psize=1400 geocaching.com
Start: Thu Jan 22 21:56:34 2015
HOST: remote239-011.home.uni-freiburg.de            Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- 193.197.62.222                                95.0%    20   54.9  54.9  54.9  54.9   0.0
 2.|-- 132.230.121.18                                 0.0%    20  105.0  81.9  49.7 333.4  70.7
 3.|-- freiburg1.belwue.de                            0.0%    20   40.9  41.4  40.2  45.5   1.4
 4.|-- karlsruhe-rz-1-10ge-0-3-0-0.belwue.net         0.0%    20   42.1  43.4  42.0  52.7   3.1
 5.|-- frankfurt-decix-1-10ge-0-0-0-1.belwue.net      0.0%    20   44.4  44.9  44.0  49.5   1.4
 6.|-- xe-1-2-0.mpr1.fra4.de.above.net                0.0%    20   44.2  45.2  44.1  49.4   1.7
 7.|-- ae8.mpr1.fra3.de.zip.zayo.com                  0.0%    20   59.3  60.1  53.9  80.5   8.8
 8.|-- ae4.cr1.ams5.nl.zip.zayo.com                   0.0%    20   60.2  60.7  59.7  64.9   1.1
 9.|-- xe-10-1-1.cr2.lga5.us.zip.zayo.com             0.0%    20  140.6 145.0 130.8 173.9   9.0
10.|-- ae6.cr2.ord2.us.zip.zayo.com                   0.0%    20  160.3 163.3 155.1 191.0   7.5
11.|-- ae11.cr1.ord2.us.zip.zayo.com                  0.0%    20  163.4 169.4 154.2 193.4   9.2
12.|-- ae16.mpr1.sea1.us.zip.zayo.com                 0.0%    20  189.2 191.1 180.9 205.0   4.8
13.|-- 208.185.125.106.ipyx-072053-008-zyo.above.net  0.0%    20  198.6 200.5 194.6 214.8   3.8
14.|-- border9.po1-40g-bbnet1.sef.pnap.net            5.0%    20  197.1 198.0 196.6 203.1   2.0
15.|-- 63.251.163.200                                 5.0%    20  207.1 208.1 206.8 215.3   2.1

Same with Deutsche Telekom:

> sudo /usr/local/sbin/mtr --report -w --report-cycles=20 --psize=1400 geocaching.com
Start: Thu Jan 22 21:58:52 2015
HOST: BernhardsMac-3.local                     Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- speedport.ip                              0.0%    20   12.6  15.1  12.0  27.6   4.2
 2.|-- 217.0.119.57                              0.0%    20   29.2  31.3  29.2  41.2   3.6
 3.|-- 217.0.68.246                              0.0%    20   29.9  32.0  29.8  46.8   4.0
 4.|-- f-ed4-i.f.de.net.dtag.de                  0.0%    20   34.5  39.2  34.2  68.9   9.6
 5.|-- 80.157.128.230                            0.0%    20   38.9  48.1  36.7  59.0   6.3
 6.|-- ae-1.r21.frnkge03.de.bb.gin.ntt.net       0.0%    20   39.6  47.1  35.2  55.6   7.1
 7.|-- ae-3.r23.nycmny01.us.bb.gin.ntt.net       0.0%    20  171.1 161.4 128.3 204.7  25.8
 8.|-- ae-0.r23.asbnva02.us.bb.gin.ntt.net       0.0%    20  129.3 137.2 119.5 150.3   9.1
 9.|-- ae-5.r21.sttlwa01.us.bb.gin.ntt.net      55.0%    20  242.8 253.4 242.8 263.1   7.2
10.|-- ae-2.r04.sttlwa01.us.bb.gin.ntt.net       5.0%    20  269.6 254.6 242.0 271.6   8.6
11.|-- ae-0.internap.sttlwa01.us.bb.gin.ntt.net  0.0%    20  203.5 201.7 188.6 217.1   6.6
12.|-- border9.po1-40g-bbnet1.sef.pnap.net       5.0%    20  187.8 219.6 187.8 388.8  54.6
13.|-- 63.251.163.200                            5.0%    20  202.4 207.4 195.9 216.5   6.2

So there is a significant packet loss at one of the nodes, which is also very consistent with other trials.

Cheers,

Bernhard

6.8k · January 22, 2015

If I use a VPN and go through my University, everything is good.

Also on Sunday evenings? I do not experience problems ion working days and also not on every Sunday evening, but on some Sunday evenings (like last Sunday) the site is very slow also for me regardless of the network I use.

7.8k · January 22, 2015

If I use a VPN and go through my University, everything is good.

Also on Sunday evenings? I do not experience problems ion working days and also not on every Sunday evening, but on some Sunday evenings (like last Sunday) the site is very slow also for me regardless of the network I use.

AFAIK, "Slowdown Sunday" affects everyone regardless of their location. That's separate from the current daily slowdowns being experienced by central Europe.

6.8k · January 22, 2015

AFAIK, "Slowdown Sunday" affects everyone regardless of their location. That's separate from the current daily slowdowns being experienced by central Europe.

I do not refer to a normal slowdown, but a site that then becomes really unusable (many time outs or half loaded pages etc). I have experienced this last Sunday and decided to delay logging.

January 22, 2015

I have tried ZenMate today, and it works pretty fine!

'With' it took some seconds to load a cachepage.

'Without', it took up to 5 minutes to load the same page only seconds later!

Independent, which country i've choosed as 'mask'

This is a strong indication for that the problem is somewhere on the 'data-highway' between GS and the User, and NOT with GS...

Edited January 22, 2015 by massafranz

5.7k · January 23, 2015

Our network support guy suggested using a ping with bigger packets. In the range of ~ 1400 Bytes as this is close to the packet size of standard DSL routers.

No impact here in Colorado at all. Wouldn't really expect there to be any. 32 vs. 1450 bytes doesn't matter as much as the mechanics of actually routing it.

Pinging 63.251.163.200 with 1450 bytes of data:

Reply from 63.251.163.200: bytes=1450 time=42ms TTL=245
Reply from 63.251.163.200: bytes=1450 time=42ms TTL=245
Reply from 63.251.163.200: bytes=1450 time=42ms TTL=245
Reply from 63.251.163.200: bytes=1450 time=43ms TTL=245   

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


Pinging 63.251.163.200 with 32 bytes of data:   

Reply from 63.251.163.200: bytes=32 time=42ms TTL=245
Reply from 63.251.163.200: bytes=32 time=41ms TTL=245
Reply from 63.251.163.200: bytes=32 time=42ms TTL=245
Reply from 63.251.163.200: bytes=32 time=40ms TTL=245    

Ping statistics for 63.251.163.200 
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:[/size]
Minimum = 40ms, Maximum = 42ms, Average = 41ms

Tracert still rational here, too:

Tracing route to 63.251.163.200 over a maximum of 30 hops

 1	<1 ms    <1 ms	<1 ms  192.168.1.1
 2	10 ms    14 ms 	9 ms  50.155.210.1
 3  	8 ms 	9 ms	11 ms  te-5-4-ur02.longmont.co.denver.comcast.net [68.85.107.197]
 4	13 ms 	12 ms	13 ms  xe-14-0-0-0-ar01.aurora.co.denver.comcast.net [162.151.8.1]
 5	16 ms 	15 ms	16 ms  he-3-4-0-0-cr01.denver.co.ibone.comcast.net [68.86.90.149]
 6	13 ms  	*   	36 ms  xe-0-0-2-0-pe01.910fifteenth.co.ibone.comcast.net [68.86.84.26]
 7	12 ms    14 ms	14 ms  dvr-edge-13.inet.qwest.net [72.164.247.149]
 8 	*        *    	* 	Request timed out.
 9	41 ms    40 ms	42 ms  63-235-80-54.dia.static.qwest.net [63.235.80.54]
10	41 ms    42 ms	55 ms  border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83]
11	42 ms    40 ms	40 ms  63.251.163.200 	

Trace complete

Edited January 23, 2015 by ecanderson

January 23, 2015

Problems from the netherlands as well. Last sunday it took 20 minutes to load the main site. Navigating any further wasn't possible at all.

Yesterday it was again hopeless

both times it was between 20:00 and 23:00 CET

I did some tracing, but couldn't post the results because the forum was unreachable as well and forgot to save them

I'm a dutch UPC customer. Last sunday I heard of 3 other people who had the same problem and all were UPC customers. Others (all non-UPC) were unaffected

January 23, 2015

I have tried ZenMate today, and it works pretty fine!

'With' it took some seconds to load a cachepage.

'Without', it took up to 5 minutes to load the same page only seconds later!

Independent, which country i've choosed as 'mask'

This is a strong indication for that the problem is somewhere on the 'data-highway' between GS and the User, and NOT with GS...

ZenMate provides a VPN-Tunnel and for this, the routing is different. In this case it's not necessary to choose another country then Germany.

January 25, 2015

Here is the direct comparison between normal and slow:

NORMAL:

1 2 ms 1 ms 1 ms router [*.*.*.*]

2 6 ms 6 ms 6 ms 87.*.*.*

3 6 ms 6 ms 6 ms 87.*.*.*

4 13 ms 13 ms 13 ms f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.134]

5 34 ms 35 ms 34 ms 80.157.128.230

6 41 ms 34 ms 57 ms ae-6.r20.frnkge04.de.bb.gin.ntt.net [129.250.6.248]

7 101 ms 99 ms 104 ms ae-3.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.180]

8 98 ms 100 ms 112 ms ae-0.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.72]

9 216 ms 179 ms * ae-1.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.13]

10 185 ms 173 ms 174 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45]

11 165 ms 166 ms 164 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]

12 183 ms 164 ms 176 ms border8.po1-40g-bbnet1.sef.pnap.net [63.251.160.18]

13 339 ms 192 ms 182 ms 63.251.163.200

SLOW:

1 2 ms 4 ms 4 ms router [*.*.*.*]

2 6 ms 8 ms 6 ms 87.*.*.*

3 7 ms 6 ms 7 ms 87.*.*.*

4 60 ms 12 ms 12 ms f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.218]

5 33 ms 33 ms 33 ms 80.157.128.230

6 28 ms 50 ms 27 ms ae-1.r21.frnkge03.de.bb.gin.ntt.net [129.250.6.216]

7 111 ms 103 ms 100 ms ae-7.r22.asbnva02.us.bb.gin.ntt.net [129.250.3.20]

8 108 ms 123 ms 102 ms ae-0.r23.asbnva02.us.bb.gin.ntt.net [129.250.3.85]

9 237 ms 230 ms 235 ms ae-5.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.182]

10 177 ms 169 ms 169 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45]

11 163 ms 162 ms 176 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]

12 170 ms 168 ms 170 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83]

13 172 ms 164 ms 170 ms 63.251.163.200

The times are nothing to complain about. As said - it is not the network connectivity in general, but the loading of the scripts that make the website unable to use. See post by baer2006.

January 25, 2015

my traceroute from Provider 1&1

traceroute geocaching.com

traceroute to geocaching.com (63.251.163.200), 64 hops max, 52 byte packets

1 fritz.box (***) 1.826 ms 1.590 ms 1.372 ms

2 217.0.118.158 (217.0.118.158) 409.527 ms 312.274 ms 308.688 ms

3 87.190.166.186 (87.190.166.186) 284.207 ms 368.745 ms 390.255 ms

4 f-ed4-i.f.de.net.dtag.de (62.154.14.206) 370.712 ms 393.817 ms 400.825 ms

5 80.157.128.230 (80.157.128.230) 413.987 ms 409.354 ms 257.573 ms

6 ae-1.r21.frnkge03.de.bb.gin.ntt.net (129.250.6.216) 241.462 ms

ae-6.r20.frnkge04.de.bb.gin.ntt.net (129.250.6.248) 270.739 ms

ae-1.r21.frnkge03.de.bb.gin.ntt.net (129.250.6.216) 301.092 ms

7 ae-7.r22.asbnva02.us.bb.gin.ntt.net (129.250.3.20) 401.653 ms

ae-3.r23.nycmny01.us.bb.gin.ntt.net (129.250.3.180) 362.340 ms 431.688 ms

8 ae-0.r23.asbnva02.us.bb.gin.ntt.net (129.250.3.85) 401.826 ms

ae-0.r22.nycmny01.us.bb.gin.ntt.net (129.250.3.72) 362.257 ms

ae-0.r23.asbnva02.us.bb.gin.ntt.net (129.250.3.85) 388.553 ms

9 ae-5.r21.sttlwa01.us.bb.gin.ntt.net (129.250.4.182) 457.002 ms 432.447 ms 459.148 ms

10 ae-2.r04.sttlwa01.us.bb.gin.ntt.net (129.250.5.45) 439.487 ms 476.633 ms 388.397 ms

11 ae-0.internap.sttlwa01.us.bb.gin.ntt.net (129.250.201.18) 316.964 ms 446.255 ms *

12 border9.po2-40g-bbnet2.sef.pnap.net (63.251.160.83) 287.463 ms

border8.po1-40g-bbnet1.sef.pnap.net (63.251.160.18) 217.535 ms

border9.po1-40g-bbnet1.sef.pnap.net (63.251.160.19) 260.311 ms

13 63.251.163.200 (63.251.163.200) 264.227 ms 264.844 ms 314.729 ms

January 25, 2015

Like for many others, ZenMate has saved my caching-weekend, and now I got a 403.6 error saying, that access via anonymous proxy is not allowed and that the IP is blocked.

You are joking, aren't you? :huh:

January 25, 2015

I could only replay with Zenmate. Because GC is slooooooooow. I am from Germany and I am using t-online.

Routenverfolgung zu geocaching.com [63.251.163.200] ber maximal 30 Abschnitte:

 1    <1 ms    <1 ms    <1 ms  fritz.box [#############] 
 2    24 ms    24 ms    24 ms  217.0.119.83 
 3    27 ms    26 ms    26 ms  217.0.72.250 
 4    34 ms    33 ms    34 ms  f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.130] 
 5    34 ms    34 ms    34 ms  80.156.161.46 
 6    34 ms    34 ms    34 ms  ae-6.r20.frnkge04.de.bb.gin.ntt.net [129.250.6.248] 
 7   133 ms   153 ms   128 ms  ae-3.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.180] 
 8   156 ms   150 ms   124 ms  ae-0.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.72] 
 9   234 ms   225 ms   230 ms  ae-5.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.182] 
10   224 ms   229 ms   232 ms  ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45] 
11   188 ms   186 ms   186 ms  ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18] 
12   185 ms   182 ms   185 ms  border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83] 
13   185 ms   185 ms   182 ms  63.251.163.200 

Ablaufverfolgung beendet.

Routenverfolgung zu geocaching.com [63.251.163.200] ber maximal 30 Abschnitte:

 1    <1 ms    <1 ms    <1 ms  fritz.box [.............] 
 2    24 ms    24 ms    24 ms  217.0.119.83 
 3    28 ms    25 ms    26 ms  217.0.72.250 
 4    34 ms    33 ms    33 ms  f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.130] 
 5    60 ms    61 ms    61 ms  80.156.161.46 
 6    59 ms    59 ms    58 ms  ae-1.r21.frnkge03.de.bb.gin.ntt.net [129.250.6.216] 
 7   132 ms   131 ms   152 ms  ae-7.r22.asbnva02.us.bb.gin.ntt.net [129.250.3.20] 
 8   125 ms   147 ms   149 ms  ae-0.r23.asbnva02.us.bb.gin.ntt.net [129.250.3.85] 
 9   220 ms   222 ms     *     ae-5.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.182] 
10   228 ms   224 ms   222 ms  ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45] 
11   182 ms   184 ms   182 ms  ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18] 
12   187 ms   185 ms   185 ms  border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83] 
13   181 ms   185 ms   181 ms  63.251.163.200 

Ablaufverfolgung beendet.

Edited January 25, 2015 by Jurgen & co

January 26, 2015

Working from home (22:00 UTC+1), I usually use Deutsche Telekom. As other users have said, it is awfully slow when accessing Geocaching.com. If I use a VPN and go through my University, everything is good. Here are the reports from MTR (a traceroute variant).

I noticed exactly the same yesterday evening (around 22:00 CET): Website and forum very slow or not responding at all when using my regular DSL provider T-Online (Deutsche Telekom). However, once I switched to the VPN tunnel provided by my employer (a German university) everything went smoothly.

1.1k · January 28, 2015

Do someone from Groundspeak do something with that issue?

Third party plugins like ZenMate are for me more a precipitate than a solution.

Edited January 28, 2015 by GeoLog81

January 28, 2015

Have a look at this page:

https://support.Groundspeak.com/index.php?pg=kb.page&id=640

5.7k · January 29, 2015

Third party plugins like ZenMate are for me more a precipitate than a solution.

Was that supposed to be a pun from chemistry class? If so, it was a GOOD one!

January 31, 2015

Hello

I have at home Vodafone DSL and Firefox and at home no problems, but a frind have many Problems mit T-Online and Internet Explorer.

We have phoned via Telephone and when i can open the Side without problems, he see only the "brown" Side and must wait very long. So he has installed Firefox and testet new. Now it works normal by him, when he use Internet Explorer he must wait and wait.

Yesterday we have tested it with my computer by him, the same reulst. With Firefox and T-Online by him with both Computer no problem, with IE only brown screen by both computer.

Cache opening also direct from GSAK open IE and only brown Screen.

So I think we can say, it is not the problem of the Computer Hardware i think its the combination from T-Online and IE.

By Firefox opening with https i see by opening the Information "Diese Webseite stellt keine Identitätsdaten zur Verfügung" (English " This website does not provide identity information available ") but no waiting for opening.

Opening with http no warning.

I hope it will help for find the Problem.

Happy Hunting

GaswerkAugsburg

Oli

March 22, 2015

I am also located in Germany, connected to the Internet with 1&1 as provider running over Deutsche Telekom VDSL (physical link). Using www.geocaching.com often is extremly slow. I did not test yet, if this is in any way related to the fact that my connection to the Internet is using dual-stack (IPv4 and IPv6).

BUT I have strong evidence that the "slowness" is somewhat related to Deutsche Telekom. The reason: I am able to switch to a totally different provider by using a VPN connection to the DFN ("Deutsches Forschungsnetz"). As soon as I am accesing www.geocaching.com via DFN through the VPN tunnel the web site is fast and everything "works as expected". When tearing down the VPN connection, www.geocaching.com is very slow (often nearly unusable) again.

If someone of the IT department of Groundspeak is interrested, please contact me for traceroutes...

Mayby this helps to catch the problem...

Regards,

LaPalmaFan

5.7k · March 23, 2015

@LaPalma

I'd just go ahead and post the tracert data and hope somebody at gc.com pays attention. If nothing else, it may provide the rest of us with some peace of mind about why certain parts of the world are having so much difficulty compared to others. Things are still zippity fast here:

Tracing route to geocaching.com [63.251.163.200]

over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1

2 11 ms 10 ms 10 ms 50.155.210.1

3 9 ms 11 ms 12 ms xe-9-0-0-0-sur02.longmont.co.denver.comcast.net [68.85.107.197]

4 11 ms 11 ms 13 ms ae-32-0-ar01.aurora.co.denver.comcast.net [68.86.103.17]

5 14 ms 12 ms 13 ms he-0-5-0-0-cr02.denver.co.ibone.comcast.net [68.86.90.149]

6 27 ms 28 ms 27 ms be-11317-cr01.dallas.tx.ibone.comcast.net [68.86.84.229]

7 26 ms 26 ms 28 ms 68.86.86.154

8 31 ms 28 ms 26 ms ae-19.r07.dllstx09.us.bb.gin.ntt.net [129.250.66.29]

9 26 ms 26 ms 26 ms ae-2.r21.dllstx09.us.bb.gin.ntt.net [129.250.2.173]

10 52 ms 55 ms 59 ms ae-8.r23.snjsca04.us.bb.gin.ntt.net [129.250.4.154]

11 58 ms 60 ms 61 ms ae-3.r20.sttlwa01.us.bb.gin.ntt.net [129.250.3.125]

12 60 ms 62 ms 59 ms ae-1.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.43]

13 57 ms 59 ms 61 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]

14 60 ms 58 ms 60 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83]

15 59 ms 57 ms 57 ms 63.251.163.200

Trace complete.

Pinging 63.251.163.200 with 32 bytes of data:

Reply from 63.251.163.200: bytes=32 time=60ms TTL=242

Reply from 63.251.163.200: bytes=32 time=57ms TTL=242

Reply from 63.251.163.200: bytes=32 time=61ms TTL=242

Ping statistics for 63.251.163.200:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 57ms, Maximum = 61ms, Average = 59ms

March 23, 2015

Thanks for the response.

As a customer of theirs, would you be willing to open a ticket with Deutsche Telekom and see if they can help you work the issue on their end? I've had little success reaching out to ISPs that I am not a customer of.

Also, Rhapsody hosts their music catalog in our datacenter so it should traverse the same routing path. I haven't seen anyone respond to my request to browse their catalog and report if it experiences similar slowness. That site is http://origin.rhapsody.com/browse/

It's clear that ZenMap and other VPN solutions provide a workaround, but we would like mitigate that requirement.

I am also located in Germany, connected to the Internet with 1&1 as provider running over Deutsche Telekom VDSL (physical link). Using www.geocaching.com often is extremly slow. I did not test yet, if this is in any way related to the fact that my connection to the Internet is using dual-stack (IPv4 and IPv6).

BUT I have strong evidence that the "slowness" is somewhat related to Deutsche Telekom. The reason: I am able to switch to a totally different provider by using a VPN connection to the DFN ("Deutsches Forschungsnetz"). As soon as I am accesing www.geocaching.com via DFN through the VPN tunnel the web site is fast and everything "works as expected". When tearing down the VPN connection, www.geocaching.com is very slow (often nearly unusable) again.

If someone of the IT department of Groundspeak is interrested, please contact me for traceroutes...

Mayby this helps to catch the problem...

Regards,

LaPalmaFan

March 23, 2015

Hm, I don't think that is only Deutsche Telekom, my ISP is Telefoncia (O2) it is also so slow, and it is no fun exploring gc.com websites for new caching adventures.

Here is an actual traceroute, ecanderson's results are an unreachable dream here.

1 1 ms <1 ms <1 ms alice.box [192.168.1.1]

2 27 ms 28 ms 28 ms 62.xx.xxx.xxx

3 27 ms 27 ms 27 ms bundle-ether5.0002.dbrx.01.ham.de.net.telefonica.de [62.53.10.232]

4 27 ms 27 ms 27 ms et-1-1-0-0.0001.corx.02.ham.de.net.telefonica.de [62.53.0.52]

5 27 ms 27 ms 28 ms et-1-0-0-0.01.xd.0176-03.ham.de.net.telefonica.de [62.53.0.55]

6 28 ms 28 ms 26 ms ae0-0.0001.prrx.02.ham.de.net.telefonica.de [62.53.7.217]

7 35 ms 36 ms 35 ms ae0-0-grtdusix1.red.telefonica-wholesale.net [84.16.7.233]

8 45 ms 55 ms 55 ms 213.140.49.10

9 129 ms 164 ms 128 ms Xe-0-0-2-0-grtnycpt3.red.telefonica-wholesale.net [94.142.126.69]

10 182 ms 208 ms 201 ms Xe9-3-0-0-grtpaopx2.red.telefonica-wholesale.net [94.142.118.186]

11 202 ms 197 ms 198 ms 213.140.53.178

12 210 ms 211 ms 207 ms ae-15.r01.snjsca04.us.bb.gin.ntt.net [129.250.5.33]

13 185 ms 185 ms 183 ms ae-4.r23.snjsca04.us.bb.gin.ntt.net [129.250.4.25]

14 217 ms 214 ms 221 ms ae-3.r20.sttlwa01.us.bb.gin.ntt.net [129.250.3.125]

15 222 ms 217 ms 219 ms ae-1.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.43]

16 200 ms 200 ms 200 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]

17 214 ms 212 ms 213 ms border9.po1-40g-bbnet1.sef.pnap.net [63.251.160.19]

18 204 ms 207 ms 215 ms geocaching.com [63.251.163.200]

March 23, 2015

As a customer of theirs, would you be willing to open a ticket with Deutsche Telekom and see if they can help you work the issue on their end? I've had little success reaching out to ISPs that I am not a customer of

I've done that two weeks ago (Link in German!), but to be honest, I do not expect too much from it. It's not the first time people complain about their transatlantic routes and the answer is usually, that this is beyond the area of influence of Deutsche Telekom which is only a part of the truth. With their peering policy they have indeed big influence on the worldwide routing of their customer's traffic. But this is a complicated story...

So I've also tried to find a contact for complaints at ntt.net, where the packet loss usually occurs, but their website has been as slow as gc.com at that time.

Meanwhile I've somehow resignated and use Zenmate, respectivly the google proxy in chrome on the mobile, and hope for better days to come.

March 25, 2015

Unusably slow here in Germany *AGAIN* - been this way on and off for more than a month - tonight it's been up to 5 mins just for a page refresh (on a 50mbit link). Finally got the forum up so I could post.

Server is

Traceroute:

Tracing route to www.geocaching.com [63.251.163.200]

over a maximum of 30 hops:

1 2 ms 2 ms 2 ms FRITZ-NAS X.X.X.X

2 18 ms 11 ms 12 ms HSI-KBW-109-192-176-001.hsi6.kabel-badenwuerttemberg.de [X.X.X.X]

3 11 ms 15 ms 11 ms 172.30.22.65

4 29 ms 19 ms 13 ms 84.116.190.81

5 13 ms 14 ms 30 ms ae0.STR-M1.ip-bb.kabel-badenwuerttemberg.de [78.42.40.4]

6 14 ms 14 ms 14 ms ae1.KAE-M1.ip-bb.kabel-badenwuerttemberg.de [78.42.40.2]

7 35 ms 14 ms 20 ms 84.116.191.2

8 190 ms 191 ms 191 ms 84.116.132.193

9 217 ms 213 ms 209 ms nl-ams02a-rd1-tge-0-4-0-2.aorta.net [84.116.130.41]

10 138 ms 131 ms 130 ms 84-116-130-122.aorta.net [84.116.130.122]

11 202 ms 196 ms 193 ms 84.116.136.42

12 192 ms 196 ms 190 ms xe-0.equinix.snjsca04.us.bb.gin.ntt.net [206.223.116.12]

13 195 ms 193 ms 199 ms ae-6.r23.snjsca04.us.bb.gin.ntt.net [129.250.4.41]

14 228 ms 239 ms 249 ms ae-3.r20.sttlwa01.us.bb.gin.ntt.net [129.250.3.125]

15 253 ms 255 ms 240 ms ae-1.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.43]

16 205 ms 202 ms 244 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]

17 210 ms 203 ms 204 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83]

18 202 ms 207 ms 218 ms 63.251.163.200

Trace complete.

Been like this for too long :-(

Edited March 25, 2015 by FeyGriffin

March 25, 2015

7 35 ms 14 ms 20 ms 84.116.191.2

8 190 ms 191 ms 191 ms 84.116.132.193

Odd 84.116.132.193 is:

84.116.132.193 - Geo Information

IP Address 84.116.132.193

Host 84.116.132.193

Location AT AT, Austria

City -, - -

Organization UPC Broadband GmbH

ISP UPC Broadband GmbH

AS Number AS6830 Liberty Global Operations B.V.

Wouldn't have expected to be routed via AT

But that's where the ping time gets slow.

March 25, 2015

Wouldn't have expected to be routed via AT

But that's where the ping time gets slow.

And via zenmate it's all good

TraceRoute from Network-Tools.com to 63.251.163.200

Hop (ms) (ms) (ms) IP Address Host name

1 17 0 0 206.123.64.221 -

2 1 1 1 129.250.202.253 xe-0-4-0-12.r01.dllstx04.us.bb.gin.ntt.net

3 4 1 1 129.250.2.198 ae-1.r21.dllstx09.us.bb.gin.ntt.net

4 40 40 40 129.250.4.154 ae-8.r23.snjsca04.us.bb.gin.ntt.net

5 57 86 57 129.250.3.125 ae-3.r20.sttlwa01.us.bb.gin.ntt.net

6 57 57 57 129.250.5.43 ae-1.r04.sttlwa01.us.bb.gin.ntt.net

7 50 50 50 129.250.201.18 ae-0.internap.sttlwa01.us.bb.gin.ntt.net

8 50 50 50 63.251.160.82 border8.po2-40g-bbnet2.sef.pnap.net

9 50 49 49 63.251.163.200 -

Trace complete

So a routing issue from DE to US which seems to be stalling in AT :-(

1.4k · March 25, 2015

Also, Rhapsody hosts their music catalog in our datacenter so it should traverse the same routing path. I haven't seen anyone respond to my request to browse their catalog and report if it experiences similar slowness. That site is http://origin.rhapsody.com/browse/

Actually I did respond to that question in my posting on 22 January 2015. Admittedly amongst lots of other bits of information

. Anyway, to repeat what I said then: While geocaching.com was extremely slow, I coulnd't connect to Rhapsody at all. That confirmed, that the problem was not specific to Groundspeak.

1.1k · March 26, 2015

So primarily Telekom is guilty for having bad routing tables and unwilling to fix it.

But on the side of Groundspeak, it's unreasonable, by the whole mass of traffic they get, not to have a single mirror server in Europe.

It seems the whole money we pay goes to marketing, and not to server infrastructure, as it allegedly should be...

6.2k · March 26, 2015

But on the side of Groundspeak, it's unreasonable, by the whole mass of traffic they get, not to have a single mirror server in Europe.

I don't see any need for a mirror in Europe, it wouldn't make much difference in response times for those Europeans (me included) who are using a properly configured network, so from my point of view it would be money wasted for no benefit.

March 30, 2015

Since some days I can't use the website! The site is very slow or I can see often only a white page or the background.

Location/provider: Germany/Telekom (16MBit/s)

Routenverfolgung zu www.geocaching.com [63.251.163.200] über maximal 30 Abschnitte:

1 <1 ms <1 ms <1 ms 192.168.xyz.x

2 1 ms 1 ms 1 ms 192.168.xyz.x

3 9 ms 8 ms 8 ms 217.0.xyz.xyz

4 11 ms 9 ms 9 ms 217.0.66.18

5 29 ms 23 ms 23 ms 217.239.47.198

6 18 ms 18 ms 17 ms 62.159.61.206

7 22 ms 33 ms 28 ms ae-8.r23.londen03.uk.bb.gin.ntt.net [129.250.6.206]

8 22 ms 23 ms 28 ms ae-0.r22.londen03.uk.bb.gin.ntt.net [129.250.4.85]

9 122 ms 124 ms * ae-4.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.126]

10 182 ms 190 ms * ae-1.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.13]

11 204 ms 199 ms 200 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45]

12 169 ms 172 ms 169 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]

13 196 ms 206 ms 205 ms border9.po1-40g-bbnet1.sef.pnap.net [63.251.160.19]

14 171 ms 169 ms 171 ms 63.251.163.200

C:\Windows\system32>ping geocaching.com -t

Ping wird ausgeführt für geocaching.com [63.251.163.200] mit 32 Bytes Daten:

Antwort von 63.251.163.200: Bytes=32 Zeit=167ms TTL=246