Introduction

ByteBlower allows performing both latency measurements and out-of-sequence detection on a stream of traffic.

This guide will show you how to set up such a scenario using the ByteBlower API and how to retrieve and interpret the results.

Using the ByteBlower lower-layer API

We start by setting up a normal frame blasting scenario.

For this post, we assume we have created a back-to-back scenario with:

• two configured ByteBlower ports srcPort and dstPort
• a valid byteframe byteFrame that will be sent between the two

Setting up the TX side

Latency and out-of-sequence measurements work by inserting FrameTags into the network packet.

Such tags are applied to a Frame object, which is itself part of a traffic stream (Tx.Stream). First we set up these objects:

Tcl

set stream [ $srcPrt Tx.Stream.Add ]
set frame [ $stream Frame.Add ]
$frame Bytes.Set $byteFrame

Then we enable one or more tags on the frame object:

• For latency measurements, we enable the time tag of the frame which contains a timestamp.
• For out-of-sequence measurements, we enable the sequence tag which contains a sequence number.
• Note that both tags can be enabled simultaneously!

Tcl

set timetag [ $frame FrameTag.Time.Get ]
$timetag Enable
set sequencetag [ $frame FrameTag.Sequence.Get ]
$sequencetag Enable

Now every frame sent by the server will contain the enabled tags.

The structure of these tags and their position within the frame may depend on the ByteBlower server type and which other tags are enabled.

By default, the ByteBlower server will place the tags automatically at an optimal position. For a background post about what actually happens when enabling frame tags and how to configure the tag properties, see XXX.

Setting up the RX side

At the receiving ByteBlower port, we need to add an incoming packet processor.

• For latency measurements, two types of processors exist: 
  • Rx.Latency.Basic (default) which calculates the minimal, average and maximum latency and the jitter
  • Rx.Latency.Distribution which creates a latency histogram
• For out-of-sequence detection a single processor exists:
  • Rx.OutOfSequence.Basic which calculates the number of frames that arrived out of order

We add such incoming packet processors to the receiving port.

Tcl

set latencyProcessor [ $dstPort Rx.Latency.Add basic ]
set latencyDistProcessor [ $dstPort Rx.Latency.Add distribution ]
set outofsequenceProcessor [ $dstPort Rx.OutOfSequence.Add ] 

The receiving side must know what tag to look for and where within the frame it can be found. Note that the receiving port may be located on another server and even on a server of a different type!

That is why we always pass the TX frametag information to the RX side in our client script. This will correctly set up the receiving side.

Tcl

$latencyProcessor FrameTag.Set [ $frame FrameTag.Time.Get ]
$latencyDistProcessor FrameTag.Set [ $frame FrameTag.Time.Get ]
$outofsequenceProcessor FrameTag.Set [ $frame FrameTag.Sequence.Get ]

Now we are ready to begin sending the traffic! If the frame tag properties of the transmitting and receiving servers are not compatible, an error will be shown at runtime.

Interpreting the results

After the scenario is finished, we can query the incoming packet processors their result values. The structure of this result depends on the type of incoming packet processor. This is done by calling the following methods:

Tcl

% puts $latencyProcessor Counters.Get
NrOfFrames 20 MinLatency 62 AvgLatency 63 MaxLatency 69 Jitter 1

% puts $latencyDistProcessor Counters.Get
[0 - 1000[ us} 56 {[1000 - 2000[ us} 23 {[2000 - 3000[ us} 4 ... {[998000 - 999000[ us} 0 {[999000 - 1000000[ us} 0 {< 0 us} 0 {> 1000000 us} 0

% puts $outofsequenceProcessor Counter.Get
FramesOutOfSequence 0 NrOfFrames 100

We can just print these counters or process them further, based on our scenario.

Using the ByteBlower higher-layer API

For simple tests, using the higher-layer API simplifies the configuration significantly.

Scenario configuration

todo

Interpreting the results

todo