Hi,
I'm trying to run rtiperftest latency test with multiple subscribers. And I read the C++ source code:
I noticed the publisher only sends latency samples to one of the multiple subscribers. I wonder is there any way to measure the overall latency of 1-n communication rather than the 1-1 latency.
Thanks,
Zhuangwei
No, RTI Perftest isn't designed to measure that. Actually, it's quite hard to measure a one-way 1-N latency. What's the definition...when the all N subscribers have received the data? Also, since it's impossible to measure 1-way latency without synchronized clocks (down to the usec), you have to measure 2-way latency, which assume symmetric operations for sending and processing both the "ping" and "pong" packets. Which means the publisher needs to receive N "pongs" to its "ping"...and then the time to receive N "pongs" is not an accurate measure of 1-way latency...can't just divide by 2...since a single application on a single host is now has to process N "pongs" which will artificially increase the round trip time reported by the Nth "pong" since has to wait for the first N-1 "pongs" to be processed in a single threaded manner.
Which is why the way that RTI Perftest is designed to measure 1-N latency actually is probably a more accurate way to measure the average one-way latency in a 1 pub, N sub situation. So RTI Perftest basically selects the Nth subscriber to send back a single "pong". This avoids artificially increasing the latency with having resource contention to process multiple "pongs".
Thank you very much for answering my question. The explanation makes sense to me.
If you have access to test equipment (such as an oscilloscope or logic analyzer) and are willing to write a small application, then the one-way latency of a 1-to-many system could be measured.
For example, a Raspberry Pi has GPIO pins that can be set high or low by software in under a microsecond, so an application (pair) could be written to run on a group of rPi's that:
Publisher: Sets a GPIO pin HIGH, then publishes a DDS sample, then clears the GPIO pin LOW, then delays for the next test interval.
Subscriber: When a DDS sample is received, it sets a GPIO pin HIGH (in the callback or after the waitset), then later clears the pin LOW.
Using an oscilloscope or logic analyzer to monitor the GPIO pins on the separate boards would produce a reasonably-accurate measurement of one-way latency, just be mindful of the potential sources of jitter and inaccuracy (as in: measure the latency and jitter of setting a GPIO pin -- although it seems to be pretty fast, depending on how you do it (this test produced square waves up to 22MHz on the original ARM11-based raspberry pi)).
Hope this helps!