Network Interface Controller Noise

Characterising a network card requires to have a local reference clock to assess its performance, a setup rarely available. This page collects performance results of network cards we have tested on our testbed.

The need for a good network card

For most configurations, network delay jitter is the first cause of variability that challenges a synchronisation algorithm. In more specific situations it may not be the main cause of variability, if for example:

the reference server is on the LAN
the reference server is of good quality (stratum 1 or 2)
there is (almost) no congestion on the network

In this case, the characteristic of the network card used may dominate the noise seen by the synchronisation algorithm and become a limiting factor. While the RADclock is robust to all causes of noise, better performance can be achieved by choosing a good network card.

Characterisation

The methodology used is described in more detais in our "A Methodology for Clock Benchmarking" paper. Here, and because the host clock is not trusted, the NIC performance is reliably measured as the sum of the two one-way delays (also called RTThost) between the host and the DAG card as described in this figure.

Synchronisation packets are exchanged between the client hosting the NIC under test and an NTP Stratum-1 server. Packets are tapped by an Endace DAG card via a 100Mbps hub. The DAG card is synchronised by the PPS signal derived from our GPS locked PRS-10 Rubidium oscillator and is an independent time reference here. The DAG card create hardware timestamps that are then extremely reliable.

On the client side, packets are timestamped in the kernel. Thanks to the small time scale of operations, the RADclock difference clock can be used and the RTT at the host can be measured with an accuracy way better than 1 micro-second. The RTThost is computed by subtracting the RTT seen by DAG from the RTT seen by the host.

Limits to the methodology

We deliberately choose to show NIC performance as part of the computer as a system. Consequently, some external parameters affect the results shown in here and their interpretation.

Because the absolute host clock is not trusted, the characteristic does not distinguish between the sending and receiving direction.
The load on the network and at the host may hide the NIC performance. We tried to keep these two as low as possible in the results presented.
Time (in seconds) is the common unit required to compare against the DAG (and not CPU cycles for example). The results depend on the CPU clock speed.
The operating system and version, the NIC driver implementation, the packet timestamping architecture, etc.

We provide details on the measurement conditions to help the interpretation of the distribution of RTThost (a.k.a. NIC noise) shown below. Note, the histograms have been normalised and show the distribution from the minimum to the 99th percentile.