Flex your time-sensitive networking (TSN) conformance testing
2021-05-06 | 5 min read
Many times, my customers tell me that validating time-sensitive networking (TSN) is a big challenge. The technology is not only complex, but also under-development implementations create a big pain for the test engineers. Until last week, I believed that the Ixia TSN conformance package provided the best of coverage and pinpoint measurements of TSN characteristics of a device. One of my old friends called and sounded frustrated. Roger works in the testing team of a well-known silicon vendor who is working on system on chip (SoC) implementing TSN – specifically time-aware shaper (IEEE 802.1Qbv). Roger was working on an early development build for validating the Qbv gate open and close accuracy of the SoC. “These developers think they can provide any half-cooked implementation as a QA drop,” he said. “They don’t understand how difficult it is to validate with all those hacks being present !!”
It took a couple of large cappuccinos to calm him down when he visited my place that evening. What came out is that the developers wanted to leave certain debugging logs in their code to track gate open and gate close event. As a result, the code path was slowed down, and the gate opening was delayed by a few microseconds every time a Qbv schedule started. Roger was using Ixia TSN conformance benchmark tests to validate the gate open time and the tests were all failing. The development team wanted Roger to adjust his tests to account for this delay and still validate the functionality. Roger was at a loss how to do that with the benchmarked tests and his manager was breathing down his neck.
“Ah..haa!,” I said. “I know exactly what you need – it’s the IxNetwork 9.0 release.” IxNetwork 9.0 comes with the customized test scenario feature for TSN conformance, so I was able to show Roger how easy it is to solve his problem.
Instead of using a benchmarked test, one can use the custom test case feature to generate a scenario to suit the need. The custom test generation workflow provides options to choose different basic and advanced scenarios – like the one shown in the screenshot below. For Roger’s case he needed to select the “Gate Scheduling” scenario.
The test case gets generated at one press of a button and it allows the user to change any test parameter or test logic.
Roger made a couple of quick fixes in this custom-generated test to make things work:
- He changed the txDelayList parameters to adjust for the delay caused by the debugging logs. As a result, the test tool was generating traffic after the adjusted delay period. The debugging logs were introducing a delay of 5 microseconds. So, his changed values were:
From txDelayList = [ 0, 250000, 500000, 750000]
To txDelayList = [ 5000, 255000, 505000, 755000 ]
- Alternatively, he could also make a change in the test logic to account for the packet drops caused by the delayed gate open. Roger accounted for the packet loss in the validating function by changing the parameters like:
TSNConf_ValidateLoss ([10,10,10,10], config, logger)
The next day when Roger called, he was very happy – not only because his problem was solved but also because these changes were so simple, he could finish his tasks earlier than his manager expected.
Read more about Ixia’s audio/video bridging (AVB) and TSN test solution.