Relative and Absolute TX Timing

Reference Documentation
Platform
Intel® PAC
Napatech SmartNIC
Content Type
Reference Information
Capture Software Version
Link™ Capture Software 12.10
Napatech Software Suite: Relative and Absolute TX Timing
Relative and Absolute TX Timing
Napatech Software Suite Documentation » Main Features

Introduction

An adapter is either in relative or absolute TX timing mode. When in relative TX timing mode, an adapter transmits packets such that the inter-frame gap (IFG) between pairs of packets is correct. When in absolute TX timing mode, the adapter transmits packets at the time stipulated by the time stamp in the packet descriptor.
When in relative TX timing mode, the IFG is most accurate but the (absolute) transmission time of a packet may be slightly off over time; whereas in absolute timing mode, the transmission time of a packet is most accurate over time but the IFG (between pairs of packets) may be slightly off.
The default
The default behavior is to run each adapter in relative timing mode.
Adapter support
Not all adapters support absolute timing mode, in which case the driver will return an error.
Setup
The TX timing mode is a static setting TxTiming defined in the ntservice.ini file for each adapter.
Selecting Relative TX timing mode
[Adapter0]
TxTiming=RELATIVE
Selecting Absolute TX timing mode
[Adapter0]
TxTiming=ABSOLUTE

Example

In the following example the difference between relative TX timing and absolute TX timing is described.
timing_mode.gif

The Goal

A number of equal size packets are transmitted with delta time X between each packet. This means that packet number 2 is transmitted after time X, packet number 3 is transmitted after time X*2 and so on. The interframe gap Z will be the same between each packet.
The above scenario is what is desired. But due to some unforseen events there is a slight delay before the third packet is transmitted.

Relative TX

When running in relative TX timing mode the adapter only looks at the difference between the timestamp in each packet (delta time X), thereby trying to keep the interframe gap constant. The figure shows that the delta time X1 between packet 2 and 3 is increased due to the delay. After packet 3, the following packets are again transmitted with delta time X between each packet.
As can be seen in the figure, the packets are not transmitted within the expected time frame.
How it works
The adapter transmits the first packet immediately. For the following packets, the adapter takes the timestamp from each packet and subtracts the timestamp from the previous packet to get the delta time X. A count down of the delta time is then started and when the count down reaches zero the packet is transmitted.

Absolute TX

When running in absolute TX timing mode the adapter looks at the packet timestamp. When transmitting the first packet the TxSetClock bit in the packet descriptor must be set. This causes the TX clock on the adapter to be synchronized with the packet timestamp. All packets are then transmitted based on their timestamp. In the figure, packet 3 is delayed and thereby not sent according to the timestamp. The difference from relative TX timing mode is that in absolute TX timing mode the adapter will try to reduce the interframe gap to send the packets a bit faster until the delay has been caught up and the packet timestamps are synchronized again.
As can be seen in the figure, the packets are transmitted within the expected time frame.
How it works
When transmitting the first packet the adapter will synchronize the TX clock with the timestamp in the packet. The following packets will be transmitted when the TX clock matches the timestamp in the packets. If the timestamp in the packet is behind the TX clock, the packet is transmitted immediately.
Note: If the packet contains a timestamp in the future, the packet will first be sent when to TX clock and the timestamp match. For example, if the TxSetClock has not been set in the descriptor of the first packet, the TX clock will be zero. Therefore, when trying to transmit a captured file with a current timestamp it could take several years before the TX clock will reach the level of the timestamp, and thereby several years before the packet is transmitted.

One TX Clock Per Port for Absolute TX Timing Mode

The adapter has one TX clock per port when using absolute TX timing mode. This means that it is possible to have different applications transmitting to different ports, but it is not possible to have different application transmitting to the same port. As all the applications transmitting to the same ports will synchronize the TX clock to the timestamp of the first packet, it is unpredictable what will happen.
How to use absolute TX timing
First a check must be made to see whether the absolute TX timing is supported by the adapter and whether it is enabled.
// Open the info stream to get the timestamp method.
if((status = NT_InfoOpen(&hInfo, "Info")) != 0) {
// Get the status code as text
NT_ExplainError(status, errorBuffer, sizeof(errorBuffer)-1);
fprintf(stderr, "NT_InfoOpen failed: %s", errorBuffer);
return status;
}
// Find the adapter on which the port is placed.
infoRead.cmd=NT_INFO_CMD_READ_PORT;
infoRead.u.port.portNo = txPort; // The transmit port
if((status = NT_InfoRead(hInfo, &infoRead)) != 0) {
// Get the status code as text
NT_ExplainError(status, errorBuffer, sizeof(errorBuffer)-1);
fprintf(stderr, "NT_InfoRead failed: %s", errorBuffer);
NT_InfoClose(hInfo);
return status;
}
txAdapter = infoRead.u.port.data.adapterNo;
// Get the timestamp method.
infoRead.cmd=NT_INFO_CMD_READ_ADAPTER_1;
infoRead.u.adapter_v1.adapterNo = txAdapter;
if((status = NT_InfoRead(hInfo, &infoRead)) != 0) {
// Get the status code as text
NT_ExplainError(status, errorBuffer, sizeof(errorBuffer)-1);
fprintf(stderr, "NT_InfoRead failed: %s", errorBuffer);
NT_InfoClose(hInfo);
return status;
}
TxTiming = infoRead.u.adapter_v1.data.txTiming;
switch(TxTiming) {
case NT_TX_TIMING_ABSOLUTE:
printf("Absolute TX timing is enabled\n");
break;
case NT_TX_TIMING_RELATIVE:
printf("Relative TX timing is enabled\n");
break;
case NT_TX_TIMING_UNSUPPORTED:
printf("Changing TX timing is not supported\n");
break;
}
Absolute or relative
if TxTiming == NT_TX_TIMING_ABSOLUTE then the Absolute TX timing mode is enabled.
Unsupported by the driver
If the NT_InfoRead returns the error NT_ERROR_NTAPI_INFO_INVALID_CMD it means that the driver does not support absolute TX timing mode. A driver update is needed.
Transmitting packets
When transmitting the packets, the following must be set in the packet descriptor:
  • Relative mode
    The first packet in a transmission must be transmitted with txnow=1 in order to synchronize the tx clock
    with the timestamp in the first packet.
  • Absolute mode
    The first packet in a transmission must be transmitted with txnow=0 and txsetclock=1 in order to synchronize
    the tx clock with the timestamp of the first packet.
The following code show how make the right setting and must must be included in the transmit loop.
if(firstPacket == 0) {
if (txTiming == NT_TX_TIMING_ABSOLUTE) {
// Use absolute TX timing
// Set up the first packet to transmit. Only the first packet must be set up
// to Synchronize the TX clock. TXNOW must be set to 0 for absolute TX timing
// to work. The default is 0.
NT_NET_SET_PKT_TXNOW((&pktNetBuf), 0); // Waits for TX delay before the packet is sent
NT_NET_SET_PKT_TXSETCLOCK((&pktNetBuf), 1); // Synchronizes TX clock to timestamp in the first packet
}
else {
// Use Legacy mode/Relative TX timing
// First packet must be sent with txnow=1
NT_NET_SET_PKT_TXNOW((&pktNetBuf), 1);
}
firstPacket = 1;
}
Failing to synchronize the transmit clock can cause packets to stay in the transmit queue.
At startup the TX clock is by default 0. A newly captured file will have a timestamp with
a time from the year 2012. Due to the timestamp format, a time of 0 will represent a time from 1970.
This means that it will take approximately 42 years before the packet will be transmitted.

In-Line Adapters

For various in-line scenarios, it can sometimes be difficult to implement the above code example.
In-line packets will flow as soon as a filter is set up. This means that packets received will
be returned and transmitted on the TX port stated in the filter expression (see In-Line Real-Time Analysis),
even though no application is running. Subsequently it will not be possible to set the required bits in the
packet descriptor.
Setting the filer as:
assign[streamid=0;txport=0;txignore=false;txnow=true]=port==0
Does not cause any problems as "txnow=true" causes the driver to set the txnow bit in the descriptor by default.
This causes all packets to be transmitted immediately.
Setting the filer as:
assign[streamid=0;txport=0;txignore=false;txnow=false]=port==0
causes problems, as "txnow=false" causes the driver to clear the txnow bit in the descriptor by default.
This causes all packets to be transmitted according to the timestamp and can cause packets to wait for
42 years or more.
The following scenario works:
  • The RX stream is opened (NT_NetRxOpen).
  • The filter is set up "assign[streamid=0;txport=0;txignore=false;txnow=false]=port==0" (NT_NTPL).
  • The packets are requested (NT_NetRxGet).
  • In the first packet, the txnow=0 and txsetclock=1 in the descriptor is set to absolute mode.
  • In the first packet, the txnow=1 in the descriptor is set to absolute mode.
  • The packets are released (NT_NetRxRelease).
The following scenario will not work:
  • The filter is setup "assign[streamid=0;txport=0;txignore=false;txnow=false]=port==0" (NT_NTPL).
  • The RX stream is opened (NT_NetRxOpen).
  • The packets are requested (NT_NetRxGet).
  • In the first packet, the txnow=0 and txsetclock=1 in the descriptor are set to absolute mode.
  • In the first packet, the txnow=1 in the descriptor is set to absolute mode.
  • The packets are released (NT_NetRxRelease).
The filter command will cause packets to be return before the RX stream is opened and as "txnow=false"
is used, the packets will wait until the TX time matches that of the packet timestamp.
Maximum interframe gap
In order to prevent packets from hanging due to the above scenario, the maximum interframe gap is set to
2.6 seconds by default for in-line adapters. This means that the maximum time between two packets is
2.6 seconds. If a greater time is needed, the maximum interframe gap can be changed by using the NT_ConfigWrite
function with the command NT_CONFIG_PARM_PORT_COMPAT_1.
// Start by reading the current settings in order to do a read/modify/write.
configInfo.parm = NT_CONFIG_PARM_PORT_SETTINGS_V1;
configInfo.u.portSettings.portNo = port;
status = NT_ConfigRead(hConfig, &configInfo);
if (status != 0) {
NT_ExplainError(status, errBuf, sizeof(errBuf));
fprintf(stderr, ">>> Error: NT_ConfigRead failed. Code 0x%08X = %s\n", status, errBuf);
NT_ConfigClose(hConfig);
return status;
}
configSettings.u.portSettings.data.maxIFG = ifgmax;
configSettings.u.portSettings.data.minIFG = ifgmin;
// Write the settings
configSettings.parm = NT_CONFIG_PARM_PORT_SETTINGS_V1;
if ((status = NT_ConfigWrite(hConfig, &configSettings)) != 0) {
NT_ExplainError(status, errBuf, sizeof(errBuf));
fprintf(stderr, ">>> Error: NT_ConfigWrite failed. Code 0x%08X = %s\n", status, errBuf);
NT_ConfigClose(hConfig);
return status;
}

Transmitting to one port from multiple applications using absolute TX timing

It is not possible to transmit from multiple applications to one port if the timestamp or interframe gap
has to be preserved. Doing this can cause unpredictable behaviour and a very slow transfer rate.
In the following 2 examples we have 2 apps APP1 and APP2 transmitting each a file containing 4 packets.
apps.gif
In example 1 APP1 is starting to transmit and then APP2.
txexample1.gif
The first two packets from APP1 are transmitted according to the timestamp due to APP1 syncing the txclock.
When APP2 starts to transmit it is also syncing the txclock and overwrites the sync done by APP1. The result
is that all packets sent from APP1 will have a timestamp that is behind the txclock and will be transmitted
immediately. Packets transmitted from APP2 will be transmitted according to the timestamp.
In example 2 APP2 is starting to transmit and then APP1.
txexample2.gif
The first two packets from APP2 are transmitted according to timestamp due to APP2 syncing the txclock.
When APP1 starts to transmit it is also syncing the txclock and overwrites the sync done by APP2.
The difference from example 1 is that APP1 is setting the txclock back in time. Depending on the difference
in the timestamp a huge delay can occur. For example if APP2 transmits a file recorded one day in 2012 and
APP1 transmits a file recorded one day in 2010. The difference in timestamps will be about 2 years and the delay
that will occur will also be about 2 years.
Note: When transmitting from multiple applications TXNOW must always be used to prevent the above
described senarios.
NT_NET_SET_PKT_TXNOW((&pktNetBuf), 1);

Transmitting to one port from multiple applications using relative TX timing

The same problem as described above does also apply to relative TX timing. The result here
will be a very slow transfer rate.

Source Code Examples

Examples of using absolute and relative TX timing mode can be found here:
net/transmit/transmit_example.c
net/transmitSegment/transmitSegment_example.c
net/replay/replay_example.c