I normally connect through a wireless router that feeds into a netgear router that is also the modem that connects to the BT network.

I thought I would have a play with changing my MTU in case I was getting headers added at both the wireless router and at the netgear one which could be taking me over 1500 - especially as my laptop (Linux) is set to an MTU of 1500 (I think that the Linux figure probably includes allowance for the headers  but I am open to other opinions).

I did the tests suggested on Kitz site but the answer I got was not what I expected. At the sensible end, packet sizes of 1472 seemed to go through with a response time of about 60mS. So did packets that were only 1400, 1000 and 500. I had to go right down to 100 before I got an improvement and the response time improved to about 25mS. That cannot be MTU related (surely?) but does it give anyone any ideas as to what I need to change to get 25mS with a normal packet size? Why would 100 bytes get through so much quicker than say 1400 when both should be being treated as one

All thoughts gratefully received.

Jim

I'm surprised no-one has commented!
Prompted by your post I did a little experimenting. Use of the -l flag (& hence the packet size) is what seems lengthen the response time.
I only tried with my default MTU (1500) so using ping -l 1472 bbc.co.uk gave me typical average.times around 67ms whereas ping bbc.co.uk gave me typical average times of 35ms. Use of the -f flag seemed to make no difference. Actual ping times will vary depending on where you are (and whether interleaving is on/off).
I noted the response time did come down as the specified -l packet size was reduced, it wasn't much quicker once you got below 100, however it's certainly not a very efficient way of sending packets as the header sizes are significantly large compared to the data size.

In conclusion, I can only guess (no expert in this area) that packet sizes assumed different from the default MTU size as specified by the -l flag require some additional processing and this is what adds to the times - maybe someone with the knowledge will give the definitive answer.
That said, the obvious most efficient way is to use the maximum MTU size that everything you use will cope with (1500 in most cases). Then adjust your rWIN to give maximum throughput if your OS doesn't do this (see Kitz page).

Edit: Perhaps if a mod moved this to the main Community Support board rather that the Speed board, it may have a greater response.

changing the packet size to 1472 from the normal 32 bytes in ping plotter also gives the same latency diffrence as below,


Pinging bbc.co.uk [212.58.224.138] with 1472 bytes of data:
Reply from 212.58.224.138: bytes=1472 time=40ms TTL=121
Reply from 212.58.224.138: bytes=1472 time=37ms TTL=121
Reply from 212.58.224.138: bytes=1472 time=37ms TTL=121
Reply from 212.58.224.138: bytes=1472 time=37ms TTL=121

Pinging bbc.co.uk [212.58.224.138] with 1000 bytes of data:
Reply from 212.58.224.138: bytes=1000 time=31ms TTL=121
Reply from 212.58.224.138: bytes=1000 time=30ms TTL=121
Reply from 212.58.224.138: bytes=1000 time=30ms TTL=121
Reply from 212.58.224.138: bytes=1000 time=30ms TTL=121

Pinging bbc.co.uk [212.58.224.138] with 500 bytes of data:
Reply from 212.58.224.138: bytes=500 time=24ms TTL=121
Reply from 212.58.224.138: bytes=500 time=23ms TTL=121
Reply from 212.58.224.138: bytes=500 time=23ms TTL=121
Reply from 212.58.224.138: bytes=500 time=23ms TTL=121

Pinging bbc.co.uk [212.58.224.138] with 100 bytes of data:
Reply from 212.58.224.138: bytes=100 time=16ms TTL=121
Reply from 212.58.224.138: bytes=100 time=17ms TTL=121
Reply from 212.58.224.138: bytes=100 time=17ms TTL=121
Reply from 212.58.224.138: bytes=100 time=17ms TTL=121

No [Censored] Sherlock!

If your connection is running at 8192K bits per second a packet of 1500 bytes takes about 1.5ms to transmit. Repeat that for every link it travels to the target and every link it comes back through (it echos back the same packet size) and it's obvious it must take longer! (Don't forget that on a tracert there are a lot of links hidden (around 8 I think) because your connection is tunnelled from your router to the Plusnet equipment.

Derrr, brain on, I was forgetting a standard ping packet was 32 bytes. Must have been half asleep as well - it even says on the first line of output Pinging bbc.co.uk [212.58.224.138] with 32 bytes of data:
 

I would like to challenge two assumptions that this makes:-

1. I believe that many of the various systems use a fixed block size. So they would pad 32 bytes up to 1500 (minus header) and just pass blocks around. While this could be inefficient for small amounts of data, most blocks would be full so they are not inefficient and a fixed block size is easier to handle than having to check every byte for a "start of new header" flag. I am almost sure that voice systems use fixed block sizes at the exchange to exchange level for example though that could be a different sort of problem.

2. That the speed of transmission is only 8Mbps on the main links. Surely once the data gets to the exchange, it is amalgamated with lots of other data and sent down a great big high speed motorway of a pipe and totally zonks along

Also, going back to my original story, the quick pings cut in quite suddenly as I went down in size. There may well have been some gradual reduction that reflects the speed of transmission as you suggest, but I am almost sure I got a sharp change somewhere above 100 bytes but below 500. -I must try that again to confirm it.

Jim

nope  ping on my line does not have a certain packet size where the ping suddenly falls away

Pinging bbc.co.uk [212.58.224.138] with 200 bytes of data:
Reply from 212.58.224.138: bytes=200 time=19ms TTL=122
Reply from 212.58.224.138: bytes=200 time=19ms TTL=122
Reply from 212.58.224.138: bytes=200 time=19ms TTL=122
Reply from 212.58.224.138: bytes=200 time=19ms TTL=122

Pinging bbc.co.uk [212.58.224.138] with 300 bytes of data:
Reply from 212.58.224.138: bytes=300 time=21ms TTL=122
Reply from 212.58.224.138: bytes=300 time=20ms TTL=122
Reply from 212.58.224.138: bytes=300 time=20ms TTL=122
Reply from 212.58.224.138: bytes=300 time=21ms TTL=122

Pinging bbc.co.uk [212.58.224.138] with 400 bytes of data:
Reply from 212.58.224.138: bytes=400 time=22ms TTL=122
Reply from 212.58.224.138: bytes=400 time=22ms TTL=122
Reply from 212.58.224.138: bytes=400 time=23ms TTL=122
Reply from 212.58.224.138: bytes=400 time=23ms TTL=122

Well your ping times are all better than mine are at any size.

At the moment my pings to the BBC are of the order of 800mS - so I think I will wait for more sensible times before I try again - maybe tomorrow.

Jim

i am on 21cn adsl2 (which dont make much if any diffrence, apart from midnight of cause  ) but more improtant there fastpath pings not interleaved but 800ms to bbc.co.uk is a silly value even on intreleaved

Do I take it that was a plain ping to bbc.co.uk (no www). & do you know what gateway you were/are on when that happened and confirm the time as accurately as you can. It should be useful to PN to have this detail.

This morning I did a speed check and tried the experiments with MTU again. It was perhaps not quite a fair test as the speeds were very good for once (2.4Mbps which is good for my line).

A straight ping test to the bbc produced times of 23 or so milliseconds. When I started to force different packet sizes the times went up steadily, lets say 25mS for a packet size of 100, 27 for 200, 29 for 300 etc up to about 58mS for 1400. But no sharp change - so I guess that makes Jelv right, much as I hate to admit it

The 800mS pings did not last long last night - the DNS seemed to go away totally at about 10:10pm. I could ping the DNS server but not get a lookup from them at all. I could also read the one page on the BBC whose IP I new - so the net was ok but neither of my computers could get anywhere using a URL.  So I am surprised to see nothing about a DNS collapse on the forums - its worrying. Anyway OpenDNS is where I go next.

Jim

i currently use opendns and pn dns as secondary

Hi EnglishMohican,

We're suspecting most of the problems seen were due to the drop of PCL-AG03 and the associated issues (we've got a service status post out now at http://status.plus.net) - do you know if that's the gateway you were connected to?