Difference between under-load and ping-pong

708 views
Skip to first unread message

materi...@gmail.com

unread,
Jan 9, 2014, 12:10:34 PM1/9/14
to sockperf...@googlegroups.com
Hi there!

I am currently using sockperf to, as you might guess, measure latency between two servers connected to a switch.  They are both on the same subnet, and both are full-duplex, 1 Gb connections.

I have done testing with UDP and TCP packets using ping-pong and under-load, and I have noticed something odd.  When using ping-pong, approximately 100% of my packets come back from the server.  Sounds good, looks good.  Awesome.  Now, when I use under-load mode, I only get about 1% of my packets back.  Uh....maybe not so good and awesome.

After doing some research, I came across this statement in the other discussion group:

"The point is that sockperf has 2 main modes: 1) ping-pong in which all packets are replied, and 2) under-load in which 1% (configurable) of the packets are replied. Since the replies are so rare, they have neglected effect on the 1 way load stream.  Still, they give us enough observations for valid performance numbers/statists."

Does this mean that under-load does not reply to all of the packets it receives, and therefore, gives a measure of the latency of client -> server only?  I was under the assumption that under-load does the same thing that ping-pong does, the only difference being that ping-pong waits for a reply before sending another packet, while under-load does not.

What should I do if I want to see RTT data with a heavy network load?  Set under-load to reply to all packets sent?  I'll be looking through the man page again, but just in case it's not there, does that make it a compile-time configuration?

Thanks for your time!  I apologize for the wordiness.

Avner BenHanoch

unread,
Jan 10, 2014, 3:47:07 AM1/10/14
to sockperf...@googlegroups.com
Hi materiam4st3r,

Your findings are correct and as you probably understood this behavior is by design and in purpose (and match sockperf's common usage).

This behavior does give you RTT data with a - one way - heavy network load (and if you want to increase the load use the --pps= OR --mps= command line switch).  Notice that sockperf always print the one way latency; however, the calculation is latency=RTT/2.  Hence, you can easily deduct the RTT value.

Now, In case you are interested in measuring RTT data with a - two ways - heavy network load (i.e., you want replies for 100% of your under-load packkets ), then you should simply specify in command line --reply-every=1.

If you want to have it compile time configurable, you can contribute an appropriate patch, I guess it needs to be arround configure.ac file.  Personally, I don't see much value in such patch since you have simple command line switch for this purpose.

Good luck,
Avner

--
You received this message because you are subscribed to the Google Groups "sockperf-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sockperf-discu...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

materi...@gmail.com

unread,
Jan 24, 2014, 1:10:00 PM1/24/14
to sockperf...@googlegroups.com
"sockperf always prints the one way latency" -- So, what am I seeing in both under-load and ping-pong when I look at the latency percentiles that are reported after the tests complete?  Are these one-way percentiles, with the average latency also being one-way, or are they Round-trip Time (RTT) percentiles with the average latency being a RTT measurement?  Does Ping-pong mode also display one-way latencies?

Avner Ben Hanoch

unread,
Jan 26, 2014, 4:06:02 AM1/26/14
to sockperf...@googlegroups.com

It is very hard to really measure the one way latency at microsecond or even sub-microsecond as sockperf need because you need to sync clocks between machines at that high level of accuracy.  Hence, the only thing that sockperf measures is RTT.

 

Everywhere you see latency in sockperf - the meaning is just RTT/2.

Avner

materi...@gmail.com

unread,
Jan 28, 2014, 10:34:04 AM1/28/14
to sockperf...@googlegroups.com, materi...@gmail.com
I think I have it now.  I just want to clarify that under-load is a measurement of latency that simulates a heavy, one-way load, while ping-pong measures......I guess......normal traffic by sending and receiving equal amounts of traffic?

I've tried making under-load reply to all packets sent, and it actually overloads the network buffers.  I'm dropping packets like crazy when I use under-load in this fashion, so I'm assuming that ping-pong is designed to measure two-way latency, while under-load is not.

I'm sorry if I'm going around in circles here.  I'm a software developer in a network engineer's shoes right now -_-'

Avner Ben Hanoch

unread,
Jan 28, 2014, 10:47:57 AM1/28/14
to sockperf...@googlegroups.com

Ping-pong is quite synthetic test in which there is only one packet on the wire and nothing is sent until a reply for this packet arrived.  This is far of normal traffic.

 

For achieving normal traffic use under-load and decrease the value in --pps (or --mps) to something that your network can carry.  You can use --reply-every=1 or whatever value that matches the pattern of “normal” traffic in your environment.

 

 

From: sockperf...@googlegroups.com [mailto:sockperf...@googlegroups.com] On Behalf Of materi...@gmail.com
Sent: Tuesday, January 28, 2014 17:34
To: sockperf...@googlegroups.com
Cc: materi...@gmail.com
Subject: Re: Difference between under-load and ping-pong

 

I think I have it now.  I just want to clarify that under-load is a measurement of latency that simulates a heavy, one-way load, while ping-pong measures......I guess......normal traffic by sending and receiving equal amounts of traffic?

--

Avner Ben Hanoch

unread,
Jan 28, 2014, 11:01:19 AM1/28/14
to sockperf...@googlegroups.com

For advanced users, you can “record” traffic in normal day in your environment using wireshark.

Then, you can use the playback option of sockperf to play it (after converting the packet headers to sockperf CSV playback format).

 

However, this is beyond what I can explain you at the moment. Sorry.

Reply all
Reply to author
Forward
0 new messages