I want to measure performance of the network, especially latency. We are performing stress tests of a system that sends live audio / video data over the network. When there are multiple simultaneous connections (e.g. 100 connections) we are observing that it takes too long for the data to be sent from one party to the second party. Currently, I don't know if it is because of server performance or it is a network issue.

Server load is really low (about 15% cpu load), however it could still be server issue because of threads context switching and it is possible that data waits for the server to begin processing. My setup is as follows:

Client -> Load balancer -> Proxy Server -> Application Server -> Agent

I want to measure how long it takes for the data to be sent between every two elements (omitting only Load balancer), e.g. between Client and Proxy Server.

Servers are Windows Server 2008R2, client and agent are Windows XP/7.

I thought that I could install wireshark on every machine, synchronize clocks and manually check packets captured on every machine. However, I hope there is a better solution.

  • TCP or UDP? Is the server agent using sockets, or some kind of web service? – Greg Askew Apr 22 '13 at 17:17
  • @GregAskew: I want to measure raw data over TCP connections. – empi Apr 22 '13 at 17:19

Psping from Russinovich does ICMP ping, TCP ping, bandwidth testing, and more.


It has a server component and a client component so you have to run it in both machines for the more advanced tests.

  • Nice tool, I think I will give it a try! – empi Apr 22 '13 at 17:24
  • a few others = iperf/jperf and Qcheck, but tool/software recommendations are usually off-topic so you didn't hear that from me. – TheCleaner Apr 22 '13 at 17:29
  • Requests for recommendations of products are off topic, but saying what tool to use, particularly generic ones, surely is on topic, else most of the content here will have to go. – dunxd Apr 23 '13 at 13:49

Wireshark could be useful for spot-checking one or two stations that are exhibiting symptoms. It has an excellent Round-Trip-Time (RTT) graph capability. If you are actually losing packets, you would need more than that, you would need to perform a correlated capture - one on each side, and identify where a packet may be sent but not received, or something else like retransmits. You would also want to determine if there are a lot of retransmits occurring.

If you are sending a lot of small TCP packets, it may be possible that you are encountering the 200 ms default delayed acknowledgement. If the symptom is reproducible, it may show up in a packet capture as 200 ms gaps between packets and the corresponding ACKs.


  • Didn't know about RTT capability - I will definitely check it. – empi Apr 22 '13 at 19:57

Wireshark seems overkill if you are just testing the network. ping would work, at its simplest just running a set number of pings during your test and then analysing the results, or going a bit futher writing a small programme that runs the test on a schedule and then saves the data into a CSV file. You could run this between any two nodes on your network you want to test latency between.

If you are looking for total latency for the programme then you will need something different.

I wouldn't trust wireshark and synced clocks to test this, since you will be looking for milisecond differences that may not show up accurately between two different hosts on the same network.

  • The problem with ping is that it uses completely different protocol. I think that there may be some QoS rules set up in the network that affect the performance. – empi Apr 22 '13 at 17:21

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.