Jump to content

gc.com website slow


holbi

Recommended Posts

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

Link to comment

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

Link to comment

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

Link to comment

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:

screenshot_706.jpg

 

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:

screenshot_707.jpg

Link to comment

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

Link to comment

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 :(

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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 by massafranz
Link to comment

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 by ecanderson
Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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 by Jurgen & co
Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment

@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

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

Link to comment

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

Link to comment

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]

Link to comment

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.

Link to comment

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

<!-- Server: WEB15; Build: Tucson.Main.release-20150316.Release_260 -->

 

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 by FeyGriffin
Link to comment

 

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.

Link to comment

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 :-(

Link to comment

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.
Link to comment

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...

Link to comment

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.

Link to comment

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Ping-Statistik für 63.251.163.200:

Pakete: Gesendet = 18, Empfangen = 18, Verloren = 0

(0% Verlust),

Ca. Zeitangaben in Millisek.:

Minimum = 167ms, Maximum = 179ms, Mittelwert = 170ms

 

----------

 

Location/provider: Germany/Unitymedia (150MBit/s)

 

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

 

1 3 ms <1 ms <1 ms 172.30.xyz.x

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

3 2 ms 1 ms 1 ms xxxxxxxxxxxxxxxx [xx.xx.xx.xx]

4 11 ms 15 ms 9 ms 10.144.0.1

5 17 ms 15 ms 14 ms de-fra04a-ra1-ae10-1210.fra.unity-media.net [81.210.128.65]

6 168 ms 165 ms 167 ms de-fra04a-rc1-ae8.fra.unity-media.net [81.210.129.225]

7 166 ms 169 ms 170 ms uk-lon01b-rd1-xe-1-2-2.aorta.net [84.116.132.17]

8 91 ms 99 ms 92 ms 84.116.140.30

9 164 ms 167 ms 163 ms 84.116.135.121

10 176 ms 167 ms 165 ms xe-0.equinix.snjsca04.us.bb.gin.ntt.net [206.223.116.12]

11 166 ms 171 ms 164 ms ae-6.r23.snjsca04.us.bb.gin.ntt.net [129.250.4.41]

12 185 ms 184 ms 194 ms ae-3.r20.sttlwa01.us.bb.gin.ntt.net [129.250.3.125]

13 183 ms 193 ms 183 ms ae-1.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.43]

14 184 ms 182 ms 182 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]

15 241 ms 209 ms 258 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83]

16 186 ms 186 ms 191 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=185ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=185ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=186ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=184ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=184ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=187ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=187ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=184ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=189ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=187ms TTL=237

Zeitüberschreitung der Anforderung.

Antwort von 63.251.163.200: Bytes=32 Zeit=186ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=185ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=189ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=185ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=192ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=188ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=188ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=188ms TTL=237

Antwort von 63.251.163.200: Bytes=32 Zeit=185ms TTL=237

 

Ping-Statistik für 63.251.163.200:

Pakete: Gesendet = 20, Empfangen = 19, Verloren = 1

(5% Verlust),

Ca. Zeitangaben in Millisek.:

Minimum = 184ms, Maximum = 192ms, Mittelwert = 186ms

 

Edit: I needed over a minute to save this post!!!

Edited by Geo Chief
Link to comment

Is that all? I understand, that you can't do anything at the routing between germandy and you.

We have these speed issues since 4 months and nothing happend. But okay, we become a Message Center, but this is also slow :(

Groundspeak say that we must use a vpn or so if we have no time to wait 5 minutes for a load of a listing.

I have every evening these speed issues and for this I pay. Premium Member is nice but when you cant use it, while the speed is to slow it is a little bit depressing.

What do you think about some mirror servers in the EU?

Link to comment

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.

 

Actually I guess the main reason of this speed issue is the peering politic of the Deutsche Telekom AG. For us Germans → http://www.heise.de/netze/artikel/Tier-1-bis-3-223802.html

 

Even the Seattle Carrier hasn't a peering agreement with DTAG, Groundspeak has possibilities to help.

I disagree that a mirror Server wouldn't help. I guess placing a mirror server in Ireland would be fine. Peering between DTAG and Carrier in Ireland shouldn't be an issue.

But even just placing a Web server somewhere in Europe which forward the request to Seattle application server / DB server would probably help.

The only question is if this is affordable and will provide any economical benefit :-)

 

Any comment from Groundspeak to this?

Link to comment

 

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.

 

Only the fact that you have absolutely no influence on 'property configured network'.

 

From the point of view of people who have no other choice the money given to Groundspeak would be money wasted for no benefit. Why pay for something you can't use?

 

If you use ZenMate, all your traffic goes through the third party. Many people have issues with that.

Link to comment

 

Actually I guess the main reason of this speed issue is the peering politic of the Deutsche Telekom AG. For us Germans → http://www.heise.de/netze/artikel/Tier-1-bis-3-223802.html

 

 

Have I understood that article correctly? Telekom AG are effectively bandits who require tribute from other sites, and if someone doesn't pay, his traffic gets cut off even to absurd point?

 

I've got recently issues with one online game from Poland, as with Groundspeak, ZenMate was the 'solution'.

 

If it's true, this is so ill! Is it not illegal activity? As for me, it breaks all possible client rights...

Link to comment

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.

 

Another fact is, that this problem only affects german users, routed by the Deutsche Telekom.

So, people from other countries or routed by providers not hooked on Deutsche Telekom are not able to relate to this problem.

As far as i know, at least...

Edited by massafranz
Link to comment

Hy,

 

I faced the same problem with a very slow gc.com site depending on the daytime I used it. And I can confirm that the Telekom routing theory seems to be right.

 

Here's my observation:

 

  • My DSL provider was German Telekom until 4th of may 2015. The geocaching.com site was often very slow, sometimes unusable. I am located nearby Nuremburg in the south of Germany.
  • When I set my Smartphone to Wireless HotSpot mode and used the mobile data connection, gc.com was much faster.
  • Since 2 days my new DSL provider is M-net and the problem is gone :D

 

Summary:

 

Performance problems with Telekom DSL, no performance problems with mobile data like LTE or M-Net DSL. Does not sound like a service problem on geoacaching.com side. Sounds like an internal Telekom routing and bottleneck issue.

 

hope that helps, regards, f r e d

Link to comment

This is becoming a parody! The Groundspeak site is completely unusable without zenmate, and with zenmate I can't open listing from outside (google etc.) because I get proxy error!

 

So the only working way to log caches is currently GSAK.

 

Is it going to be 'permanent bug not allowed to mention on forum' like that one with magically changing coordinates to W on Waymarking?

Link to comment

Is it going to be 'permanent bug not allowed to mention on forum' like that one with magically changing coordinates to W on Waymarking?

 

Hasn't it been pretty well confirmed that the problem here is in the routing of a European telecoms company? If so there's not much Groundspeak can do about it and you need to take it up with the telecoms company.

Link to comment

 

Hasn't it been pretty well confirmed that the problem here is in the routing of a European telecoms company? If so there's not much Groundspeak can do about it and you need to take it up with the telecoms company.

 

It is wrong that only one country and only one company is involved. Several countries and cachers relying on different providers/companies are affected.

Link to comment

Hasn't it been pretty well confirmed that the problem here is in the routing of a European telecoms company? If so there's not much Groundspeak can do about it and you need to take it up with the telecoms company.

It is wrong that only one country and only one company is involved. Several countries and cachers relying on different providers/companies are affected.

Regardless, the problem seems to be ISP routing, which isn't something Groundspeak can control or fix. Affected cachers need to harass their ISP.

Link to comment

Also, in regard to :

 

Is it going to be 'permanent bug not allowed to mention on forum' like that one with magically changing coordinates to W on Waymarking?

 

There are no bugs that are "not allowed to mention on forum." Your thread on longitude changing to W on Waymarking was simply closed as a duplicate of an existing thread with an explanation that developer resources have been moved off of that project.

Link to comment

Regardless, the problem seems to be ISP routing, which isn't something Groundspeak can control or fix. Affected cachers need to harass their ISP.

 

Yes, Groundspeak cannot fix it. The involved ISPs (many) will not fix it either. Everyone argues that they are not the cause of the problem. Groundspeak's site is not that important.

 

Moreover, however at some times Groundspeak's site is also very slow if one has the privilege of fast routings to gc.com.

Edited by cezanne
Link to comment

Regardless, the problem seems to be ISP routing, which isn't something Groundspeak can control or fix. Affected cachers need to harass their ISP.

 

Affected cachers that would harass their ISP would be ridiculed. This is Germany, where the client is not the king, but the servant, which should actually pay for consuming the precious time of the officer bored by his petty sorrows.

 

The Groundspeak harassing the ISPs on the side of the cachers would have some more chances to be heard. Well, the company having a lot of many is almost as much worth as someone from good noble family, maybe event they'd be granted audience.

 

The one thing Groundspeak can fix, and ought to do that ASAP is that idiotic message about 'anonymous proxy' that affects users using ZenMate, the only actual solution to the 'evil ISP bug'.

Link to comment

Just letting you know, that this problem is concerning Czech republic as well. It's not perfect at the midday, but at the evening it's much worse.

 

This is how long does it takes to load geocaching.com homepage (no cache, around 14.30 Central Europe Time) - 46 seconds. Image is grab from the firebug extension of firefox, basically bar colors are follows:

gray - blocked

light green - connecting

purple - waiting for response

dark green - recieving data

 

slow_geocaching.png

 

and for comparison the http://origin.rhapsody.com/browse/new website:

slow_geocaching2.png

 

Here's the a trace route for both servers:

C:\Users\Petr>tracert www.geocaching.com

Tracing route to www.geocaching.com [63.251.163.200]
over a maximum of 30 hops:

 1     9 ms    <1 ms    <1 ms  192.168.5.1
 2     2 ms     *       37 ms  ###.net.vse.cz [146.102.###.###]
 3   253 ms     *        3 ms  ###.net.vse.cz [146.102.###.###]
 4     4 ms     4 ms     2 ms  ge-zizkov.net.vse.cz [146.102.25.29]
 5     5 ms     1 ms     1 ms  geruk-gezizkov.pasnet.cz [195.113.68.217]
 6     2 ms     1 ms     2 ms  geff-geruk.pasnet.cz [195.113.69.63]
 7   210 ms     4 ms     1 ms  geovc-geff.pasnet.cz [195.113.67.5]
 8   212 ms     4 ms     1 ms  bgpovc-geovc.pasnet.cz [195.113.68.153]
 9    11 ms     3 ms     2 ms  cesnetzikova-bgpovc.pasnet.cz [195.113.69.54]
10     5 ms     3 ms     2 ms  prag-b3-pos4-0.telia.net [213.248.77.117]
11     2 ms     2 ms     4 ms  prag-bb1-link.telia.net [213.155.132.164]
12    20 ms    20 ms    21 ms  ffm-bb1-link.telia.net [80.91.246.14]
13   140 ms    20 ms    20 ms  ffm-b12-link.telia.net [62.115.141.233]
14    32 ms   284 ms    23 ms  ntt-ic-155239-ffm-b12.c.telia.net [213.248.72.10]
15   233 ms   192 ms    21 ms  ae-2.r20.frnkge04.de.bb.gin.ntt.net [129.250.5.217]
16   119 ms   112 ms   113 ms  ae-7.r22.asbnva02.us.bb.gin.ntt.net [129.250.3.20]
17   114 ms   113 ms   119 ms  ae-0.r23.asbnva02.us.bb.gin.ntt.net [129.250.3.85]
18   176 ms     *      454 ms  ae-3.r21.sttlwa01.us.bb.gin.ntt.net [129.250.3.51]
19   172 ms   173 ms   175 ms  ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45]
20   176 ms   171 ms   169 ms  ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]
21   170 ms   168 ms   169 ms  border9.po1-40g-bbnet1.sef.pnap.net [63.251.160.19]
22   169 ms   171 ms   175 ms  63.251.163.200

Trace complete.

C:\Users\Petr>tracert origin.rhapsody.com

Tracing route to origin.rhapsody.com [66.150.171.162]
over a maximum of 30 hops:

 1     2 ms    <1 ms     2 ms  192.168.5.1
 2     1 ms     *       89 ms  ###.net.vse.cz [146.102.###.###]
 3    23 ms     *        1 ms  ###.net.vse.cz [146.102.###.###]
 4     4 ms     4 ms     2 ms  ge-zizkov.net.vse.cz [146.102.25.29]
 5     2 ms     2 ms     1 ms  geruk-gezizkov.pasnet.cz [195.113.68.217]
 6    65 ms     2 ms     1 ms  gejinonice-geruk.pasnet.cz [195.113.67.32]
 7   190 ms     2 ms     5 ms  geovc-gejinonice.pasnet.cz [195.113.69.177]
 8   216 ms     1 ms     5 ms  bgpovc-geovc.pasnet.cz [195.113.68.153]
 9     2 ms     3 ms     2 ms  cesnetzikova-bgpovc.pasnet.cz [195.113.69.54]
10     2 ms     2 ms     2 ms  prag-b3-pos4-0.telia.net [213.248.77.117]
11     2 ms     2 ms     2 ms  prag-bb1-link.telia.net [80.91.249.227]
12    21 ms    20 ms    20 ms  ffm-bb1-link.telia.net [62.115.136.64]
13    21 ms    22 ms    26 ms  ffm-b12-link.telia.net [62.115.142.23]
14   188 ms   285 ms    21 ms  ntt-ic-155239-ffm-b12.c.telia.net [213.248.72.10]
15   521 ms    21 ms   282 ms  ae-5.r21.frnkge03.de.bb.gin.ntt.net [129.250.4.162]
16   111 ms   111 ms   114 ms  ae-3.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.180]
17   113 ms   144 ms   114 ms  ae-0.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.72]
18   189 ms   184 ms     *     ae-1.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.13]
19   279 ms   305 ms   214 ms  ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45]
20   180 ms   180 ms   172 ms  ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18]
21   181 ms   183 ms   181 ms  border1.t8-1-bbnet2.sef003.pnap.net [63.251.160.85]
22   173 ms   173 ms   173 ms  206.191.144.222
23   172 ms   173 ms   172 ms  origin.rhapsody.com [66.150.171.162]

Trace complete.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...