cancel
Showing results for 
Search instead for 
Did you mean: 

Latency/ping

ArthurDent
Grafter
Posts: 170
Thanks: 2
Registered: ‎25-02-2013

Latency/ping

(Have separated out this query I posted elsewhere)
Remind me, please, why is there such a disparity in latency depending on who reports it::
BTW - 47
Thinkbroadband - 32
Speedtest (ookla) - 24
OK, I know there's going to be a brief time lag between them but that difference seems excessive! Who do I believe?
RF suggested it was due to variations in the distant server, which seemed feasible. However I'm not now sure. Speedtest/ookla gives you a choice and previously I was using xylo, only about 5 miles from chez Dent as the drone flies. But I've just selected others much more distant and got similarly lower speedtest/ookla figures:
BTW - 41
Thinkbroadband - 31
Speedtest/ookla - averages 26
Pinging plusnet averages 35
What can one deduce from all this please?
 
6 REPLIES 6
AndyH
Grafter
Posts: 6,824
Thanks: 1
Registered: ‎27-10-2012

Re: Latency/ping

All of them use java/flash and I don't rate any of them for ping response times.
A much better way is to use the ping command (e.g. ping bbc.co.uk) from the command prompt.
30FTTC06
Pro
Posts: 2,286
Thanks: 108
Fixes: 4
Registered: ‎18-02-2013

Re: Latency/ping

I was looking at this earlier and I located and tested the severs as follows.
[tt]
BT
193.113.8.193 
193.113.4.154
22 ping
ThinkBroadband
80.249.107.221
80.249.106.133
64 bytes from 80.249.107.221: icmp_seq=5 ttl=59 time=16.6 ms
64 bytes from 80.249.107.221: icmp_seq=6 ttl=59 time=17.3 ms
64 bytes from 80.249.107.221: icmp_seq=7 ttl=59 time=16.9 ms
64 bytes from 80.249.107.221: icmp_seq=8 ttl=59 time=16.7 ms

Speedtest.net london server
85.233.160.167
64 bytes from 85.233.160.167: icmp_seq=1 ttl=58 time=19.6 ms
64 bytes from 85.233.160.167: icmp_seq=2 ttl=58 time=19.0 ms
64 bytes from 85.233.160.167: icmp_seq=3 ttl=58 time=19.1 ms
64 bytes from 85.233.160.167: icmp_seq=5 ttl=58 time=19.1 ms
[/tt]
The BT server doesn't give priority for ping
[tt]
1. 192.168.0.254                                    0.0%    69  48.0  50.7  4.2  99.3  30.9
2. lo0.10.central10.pcl-bng01.plus.net              0.0%    69  17.2  18.2  16.1  43.4  4.9
3. irb.10.pcl-cr02.plus.net                          0.0%    68  16.8  20.3  16.0  54.2  9.3
    irb.10.pcl-cr01.plus.net
4. ae1.ptw-cr02.plus.net                            0.0%    68  16.8  19.8  16.2  65.1  7.7
    ae1.ptw-cr01.plus.net
    ae2.pcl-cr01.plus.net
    ae2.pcl-cr02.plus.net
5. ae2.ptw-cr01.plus.net                            0.0%    68  17.6  20.0  16.5  54.2  6.0
    ae1.ptw-cr01.plus.net
    195.99.126.182
    195.99.126.138
    ae1.ptw-cr02.plus.net
    ae2.ptw-cr02.plus.net
6. 195.99.126.138                                    0.0%    68  17.8  21.1  16.8  41.6  3.9
    core1-te0-15-0-10.ealing.ukcore.bt.net
    core1-te0-3-0-7.ilford.ukcore.bt.net
    core1-te0-15-0-10.ilford.ukcore.bt.net
    195.99.126.182
    194.72.31.148
    core2-te0-15-0-4.ealing.ukcore.bt.net
    core2-te0-3-0-12.ealing.ukcore.bt.net
7. core2-te0-15-0-10.ealing.ukcore.bt.net            0.0%    68  22.6  34.3  17.9 211.6  38.3
    core1-te0-3-0-7.ilford.ukcore.bt.net
    core1-pos1-1.birmingham.ukcore.bt.net
    core1-te0-0-0-11.ealing.ukcore.bt.net
    core2-pos1-1.birmingham.ukcore.bt.net
    core1-pos1-0.birmingham.ukcore.bt.net
    core2-pos1-0.birmingham.ukcore.bt.net
    core1-te0-15-0-10.ealing.ukcore.bt.net
8. core2-pos1-0.birmingham.ukcore.bt.net            0.0%    68  22.6  29.7  21.0 192.3  25.3
    iar1-gig5-4.birmingham.ukcore.bt.net
    core1-pos1-1.birmingham.ukcore.bt.net
    iar1-gig5-5.birmingham.ukcore.bt.net
    core1-pos1-0.birmingham.ukcore.bt.net
    core2-pos1-1.birmingham.ukcore.bt.net
9. iar1-gig5-5.birmingham.ukcore.bt.net              0.0%    68  22.1  23.3  21.0  57.1  4.8
    iar1-gig5-4.birmingham.ukcore.bt.net
    62.172.57.218
10. 62.172.57.218                                    46.3%    68  22.5  23.1  21.1  32.6  2.7
11. ?Huh
12. ?Huh
13. ?Huh
14. ?Huh
15. 193.113.8.193                                    47.8%    68  7377. 6357. 5388. 7377. 587.5
[/tt]
30FTTC06
Pro
Posts: 2,286
Thanks: 108
Fixes: 4
Registered: ‎18-02-2013

Re: Latency/ping

Mind u this is interesting..
[tt]
Connected to 193.113.4.154: time=28.78ms protocol=TCP port=80
Connected to 193.113.4.154: time=29.15ms protocol=TCP port=80
Connected to 193.113.4.154: time=27.21ms protocol=TCP port=80
Connection statistics:
Attempted = 3, Connected = 3, Failed = 0 (0.00%)
Approximate connection times:
Minimum = 27.21ms, Maximum = 29.15ms, Average = 28.38ms
Connected to 193.113.8.193: time=29.83ms protocol=TCP port=80
Connected to 193.113.8.193: time=28.20ms protocol=TCP port=80
Connected to 193.113.8.193: time=28.50ms protocol=TCP port=80
Connection statistics:
Attempted = 3, Connected = 3, Failed = 0 (0.00%)
Approximate connection times:
Minimum = 28.20ms, Maximum = 29.83ms, Average = 28.84ms
[/tt]
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: Latency/ping

I don't think the BT Wholesale speedtest even uses ICMP ping packets to measure latency - I didn't see any in wireshark. It probably just puts a timestamp in a URL, and compares the sent timestamp with when the request arrives at the server.
I concur that it's better to use ping at a command prompt for measuring latency.
ArthurDent
Grafter
Posts: 170
Thanks: 2
Registered: ‎25-02-2013

Re: Latency/ping

Many thanks! That's way too technical for me, but I'll follow your suggestion and use ping, just looking for any major change.
SuperZoom
Grafter
Posts: 353
Registered: ‎17-05-2013

Re: Latency/ping

It's true that the latency measures from the various online speed testers shouldn't be given much credence, but it's also worth remembering that modern networks, including PlusNet's Juniper platform and the underlying BT Wholesale infrastructure, are so heavily shaped and buffered that ICMP echo replies (ie. the ping command) may not give a particularly accurate picture of the real latency (nor the variation in it) across traffic classes either.
Ping is more usefully seen as an end-to-end link integrity (and possibly routing) check - provided the other end is set to reply. It will generally show up serious problems too, and on the flip side of that coin give an indication of the minimum achievable latency when things are running smoothly. But that minimum may not be what actual real-world traffic over other protocols experiences. It may often be: but not necessarily.
There's an interesting knowledge base article which explains why pinging the PlusNet gateways themselves is not a reliable measure of latency; and whilst it doesn't directly apply to pinging other sites on the internet, it does illustrate that various factors can be at work which cause different traffic to be treated differently in all sorts of places.
It is handy to use something like hping (or even Wireshark) to compare pings using TCP and UDP to build up a more accurate picture, but even then if DPI is being employed all bets are off.
I've had an opportunity to compare a PlusNet 40/20 FTTC connection with a 100/15 FTTP connection on a different exchange recently. The ICMP pings are a little higher on the FTTC (which is close to the cabinet) - around 5-6ms rather than 3-4ms on FTTP to 80.249.99.164 (ThinkBroadband) - and the bandwidth is obviously lower, yet my general subjective impression so far has been that the FTTC connection is snappier. Hard to put my finger on objective metrics, as ever, and I haven't had chance to do any serious testing, but real-world browsing latency seems as if it may be lower. Certainly not consistently higher, anyway.
So latency is indeed all a bit technical - or opaque and subjective, at any rate.