A crucial aspect of running and maintaining a network is achieving optimal performance. In the context of network monitoring, performance can be linked to the concept of latency, referring to the speed of the network or the Remote Response time. Apart from the processing time needed for any network application service to process a request, there is a delay involved for the request to reach the service. While referring to latency, it’s that delay we are talking about.
Fig 1. In network monitoring, performance can be linked to the concept of latency, referring to the speed of the network or the Remote Response time.
This becomes a big issue for industrial control systems (ICS) with remote locations. Imagine a manufacturing center in the US accessing a data center in Europe. If ignored, latency can trigger the service level agreements (SLAs) violation. In other words: losing access to data and cloud-based applications for even a few minutes at a time can cost company productivity, lost revenue opportunities, and brand damage.
Even though it can be quite difficult to improve latency, it’s important to precisely measure it with purpose-built solutions. The ability to timestamp packets with high accuracy when monitoring is therefore essential for understanding what is going on in the network at a packet level. Accurate time information is important for legal and criminal investigation, and the same applies for accurate forensic analysis and performance testing to measure crucial indicators like latency.
A timestamp is a sequence of characters that can help you identify when a certain event occurred, by giving you the actual date and time of day, sometimes accurate to a small fraction of a second. Timestamps are added as information to the header of each packet, that in turn can be interpreted by an analyzer such as IOTA or Wireshark. In a nutshell, a timestamp is a record of the time at which a packet was received and processed through your network access device.
When starting to analyze packets, an important requirement is knowing the exact date and time they were captured with the highest possible accuracy and resolution. This can be especially important in many applications and situations where different time zones are involved, such as compliance, troubleshooting, capacity planning, intrusion detection and prevention of cyberattacks, and so on. This ensures packets contain the actual time of their occurrence over the network.
3 methods to run a timestamp analysis with IOTA plus
As mentioned before, timestamping is an important tool when analyzing network traffic. But what equipment can you use for this type of analysis? Here we’ll discuss the IOTA series, which offers several timestamping options.
All IOTA models are able to timestamp ingress frames using a hardware time counter. The time counter has a resolution of <10 ns, the resolution depends on the device and feature: 8 ns for the 1G and 1G+, 6.4 ns for the 10G, and 5 ns for the 10G+.
We will go through 3 methods to synchronize 2 IOTA devices: with one GPS signal, with 2 GPS signals, and without GPS signals.
Fig. 2 On premise monitoring or remotely in different timezones with IOTA
Method 1: relying on 1 GPS signal
Let’s get started with two key definitions: Time initialization means taking a timestamp from a source. It happens once during IOTA boot time. Counter disciplining means synchronizing the counter speed to an external source. This happens every second during IOTA operation.
Fig 3. Method 1: relying on 1 GPS signal.
IOTA 1's time is initialized from the GPS signal, and the timestamp counter is disciplined from the GPS. In this case, IOTA 1 is the "main" device, disciplining IOTA 2.
IOTA 2 uses its own system time (set either via NTP or manually), while the timestamp counter is disciplined from external PPS (from IOTA 1).
For this method, it is important that IOTA 2's system time be within 0.5 s of UTC global time.
If IOTA 2's system time has an offset greater than 0.5 s, this may induce a constant time offset between IOTA 1 and IOTA 2 (aligned to whole seconds, like 1 s, 2 s, etc).
Method 2: relying on 2 GPS signals
Fig 4. Method 2: relying on 2 GPS signals.
Times are initialized from GPS and timestamp counters are disciplined from GPS.
In this case, both IOTAs rely on GPS signals in both taking timestamps and disciplining. Therefore, both IOTAs will have valid absolute UTC-aligned timestamps.
Method 3: no GPS signal
Fig 5. Method 3: No GPS signal.
To synchronize two IOTAs together (not to UTC) without GPS signal, both IOTAs use their own system time for timestamping (the generic "0.5 seconds difference" rule also applies here). IOTA 1 generates a PPS signal and forwards it to IOTA 2 through a PPS cable.
Alternatively, an external PPS source provides PPS to both IOTAs.
