I understand that there are queuing delays and processing delays prior to sending out a packets. However, do you measure those delays in linux or specifically ubuntu?

  • You can ping a remote host (on your LAN if possible). Each reply line shows the time, and when ending the rtt min/max/average and so on. Of course, it measure also the network latency, but this is probably the simplest idea. – Pyrophorus Oct 9 '14 at 15:30
  • Hi Pyrophorus, but it doesn't show me TCP queuing delays where pinging takes into the RTT + queuing delay + process delay. I'm trying to find out the queuing delay and process delay. Any help would be greatly appreciated. – momododo Oct 10 '14 at 15:52

It's difficult to reply anything accurate. First of all because TCP packets makes no sense. TCP implements a continuous data flow over IP, so a program using a TCP connection will have to:

  1. Elaborate the data and write it to the TCP socket. Maybe this is what you mean by "process delay".
  2. Optionally, something like SSL can process the data (encryption, VPN)
  3. The data is passed to the IP protocol which slices the stream, creating packets.
  4. The packets are routed/masqueraded at need.
  5. The packets are encapsulated in Ethernet packets (most of time).
  6. The Ethernet packets are sent, and maybe with some random delay (network congestion).

On each layer of the TCP/IP stack, delays can occur (and I said nothing about error recovery). This imply you should be more accurate about which delay you want to measure. Maybe some tool like wireshark or tcpdump will help you, maybe not.

Reading your last comment,it's more clear you're investigating on application level. A profiling tool should help you then. Most IDE have one, but... the profiling itself introduces some overhead ! :-)

  • Yes, the processing delay is what you mention in point 1, but how do you measure that? Also, the queuing delay refers to the time spent in the queue waiting to be written to the TCP socket, are there ways to measure that? – momododo Oct 11 '14 at 14:50
  • @Pyrophorus I hope your understanding of the network stack has improved in the last 3 years. IP has no stream interface, so it is TCP that packetizes the stream into IP packets. These packets are marked in such a way that they can be identified as TCP data, so it should be quite possible to tell what IP packets are awaiting transmit that contain TCP data. – kfsone Jul 4 '17 at 0:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.