[Doylo]

Very hit and miss for me at the mo

[dontfollowme]

Very flakey here too, having to refresh lots.

[Johnny Brown]

Still fine here.

[Tris]

Still fine here.

Just rub it in 

[Fatboy]

Fine here too over in sunny/cloudy Ireland!! 

[slackline]

There are a few nodes that data is passing through between the host server and my computer that are very slow to respond (already passed this info to Bubba)...

From my work computer where things are slow we have the following route being taken when connecting to UKB...

Code: [Select]

# tracepath [url=http://www.ukbouldering.com]www.ukbouldering.com[/url]
 1:  dyn138134.shef.ac.uk (143.167.138.134)                 0.100ms pmtu 1500
 1:  143.167.136.254 (143.167.136.254)                      3.694ms
 1:  143.167.136.254 (143.167.136.254)                      6.512ms
 2:  172.22.0.66 (172.22.0.66)                              1.219ms
 3:  172.22.1.67 (172.22.1.67)                              1.867ms
 4:  po12.sff-d01.yhman.net.uk (195.195.130.33)             1.683ms
 5:  v795.lee-c01.yhman.net.uk (194.81.2.73)                2.668ms
 6:  so-1-1-0.leed-sbr1.ja.net (146.97.42.25)               2.667ms asymm  7
 7:  so-5-1-0.lond-sbr1.ja.net (146.97.33.98)               7.152ms asymm  8
 8:  so-6-0-0.lond-sbr4.ja.net (146.97.33.154)              7.412ms asymm  9
 9:  ae0.lond-gw-ixp4.ja.net (146.97.35.182)                7.398ms asymm 10
10:  no reply
11:  no reply
12:  te0-2-0-6.ccr22.jfk02.atlas.cogentco.com (154.54.30.134)  82.905ms
13:  no reply
14:  no reply
15:  river-city-internet-group.demarc.cogentco.com (38.104.162.10) 124.405ms asymm 16
16:  river-city-internet-group.demarc.cogentco.com (38.104.162.10) 126.263ms
17:  static-216.87.62.241.primary.net (216.87.62.241)     134.563ms asymm 19
18:  r-1.core04.stl.rosehosting.com (206.196.99.250)      133.640ms asymm 21
19:  vs314.rosehosting.com (209.135.140.14)               122.593ms reached
     Resume: pmtu 1500 hops 19 back 47


Note the nodes with "no reply" where there is a big delay.

[Bubba]

I'm getting steady pings of around 120ms today. I've emailed the hosts and they can't see any problems.

What ISPs are you slow people using? Wondering if there's something in common.

[Jaspersharpe]

What ISPs are you slow people using?

Watch it. Glen Hoddle got sacked for talking about people like that.

[slackline]

Similar speeds (generally between 110 and 125ms) on pings from work where I've the problem (ISP is Univ of Sheffield, which is part of JANET).  I also get similar stats when pinging from my home computer where I don't have any problems.

But then pinging isn't the same as page requests and the complex db/php interaction.

Is there any caching of popular pages (thinking possibly the CSS sheet) that may have gone astray?

[Bubba]

I'm confused, I thought the problem was timeouts (no reply) in the traceroute, i.e. slow reaching the site.

Are you saying that's not the issue, but it's the actual pages being served slowly?

I'll flush the forum page cache to see if that helps.

[cofe]

it's been fine for me all week. look at me.

[Kim]

It's been fine for me all week (on a sky connection) but now using andy's bt connection (same computer) and it's gone all fuckwise.

[Bubba]

Anything cached has been purged. Make sure to do a CTRL+F5 to pull in anything that needs to override what's cached in your browser.

[slackline]

I'm confused too, mainly cause I don't really know what I'm talking about 

But my understanding is

ping = send a small packet of data to a server and time how long it takes to get back
traceroute = send a small packet of data to a server and record what nodes it passes through and how long it takes at each node

Neither of these are the same as making page requests of a server (particularly if there is some sort of LAMP setup involved with a DB/CGI/PHP combo).

Looking at the times for ping's and traceroutes from the two computers I use (one at work with a problem, the other at home without any problem) they seem comparable, so I suspect its not server responsiveness thats the problem here, but more how pages requests are being handled/served by the server.

I'm not that experienced in server configuration but CGI modules allow frequently requested pages such as CSS sheets to be cached to avoid clogging up the server and "stuff".

Perhaps, if its possible, turning on verbose logging and seeing what entries there are for people who are having problems might provide some insight? 

[magpie]

I'm confused, I thought the problem was timeouts (no reply) in the traceroute, i.e. slow reaching the site.

Are you saying that's not the issue, but it's the actual pages being served slowly?

I am getting both. :lucky:

I don't know anything about my ISP or my pings though.  ???

[Kim]

I'm confused too, mainly cause I don't really know what I'm talking about 

and then proceeded to demonstrate he has some idea what he's talking about.

My understanding, as someone who really doesn't know what he's talking about

ping = four fifths of a penguin
traceroute = plagiarising maps

Neither of these would seem to help much.

Oh yeah, my point was it seems fine all of a sudden. Well done bubba i assume 

[Tris]

As I said before all my tests have been with BT. I am stuck with this shite ISP unfortunately...

Traceroutes from 2 x different BT ADSL lines:

Tracing route to ukbouldering.com [209.135.140.14]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  www.routerlogin.com [192.168.0.1]
  2    32 ms    31 ms    31 ms  host81-148-0-1.in-addr.btopenworld.com [81.148.0.1]
  3    31 ms    32 ms    32 ms  213.120.178.141
  4    32 ms    31 ms    31 ms  213.120.177.98
  5    32 ms    31 ms    33 ms  213.120.176.22
  6     *       31 ms     *     213.120.176.178
  7    32 ms    32 ms    34 ms  213.120.176.121
  8    32 ms    32 ms    31 ms  core2-gig14-0-0.faraday.ukcore.bt.net [62.172.102.153]
  9    33 ms    32 ms    33 ms  62.172.103.45
 10    32 ms    32 ms    33 ms  transit1-xe0-1-0.ealing.ukcore.bt.net [194.72.9.234]
 11    32 ms    32 ms    32 ms  t2c1-ge11-0-0.uk-eal.eu.bt.net [166.49.168.29]
 12    33 ms    33 ms    34 ms  t2c2-p3-1.uk-lon1.eu.bt.net [166.49.208.110]
 13    33 ms    33 ms    33 ms  t2a1-ge7-0-0.uk-lon1.eu.bt.net [166.49.135.110]
 14    48 ms   245 ms   228 ms  gi8-44.mpd01.lon01.atlas.cogentco.com [130.117.14.49]
 15    34 ms    34 ms    33 ms  te1-8.ccr01.lon01.atlas.cogentco.com [130.117.3.226]
 16    52 ms    51 ms    51 ms  te0-0-0-0.ccr21.ams03.atlas.cogentco.com [130.117.1.109]
 17    51 ms    50 ms    51 ms  te3-8.ccr02.ams03.atlas.cogentco.com [130.117.0.33]
 18   120 ms   119 ms   120 ms  te4-2.ccr02.ymq02.atlas.cogentco.com [154.54.0.74]
 19   149 ms   149 ms   149 ms  te8-7.ccr02.ord01.atlas.cogentco.com [154.54.28.5]
 20   144 ms   145 ms   144 ms  te4-2.ccr01.stl03.atlas.cogentco.com [154.54.27.30]
 21   144 ms   143 ms   143 ms  river-city-internet-group.demarc.cogentco.com [38.104.162.10]
 22   142 ms   142 ms   143 ms  205.242.181.29
 23   168 ms   141 ms   141 ms  r-1.core04.stl.rosehosting.com [206.196.99.250]
 24   142 ms   142 ms   141 ms  vs314.rosehosting.com [209.135.140.14]

Trace complete.

Tracing route to ukbouldering.com [209.135.140.14]
over a maximum of 30 hops:

  1     3 ms     1 ms     2 ms  home [10.0.0.1]
  2    34 ms    34 ms    34 ms  host81-134-96-1.in-addr.btopenworld.com [81.134.96.1]
  3    33 ms    32 ms    32 ms  213.120.182.141
  4    33 ms    34 ms    32 ms  213.120.161.82
  5    34 ms    34 ms    32 ms  217.41.222.30
  6    33 ms    32 ms    33 ms  217.41.222.178
  7    33 ms    34 ms    34 ms  217.41.222.121
  8    33 ms   243 ms    32 ms  core2-gig4-0-0.birmingham.ukcore.bt.net [217.32.170.73]
  9   261 ms    42 ms   248 ms  62.172.103.86
 10    54 ms    39 ms    36 ms  transit1-xe1-1-0.ealing.ukcore.bt.net [62.6.200.138]
 11    39 ms     *       40 ms  t2c1-ge14-0-0.uk-eal.eu.bt.net [166.49.168.25]
 12    45 ms    38 ms    38 ms  t2c2-p3-2.uk-lon1.eu.bt.net [166.49.164.138]
 13    39 ms    38 ms    38 ms  t2a1-ge7-0-0.uk-lon1.eu.bt.net [166.49.135.110]
 14    41 ms     *        *     gi8-44.mpd01.lon01.atlas.cogentco.com [130.117.14.49]
 15    40 ms    42 ms    38 ms  te3-1.mpd02.lon01.atlas.cogentco.com [130.117.2.26]
 16    49 ms    48 ms    48 ms  te0-3-0-0.mpd21.ams03.atlas.cogentco.com [130.117.2.82]
 17    49 ms    50 ms    50 ms  te1-8.ccr02.ams03.atlas.cogentco.com [130.117.49.206]
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22   153 ms     *        *     static-216.87.62.241.primary.net [216.87.62.241]
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

Not sure if this helps, but could be a routing issue somewhere?

[Peanuts]

Pretty unusable and has been for a few days, have been forced to go to the 'other place' for my fix 

[Bubba]

From looking at some of these traceroutes, it appears that the problem lies with Cogent. In which case there's nothing we can do.

[slackline]

Okay then, can people post details of their DNS servers for places where they are having a problem and also from locations where they're not.

From work I have the following DNS servers listed (and presume they are used in sequential order)...

143.167.2.110
143.167.252.110
208.67.222.222
208.67.220.220

[Tris]

What has DNS got to do with possible routing issues? We can see that DNS is working from the traceroute commands - the ip's are resolved from the names...

EDIT: unless Bubba says that UKB is not on 209.135.140.14?

[slackline]

I thought that different DNS at say home v's work may result in different routes for the data being taken as they're clearly not going the same routes.

But then I don't really know enough about network protocols and such like to really know what I'm talking about, t'was just a stab in the dark, and I was going to try an alternative DNS of someone who isn't having a problem to see if that resolved it (can't get at my home DNS entries at present).

Kind of like troubleshooting, if it fixes it then its a work-around solution, whilst waiting for the true cause to be identified/resolved.  Often how I go about solving computing problems when I've no real idea of the underlying cause   

[slackline]

Not that it provides much insight, but the site is still very slow if I use a proxy server.

[GCW]

I haven't beeen able to get on UKB yesterday, session timed out error message. Has been on my home PC and at work. Still not working, so this is brought to you via gayPhone.

[dobbin]

I have had problems as well from both home and work.

DNS however is probably a red herring. For the reason that by the time your traceroute takes place, DNS is finished and done with. The way DNS and traceroute works is thus :

I want to traceroute UKB. I tell my computer as much.
My computer doesnt know where UKB is so it asks its configured DNS server.
That doesnt know either, so it asks another DNS server upstream from it (which is called a recursive lookup)
that one still may not know, but it knows one that does, and ultimately gets an answer, which it hands back down to me.
Now knowing where UKB is, i send a ping with something called a Time to live value set to 1. This is a value used to prevent routing loops which I set to say "only pass through one router". So at the first time my packet goes to a router, the router reads this TTL field and says "oooh, that means this packet must be looped, i'll drop it, and respond". I get a message back which tells me the packet was dropped. Reading the source field of the packet I can see where it went. So, I send another packet - this time setting TTL to 2. Which means when it gets to the router we saw before it thinks its ok to forward it and makes a routing decision - sending the packet on with a decremented TTL value (now 1). Our packet hits a second router which spots the TTL =1 thing, thinks its got a looped packet and drops it as before. The problem with this is that some router administrators may have configured the router not to respond deliberately. So traceroute with a missing step doesnt always mean theres a problem with a router.

Plus, each router makes a routing decision based on its current routing topology which is governed by the state of its interfaces and what it knows about routers and routes near it - from one packet to the next, different routes may apply - packets may take a different path. By its very nature, IP is resilient - it will work around black holes (with occasional packet loss whilst things converge) so where routing a problem the routers between you and ukb should (!) sort themselves out over time.

Looking for commonality between the traces that failed and those that didnt - it all seems to sit within the cogentco cloud, who are one ISP who probably resell space or IP peering to rosehosting. Perhaps they had problems over the last few days? I seem to work today when I didnt yesterday for instance?!

Finally, PING - round trip packet time is the amount of delay it takes for me to talk to ukb. 120ms is slow. Rosehosting must be a lot of routers away! lot of routers = lot of routing decisions = potential for problems. Hosting in the UK would probably mitigate, but at what cost?