Latency - what is it?
Discussion
leosayer said:
Please can someone explain is simple terms what this means when applied to an internet connection.
Someone tried to explain using the example of a tap, water and a sink but it was lost on me.
Thanks
Think of your hot water tank and a tap.
Throughput (or bandwidth) is how much water per sec you can get out the tap - and the same amoutn of water goes out the tank into the pipes.
Latency is how long it takes for hot water to reach your tap, i.e. how long it takes for a single bit of water to reach the tap from the tank, regardless of other water...
I looked into satellite broadband a couple of years ago - once you have it all set up, you got a very high data rate. Unfortunately you had to set up your downloads and they were queued for some other time, so your latency was several hours...
Size Nine Elm said:
I looked into satellite broadband a couple of years ago - once you have it all set up, you got a very high data rate. Unfortunately you had to set up your downloads and they were queued for some other time, so your latency was several hours...
Plus the uplink is usually via a phone line (on a 56k modem!) so they're only any good for large downloads and tiny uploads.
pdV6 said:
I looked into satellite broadband a couple of years ago - once you have it all set up, you got a very high data rate. Unfortunately you had to set up your downloads and they were queued for some other time, so your latency was several hours...
Plus the uplink is usually via a phone line (on a 56k modem!) so they're only any good for large downloads and tiny uploads.
Indeed. So I went ISDN for a year, and then ADSL arrived...
Right, the best way to say it is :-
It's the time between me sending you some data, and me getting your reply that you've got it.
It's got almost nothing to do with bandwidth. In fact I've seen lower latency on some modem links than some ADSL lines before now. It DOES effect how fast data can be transfered (which is why it's commonly connected wrongly with bandwidth). The reason is if I send you a file, I'll do it in packets, and wait until you acknowledge me before I send another packet. If the latency is high I could double the bandwidth and it'd make very little difference, as most of the time I'm sitting doing nothing waiting for your reply, rather than actually moving data.
There are methods around high latency but to be honest for a home user they're usually very expensive and very application specific.
It's the time between me sending you some data, and me getting your reply that you've got it.
It's got almost nothing to do with bandwidth. In fact I've seen lower latency on some modem links than some ADSL lines before now. It DOES effect how fast data can be transfered (which is why it's commonly connected wrongly with bandwidth). The reason is if I send you a file, I'll do it in packets, and wait until you acknowledge me before I send another packet. If the latency is high I could double the bandwidth and it'd make very little difference, as most of the time I'm sitting doing nothing waiting for your reply, rather than actually moving data.
There are methods around high latency but to be honest for a home user they're usually very expensive and very application specific.
On a slightly more technical note, when my browser wants to down load a page from PH, it has to first establish a connection to the PH Web Server. It does this using a protocol called TCP (Transport Control Protocol)
Now, when the connection is established, the page from the PH Web Server is not sent back to my Browser in one big chunk, it is sent in lots of smaller chunks called packets, TCP tries to guarantee that all the packets required to get the page to my browser are delivered.
So TCP consists of a number of messages going backward and forwards between the browser and the web server, flagging which packets have been sent and which have been received. Eventually, the two systems agree that all the packets have been delivered and the connection may be closed.
Some times packets get lost due to too much traffic trying to flow through all these TCP connections - each packet has a Time-To-Live value attached to it, so if a packet cannot be delivered in a timely manner it will get dropped, it is upto the browser or server to make another request for that packet when a time out occurs.
Another reason for TTL is to prevent the network filling up with lost packets - imagine a scenario where a request is sent out but somewhere in the Internet a router doesn't know where to deliver it to? If packets did not have a TTL then eventually all these lost packets would mount up and clog all the genuiine ones.
TCP is also very intelligent, as it is constantly trying to send the most packets possible without waiting for an acknowledgement that the other end has received all the packets. If we ran a system where we ackknowledged each packet before sending another one we can only send one packet for every Round Trip Time - the time it takes for the Server to send a Packet to the Browser plus the time it takes for the Acknowledgemnet from the Broswer to get back to the Server. By allowing the Browser the opportunity to receive 10 packets without the Server needing an Ack then we can reduce the number of round trips by a factor of 10. So server sends 10, Browser send ack for those 10, Server sends next 10... etc,
So, TCP ascertains the quality of the network link by only acknowledging every n packets. At the same time it is also trying to send bigger and bigger packets through the network. Each packet has to carry source and destination information as well as the actual data it is transporting. The bigger the packet we can send then the less of the bandwidth is required for carrying just transport information.
As TCP stretches out all these paramters, eventually packets start gettting dropped, and TCP winds these paramters back a little until a reliable Packet Size and Acknowledgement Ratio is achieved.
When you then take a look at satellite communications (and some very long terrestrial links) we hit a new problem, latency - it takes along time (in computer communication terms) for a data packet to get all the way upto the satellite and back down again, before it even gets onto the Internet to go off to a Web Server somewhere.
This type of connection is called an LFP (elephant) Long, Fat, Pipes. LFPs have long long latency issues and so it is very important for TCP to be able to maximise its performance paramters to achives the best through put - we certainly don't want to be waiting for an ack for every packet on a link where the RTT can be 1/2 second!
Another problem with LFPs is that they actually hold a lot of data packets that are still in transit - this causes problems because the Browser may think it has lost a packet because it didn't see it before a timeout triggered, when in fact the packet is in the pipe and is likely to arrive safely any moment now.
There is a lot of fascinating research info about methods of tuning TCP to run over LFPs.
Hope this didn't bore you all to tears, I guess some of you might have found it a bit interesting - gotta go help a mate put the carb back on his quad bike now.
best
Ex
Now, when the connection is established, the page from the PH Web Server is not sent back to my Browser in one big chunk, it is sent in lots of smaller chunks called packets, TCP tries to guarantee that all the packets required to get the page to my browser are delivered.
So TCP consists of a number of messages going backward and forwards between the browser and the web server, flagging which packets have been sent and which have been received. Eventually, the two systems agree that all the packets have been delivered and the connection may be closed.
Some times packets get lost due to too much traffic trying to flow through all these TCP connections - each packet has a Time-To-Live value attached to it, so if a packet cannot be delivered in a timely manner it will get dropped, it is upto the browser or server to make another request for that packet when a time out occurs.
Another reason for TTL is to prevent the network filling up with lost packets - imagine a scenario where a request is sent out but somewhere in the Internet a router doesn't know where to deliver it to? If packets did not have a TTL then eventually all these lost packets would mount up and clog all the genuiine ones.
TCP is also very intelligent, as it is constantly trying to send the most packets possible without waiting for an acknowledgement that the other end has received all the packets. If we ran a system where we ackknowledged each packet before sending another one we can only send one packet for every Round Trip Time - the time it takes for the Server to send a Packet to the Browser plus the time it takes for the Acknowledgemnet from the Broswer to get back to the Server. By allowing the Browser the opportunity to receive 10 packets without the Server needing an Ack then we can reduce the number of round trips by a factor of 10. So server sends 10, Browser send ack for those 10, Server sends next 10... etc,
So, TCP ascertains the quality of the network link by only acknowledging every n packets. At the same time it is also trying to send bigger and bigger packets through the network. Each packet has to carry source and destination information as well as the actual data it is transporting. The bigger the packet we can send then the less of the bandwidth is required for carrying just transport information.
As TCP stretches out all these paramters, eventually packets start gettting dropped, and TCP winds these paramters back a little until a reliable Packet Size and Acknowledgement Ratio is achieved.
When you then take a look at satellite communications (and some very long terrestrial links) we hit a new problem, latency - it takes along time (in computer communication terms) for a data packet to get all the way upto the satellite and back down again, before it even gets onto the Internet to go off to a Web Server somewhere.
This type of connection is called an LFP (elephant) Long, Fat, Pipes. LFPs have long long latency issues and so it is very important for TCP to be able to maximise its performance paramters to achives the best through put - we certainly don't want to be waiting for an ack for every packet on a link where the RTT can be 1/2 second!
Another problem with LFPs is that they actually hold a lot of data packets that are still in transit - this causes problems because the Browser may think it has lost a packet because it didn't see it before a timeout triggered, when in fact the packet is in the pipe and is likely to arrive safely any moment now.
There is a lot of fascinating research info about methods of tuning TCP to run over LFPs.
Hope this didn't bore you all to tears, I guess some of you might have found it a bit interesting - gotta go help a mate put the carb back on his quad bike now.
best
Ex
. Don't think you said what the TLA RTT was though 
. TheExcession said:
Some times packets get lost due to too much traffic trying to flow through all these TCP connections - each packet has a Time-To-Live value attached to it, so if a packet cannot be delivered in a timely manner it will get dropped, it is upto the browser or server to make another request for that packet when a time out occurs.
All cool stuff, my anal-ness is twitching though - AFAIK though TTL is nothing to do with time as in seconds but purely the number of routers a packet can pass through. A packet should only usually reach it's TTL if a router is misconfigured and sending things round in circles. That's how traceroute works - send out a packet with a TTL of 1 then the first router will reply that the packet's been dropped, so you know what the first router is and how long it took to get there. Repeat with a TTL of 2 for the second one, etc. etc. until the packet gets all the way to the destination.
aldi said:Indeedy tho my old skool head remembers it can be in seconds or router hops. Next week we'll do the Nagle Algorithm, Sliding Windows, Congestion Avoidance and Selective Rejects
Some times packets get lost due to too much traffic trying to flow through all these TCP connections - each packet has a Time-To-Live value attached to it, so if a packet cannot be delivered in a timely manner it will get dropped, it is upto the browser or server to make another request for that packet when a time out occurs.
All cool stuff, my anal-ness is twitching though - AFAIK though TTL is nothing to do with time as in seconds but purely the number of routers a packet can pass through. A packet should only usually reach it's TTL if a router is misconfigured and sending things round in circles. That's how traceroute works - send out a packet with a TTL of 1 then the first router will reply that the packet's been dropped, so you know what the first router is and how long it took to get there. Repeat with a TTL of 2 for the second one, etc. etc. until the packet gets all the way to the destination.
TheExcession said:If you start talking about Manchester and Differential Manchester encoding I'm gonna have to slap you
Some times packets get lost due to too much traffic trying to flow through all these TCP connections - each packet has a Time-To-Live value attached to it, so if a packet cannot be delivered in a timely manner it will get dropped, it is upto the browser or server to make another request for that packet when a time out occurs.
All cool stuff, my anal-ness is twitching though - AFAIK though TTL is nothing to do with time as in seconds but purely the number of routers a packet can pass through. A packet should only usually reach it's TTL if a router is misconfigured and sending things round in circles. That's how traceroute works - send out a packet with a TTL of 1 then the first router will reply that the packet's been dropped, so you know what the first router is and how long it took to get there. Repeat with a TTL of 2 for the second one, etc. etc. until the packet gets all the way to the destination.
What you said would be correct if the data didnt need routing i.e web server was on the same subnet.
All the above is handled by Internet Protocol not TCP.. i.e IP gets the data to where it need to go TCPUDP ensure the data is recieved correctly
TheExcession said:
On a slightly more technical note, when my browser wants to down load a page from PH, it has to first establish a connection to the PH Web Server. It does this using a protocol called TCP (Transport Control Protocol)
So TCP consists of a number of messages going backward and forwards between the browser and the web server
Another reason for TTL is to prevent the network filling up with lost packets - imagine a scenario where a request is sent out but somewhere in the Internet a router doesn't know where to deliver it to? If packets did not have a TTL then eventually all these lost packets would mount up and clog all the genuiine ones.
All the above is handled by Internet Protocol not TCP.. i.e IP gets the data to where it need to go TCPUDP ensure the data is recieved correctly
ThatPhilBrettGuy said:
...lots of good stuff...
There is a lot of fascinating research info about methods of tuning TCP to run over LFPs.
Hardware TCP ack accelerators are your current best friend.
Sorry have to disagree on that - most of the stuff we've seen are somewhat mickey mouse and certainly don't cope with enterprise needs or real bandwidth.
We've had real issues with LFPs (we've got loads of >10GB IP network connections of substantial distances (1000+km stuff) - including vast MPLS deployments - and the core problem is physics & the speed of light and the fact that our common protocols in use today were not designed for performance.
Some interesting stuff here :-
www.orbitaldata.com/news/media.php?m=053005
www.thinkingsecure.com/docs/TCPIP-Illustrated-1/tcp_fut.htm
Also with the industry work on WAFS people are beginning to try and work-around the issue as it applies to NFS & CIFS - but again even the best today only copes with <150 connections (whereas I need tens of 1,000s).
I can't remember the URL but there is a competition site somewhere for people to describe how fast & what they did/used to get high performance FTP over LFPs - you'd be surprised at what standard FTP tops out at and how it falls over....
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff