Reputation: 41
I want to measure message latency and throughput for both TCP and UDP using C sockets. I am writing a client.c and server.c (Question 1: Do I have to?) that run on different servers to accomplish this. I have to take several measurements using different packet sizes and multiple trials and plot my results.
For message latency: Send a packet of varying size and measure the round trip time and divide by 2 to get latency. Question 2: I send a packet of size x, and then from server.c I send the packet back. So at the client I start the timer, send packet and then wait till I receive the packet then stop the timer. The timer/2 is my latency? What are the steps to go about measuring this?
For throughput: Question 3: How would I measure throughput of both? What are the steps to go about doing this?
Im a beginner to Unix socket programming in C so detail would be helpful, with emphasis on the bechnmarking aspect.
EDIT: I cannot use tools that already exist. I need to write my own.
Thanks!
Upvotes: 4
Views: 5850
Reputation: 5755
You might also be interested in this related question:"How to measure network performance (how to benchmark network protocol)".
Upvotes: 0
Reputation: 28180
There already exists a program called ttcp which test TCP and UDP performance:
DESCRIPTION
Ttcp times the transmission and reception of data between two systems using the UDP or TCP protocols.
It does not calculate latency, but you can take a look at the source code of that program to examine how it does other calculations. And you can also use that as either client or server in case you do not want to write both yourself.
Update: Other similar TCP test programs
as well as related programs
Upvotes: 1
Reputation: 12037
You may want to look at tools that already exist for this type of thing. Maybe D-ITG or iperf
combined with tcpdump
or wireshark
? Unless the intent is to learn more about socket programming itself.
Upvotes: 0
Reputation: 41222
Question 1: You probably can find existing test cases with some use of Google. But if there are special situations you need to deal with, then it probably makes sense to write your own so that you take that into account.
Question 2: Maybe there is an official definition of "latency" in terms of network operations, but I think what is really important is the round trip cost. So I would not divide by 2. The total round trip cost is what the user (client) experiences. That will be the latency they see.
Question 3: I think your plan of using differing packet sizes is good for measuring the throughput. There is another SO question related to this. I posted an answer to that question and provided some numbers from my own testing of UDP versus TCP. Those might be of interest as a "sanity" checkpoint.
Ah - I forgot one thing I was going to mention. If you write a really simple test case with UDP, it might be somewhat unrealistic. If you use UDP directly, you will need to add your own error handling, packet verification, etc. That will add cost. Ultimately, we find that UDP is faster in most situations for us because we have tailored it to our own use. But it certainly requires a LOT more code to get everything working correctly.
Upvotes: 1