And to double check, thats entanet using WBC too.

In reply to a post by RobertoS:

In reply to a post by driz:

Correct - the ping to hop 11 from the source system was 1ms.

And if hop 17 takes 13ms from system, and hop 18 takes 19ms from the source system, then the time to traverse the link between 17 and 18 is 6ms? I'm not sure what the confusion is!

Therefore the time taken to traverse the link between 12 and 13 was minus 5ms.

This can be caused by different packet handing and traffic prioritisation along the route and at the destination - with in this case hop 12 passing packets between 11 and 13 faster than it dealing with packets "destined" for itself.

The way traceroute works is by always sending to the final destination but with a limited hop count: 1 first time, then 2, then 3, ... - so when you get a reply back (unless that reply is from the destination) it is actually an error response (hop count would be exceeded if I passed this further) which is why the node handles them differently to when it is simply forwarding the original packet on or forwarding the error report (which it doesn't know/care is an error: it is just a packet to be routed with a valid hop count) back.

Thanks, but we've been through all that. If you follow through what leads up to what you quote from me, I am saying it to debunk his assertation that the time to traverse 17-18 is 6ms, by saying something that logically follow from his belief but which is clearly absurd.

Therefore his belief is wrong.

I don't think he has grasped that even now.

If you are looking for an ISP that does absolutely nothing with your traffic including DNS (many replace NXDOMAIN errors with references to their search/advert web server for instance) then you'll need to pay a bit extra I'm afraid, to use the likes of AAISP, Zen, or their ilk.

AAISP goes a little further than most in that they are one of the few that don't even subscribe to the IWF blacklist. If using AAISP you can reduce the bandwidth cost of your ~80-100Gb considerably if you can schedule large downloads for between 0200 and 0600 when downstream transfer is metered at 5% of what it is at other non-peak times. Obviously that doesn't help is most of your downstream activity is interactive (live TV/film streaming for instance). Upstream transfer is never metered on most of the more expensive ISPs.

Oops, I thought I was replying to him there. Must have got myself lost in the thread a bit and should have read the rest in ore detail before replying!

In reply to a post by RobertoS:

Thanks, but we've been through all that. If you follow through what leads up to what you quote from me, I am saying it to debunk his assertation that the time to traverse 17-18 is 6ms, by saying something that logically follow from his belief but which is clearly absurd.

Therefore his belief is wrong.

I don't think he has grasped that even now.

Perhaps we are not understanding each other.

Hop 18 is my home router. Hop 17 is whatever one might usually refer to as my 'first hop' if you were doing a traceroute from your home out to the wider internet. 17 and 18 correspond to 1 and 2 in my second traceroute.

It is reasonably well established that FTTC fastpath (and ADSL fastpath) introduces about 5-6ms latency.

I am definitely _not wrong_ about this.

An errant value midway through a traceroute does not prove my premise incorrect - that particular router may deprioritise ICMP traffic. Or maybe it's related to MPLS. BT's network is frankly a bit of a mystery to me, which is why I'm a) trying to understand it and b) trying to move somewhere else.

Thanks both - very useful.

Ah, now I see where you are going wrong .

The direction is relevant. You just implied that it isn't. Any one, or a combination of a few adding 1ms or so, of the routers that tracert went through could have caused the extra 6ms.

It is reasonably well established that FTTC fastpath (and ADSL fastpath) introduces about 5-6ms latency.

Really?

In reply to a post by dspillett:

If you are looking for an ISP that does absolutely nothing with your traffic including DNS (many replace NXDOMAIN errors with references to their search/advert web server for instance) then you'll need to pay a bit extra I'm afraid, to use the likes of AAISP, Zen, or their ilk.

AAISP goes a little further than most in that they are one of the few that don't even subscribe to the IWF blacklist. If using AAISP you can reduce the bandwidth cost of your ~80-100Gb considerably if you can schedule large downloads for between 0200 and 0600 when downstream transfer is metered at 5% of what it is at other non-peak times. Obviously that doesn't help is most of your downstream activity is interactive (live TV/film streaming for instance). Upstream transfer is never metered on most of the more expensive ISPs.

I like the look of AAISP and seem to be the closest philosophically to what I'm looking for BUT their weekday usage rates make it untenable. We use Netflix et al pretty regularly and the idea of severely restricting daytime internet usage on a bank holiday or perhaps if someone had a day off work is just a little too constrictive.

Zen seem to be the next best choice, I think.

In reply to a post by RobertoS:

Ah, now I see where you are going wrong .

The direction is relevant. You just implied that it isn't. Any one, or a combination of a few adding 1ms or so, of the routers that tracert went through could have caused the extra 6ms.

It is reasonably well established that FTTC fastpath (and ADSL fastpath) introduces about 5-6ms latency.

Really?

You're not really claiming anything except that I'm going wrong. Except that I'm not going wrong.

Is it really just a coincidence that hop 1 to 2 going out (6ms change) is the same as hop 17 to 18 (6ms) coming in?

OR, does it show time taken to traverse that link?

Another example, using BT's looking glass from London to a server in New York - http://lg.bt.net/

This is an extract:
5 ae-59-224.ebr2.London1.Level3.net (4.69.153.141) [AS 3356] 0 msec
ae-56-221.ebr2.London1.Level3.net (4.69.153.129) [AS 3356] 0 msec
ae-58-223.ebr2.London1.Level3.net (4.69.153.137) [AS 3356] 0 msec
6 ae-44-44.ebr1.NewYork1.Level3.net (4.69.137.78) [AS 3356] 80 msec
ae-42-42.ebr1.NewYork1.Level3.net (4.69.137.70) [AS 3356] 68 msec
ae-43-43.ebr1.NewYork1.Level3.net (4.69.137.74) [AS 3356] 76 msec
7 *
ae-91-91.csw4.NewYork1.Level3.net (4.69.134.78) [AS 3356] 68 msec
ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) [AS 3356] 76 msec
8 ae-33-80.car3.NewYork1.Level3.net (4.69.155.133) [AS 3356] 68 msec 72 msec
ae-23-70.car3.NewYork1.Level3.net (4.69.155.69) [AS 3356] 96 msec
9 PILOSOFT-IN.car3.NewYork1.Level3.net (4.53.88.10) [AS 3356] 68 msec 72 msec 68 msec

Hop 5 is in London. Hop 8 is in New York. It is relatively well known that it takes about 70ms to cross the atlantic from London to NY. Coincidentally, this is the difference between these hops.

As to really? Well, yes.