Latency / Jitter Explained
The architecture of the Chimera delay block puts certain limits on the minimum and maximum latency that can be configured in the latency / jitter impairment described in section 10.6.
This section describes these limits, along with timing configuration parameters and the timing accuracy that can be expected from the latency / jitter impairment, depending on the configuration. Besides the latency of the active emulator core described in this section, notice the emulator bypass mode described in section 3.2.
The minimum latency that can be configured for any latency distribution is described in Section Minimal Latency. Regarding the maximum latency that can be configured for any latency distribution, there are two limits to be aware of:
Lossless Latency:
The maximum latency that can be guaranteed without the risk of packet loss at wire speed.
Lossy Latency (Reduced Bandwidth Latency):
The maximum latency supported by Chimera. At this latency, there will be loss at wire speed. It is possible to calculate a reduced BW which can be supported without loss. Sending packets at a higher bandwidth than the guaranteed BW will eventually result in packet loss. See Section Maximum latency (Reduced Bandwidth Latency) for details on reduced BW.
When configuring a latency distribution, it is possible to configure the maximum delay to the lossy latency limit. However, when configuring a maximum above the lossless latency limit, sending packets at a higher BW than the guaranteed reduced rate may result in packets being lost.
Maximum Lossless Latency is described in Section Maximum Latency (without packet loss), while Reduced Bandwidth Latency is described in Section Maximum latency (Reduced Bandwidth Latency). Finally, Section Latency and Multiple Flows describes the latency / jitter accuracy that can be expected depending on configuration.
Extended Timing Mode
The latency / jitter impairment can operate in either “Normal Timing Mode” or “Extended Timing Mode”. Normal timing mode will allow high precision latency and jitter, with a maximum configurable latency of 1.9 sec.
Extended timing mode allows configuring latencies up to 19.5 sec. at the expense of the latency and jitter precision. The minimum configurable latency is unaffected by the setting of extended timing mode.
The timing mode is configured at the module level as illustrated in Fig. 196, and will apply to the entire Chimera module.
Fig. 196 Configuring Extended Timing Mode
Note
Changing the timing mode will reset all configured latency / jitter parameters in the entire module to default values, including those configured for custom distributions. Hence, modifying the timing mode will require all timing values in the module to be reconfigured.
To configure extended timing mode:
Go to the tab and select the required timing mode (e.g. off).
This will set the extended timing mode to off and cause all timing parameters in the module to be reset to default values.
Due to decreased latency / jitter precision, it is recommended that users enable extended timing mode only when the increased maximum delay is required for your testing.
Note
Corresponding CLI command: M_LATENCYMODE
Minimal Latency
Chimera supports the following minimum latency (intrinsic latency) depending on port speed:
Port Speed |
Minimum Latency |
|---|---|
8 x 10G (no RS-FEC) |
13 µs (13,000 ns) |
8 x 25G |
7.3 µs (7,300 ns) |
2 x 40G (no RS-FEC) |
7.1 µs (7,100 ns) |
4 x 50G (no RS-FEC) |
7.1 µs (7,100 ns) |
2 x 100G |
7.1 µs (7,100 ns) |
The minimum latency is significantly increased for 10G due to the store and forward delay of a 10K Ethernet packet at 10G. Notice that the minimum latency is unaffected by the setting of the timing mode described in Section Extended Timing Mode.
Maximum Latency (without packet loss)
Due to the amount of memory needed to support latency, there is an upper limit to the latency which can be supported without loss. The maximum latency without loss which can be configured for a flow depends on the number of ports and flows currently active on the port.
Port Speed |
1 active flow |
2 active flows |
3-4 active flows |
5-8 active flows |
|---|---|---|---|---|
8 x 10G (no RS-FEC) |
1,990 ms |
995 ms |
497 ms |
248 ms |
8 x 25G |
796 ms |
398 ms |
199 ms |
99 ms |
2 x 40G (no RS-FEC) |
497 ms |
248 ms |
124 ms |
62 ms |
4 x 50G (no RS-FEC) |
398 ms |
199 ms |
99 ms |
49 ms |
2 x 100G |
199 ms |
99 ms |
49 ms |
24 ms |
Port Speed |
1 active flow |
2 active flows |
3-4 active flows |
5-8 active flows |
|---|---|---|---|---|
8 x 10G (no RS-FEC) |
3,990 ms |
1,995 ms |
997 ms |
498 ms |
8 x 25G |
1,596 ms |
798 ms |
399 ms |
199 ms |
2 x 40G (no RS-FEC) |
997 ms |
498 ms |
249 ms |
124 ms |
4 x 50G (no RS-FEC) |
798 ms |
399 ms |
199 ms |
99 ms |
2 x 100G |
399 ms |
199 ms |
99 ms |
49 ms |
The total amount of latency / jitter memory inside Chimera is constant. This memory is divided equally between the active flows, as is reflected in Table 64 and Table 65, which illustrates how the maximum lossless delay depends on the number of active flows.
The distribution of memory among active flows mentioned above, requires re-allocating the memory, when the number of active flows is modified. If traffic is running through the filters, when memory is re-allocated, packets will be lost on all active flows.
To avoid packet loss due to memory re-allocation, enable all required filters, before starting the traffic. Subsequently modifying the filters will not result in any packet loss.
Maximum latency (Reduced Bandwidth Latency)
Chimera supports latencies above what is listed in Table 64 and Table 65, but in such cases, it can only be guaranteed to be lossless at a reduced bandwidth given by:
ReducedBW(Gb/s)=(LossLessLatency*Speed(Gb/s))/ConfiguredLatency
where the LosslessLatency is taken from Table 64 and Table 65, and ConfiguredLatency is the latency currently configured for the flow (> LosslessLatency).
In case the average data rate on the flow exceeds the reduced bandwidth, packets will be dropped.
The maximum latency which can be configured for reduced bandwidth = 1.9 sec (normal timing mode) / 19.5 sec. (extended timing mode). See Section Extended Timing Mode for details.
Latency and Multiple Flows
When only the default flow is configured on a port, the uncertainty on the configured latency is +/- 50 ns.
When multiple flows are configured on a port, there will be an added latency due to the fact that packets from multiple flows need to be merged onto the same physical link at the Chimera output port. This is a basic property of Ethernet. In this case, the added latency will depend on the number of flows configured on the port and the maximum packet size on the active flows.
When adding a 2nd flow (flow #1) to the port, the packets of the default flow risk waiting to be merged into the common output packet stream due to transmission of a packet on flow #1. Worst case, this is a maximum size packet (= 10K bytes), in which case 802 ns (for 100 G) will be added to the latency of the packet of the default flow (see Table 66).
For every flow added to the port, the packets of a given flow risk waiting another maximum packet size to be merged at the output. The influence of the multiple flows is very random, but worst case, a packet scheduled to be sent on a port with 8 flows configured will experience an increased delay of 7 x maximum packet delay. The worst case added latencies in cases with 8 flows on a port are listed in Table 66.
Speed |
Delay of 10K pkt (ns) |
Max added delay (ns) |
|---|---|---|
100G |
802 |
5,600 |
50G |
1,603 |
11,200 |
40G |
2,004 |
14,000 |
25G |
3,206 |
22,400 |
10G |
8,016 |
56,100 |