Understanding Perftest Instantaneous Throughput results.

3 posts / 0 new
Last post
Last seen: 5 years 6 months ago
Joined: 10/24/2013
Posts: 15
Understanding Perftest Instantaneous Throughput results.


I have trouble understanding the instantaneous perftest  throughput output on the subscriber side.

If I start the publisher with the following:

perftest_cpp -pub -numIter 100000 -latencyCount 100

(It will send a latency ping after every 100 samples)

On the subscriber  side I see the following output:

Packets:    38250  Packets/s:   18540 
Packets:    58011  Packets/s:   19757  (packet difference 58011 - (38250+19757) =  4)
Packets:    77744  Packets/s:   19730  (packet difference 77744 - (19730 + 58011) = 3)
Packets:    97000  Packets/s:   19252  (packet difference 97000 - (77744 + 19252) =  4)

The subscriber only considers the samples received on the throughput topic( not considering the latency pings) to calculate the throughput. So the number of packets/s will signify the packets received on the throughput topic (excluding latency pings) and the Packets will signify total number of packets( including latency pings).

Why is there a variability in packet difference. It always varies to be either 3,2 or 4.

Shouldn't the packet difference be more? Since I am sending a latency ping every 100 samples,  approx. 200 ?

When I configure 100000 samples to be sent with -numIter, does this mean that a total of 100000 samples will be sent inclusive of the latency pings or does this mean that there will be 100000 samples + (100000/100 -1) latency pings being sent ?

Please guide me in this regard as it will help me in better understanding the throughput results.

thank you

Last seen: 5 years 9 months ago
Joined: 01/31/2011
Posts: 37

Hi Shweta,

Perftest works by having the publisher send data samples on the "Throughput" topic. Every so often, one of these samples will be tagged with timestamp information.  The Subscriber, upon receiving this tagged sample, will send the same data back on the "Latency" topic.  The publisher can use this reflected timestamp to then calculate latency by using the round trip time divided by 2. 

So when you configure perftest to send 100000 samples with the -numIter option, the publisher will send 100000 samples inclusive of latency pings because the publisher sends latency pings (aka "tagged samples") on the "Throughput" topic. The subscriber reports statistics on received data for all packets received on the Throughput topic. As you've noted, the rate at which the publisher sends these tagged samples is controlled by the -latencyCount option.

As for the math... that's likely caused by rounding errors.  If you look in the file perftest_cpp/perftest_cpp.cxx, in the function peftest_cpp::Subscriber(), around line 910, you'll see where we implement the logic to report packets received and packets/s.  There are three variables that matter:

  1. total packets received, which is "last_msgs" in the code
  2. actual packets received since the last print statement, which is "msgsent" in the code
  3. the number of microseconds that passed since the last print statement, which is "delta" in the code

The logic to determine the packets/s takes the number of messages sent in the last iteration, multiplies by 1000000, and divides by the actual observed delta (line 917):


Msgsent is an unsigned long long, and delta is an unsigned long long.  The delta from one print statement to the next isn't going to be exactly 1s (or 1000000 us).  The packet/s is therefore going to be truncated because the math is using integers, rather than double floating point.  You can verify for yourself by printing out the time delta and then calculating the math, keeping in mind that all variables are treated as integers.

Btw, if you'd like to learn more about perftest we have a free video available on our eLearning site: http://www.rti.com/elearning/.  Look for "Chapter 9: Measuring Performance with PerfTest Utility".


Last seen: 5 years 6 months ago
Joined: 10/24/2013
Posts: 15

Hi Sumeet,

Thank you for your reply. It was very helpful!