USB4 Alt-Mode Testing: DPAUX and USB-PD

Figure 1: The interfaces that make up the USB-C connector and their relationships.

The USB Type-C® (USB-C) connector supports not only USB data transfers at speeds of up to 20 Gb/s but also can be reconfigured to support a wide variety of other interfaces through the USB4 provision for alternative (Alt) modes. The Alt-Mode protocols supported include Thunderbolt™, Mobile High-Definition Link (MHL), Peripheral Component Interconnect Express (PCIe®), High-Definition Multimedia interface (HDMI®) and DisplayPort™ (DP).

The diagram of the USB-C receptacle in Figure 1 shows where it potentially switches from normal operation into Alt-Mode.

Testing DisplayPort 2.0 vs. USB4 Over USB Type-C Connectors

Figure 1: The pin out of the USB Type-C connector.

DisplayPort™ 2.0 (DP 2.0) is a high-resolution video interface and USB4® is a high-speed data interface; what they have in common is the USB Type-C® (USB-C) connector. While DP 2.0 can also be deployed on the standard DisplayPort as well as mini-DisplayPort connectors, it is the USB-C connector that really excites electronics manufacturers because now they can use a single connector for high-speed data, high-resolution video and even power distribution. 

Figure 1 shows the pin assignments for a USB-C connector, which is a mechanically reversible connector that includes four, high-speed differential data lines: TX1, TX2, RX1 and RX2.

In USB4 operations, the four data lines TX1, TX2, RX1 and RX2 form a dual-lane, duplex signal path, supporting 10 and 20 Gb/s transfers on each line. When operating in USB4 Alt mode, up-to-four of these buses can be reassigned to become four DP 2.0 video lanes, which operate at 10, 13.5 or 20 Gb/s.

Testing for both interfaces over the USB-C connector is similar, but there are some notable differences.

DisplayPort 2.0 Physical Layer Testing

Figure 1. Functional diagram of DisplayPort 2.0
over USB-C Source (Tx) PHY testing.

The Video Electronics Standards Association (VESA) DisplayPort 2.0 video interface introduces a new performance standard with an increase in data bandwidth of three times compared to the older DisplayPort 1.4a specification, achieved by using four lanes of  up-to-20 Gb/s data per lane. This permits display resolutions to better than 8K, higher refresh rates and better dynamic range. These advantages are available using native DisplayPort connectors as well as the USB Type-C connector, which allows devices to handle video data, USB data and power all in the same connector.

With the USB-C cable now carrying DisplayPort and lower-speed sideband data, testing for USB devices has expanded to cover many dependencies between these protocols. This series will give an overview DisplayPort 2.0 physical-layer testing and how it relates to USB testing.

What Is Differential Manchester Encoding?

Figure 1. Differential Manchester encoding is based on the
presence or absence of a transition, whereas Manchester 
encoding relies on the polarity of the transition.

Differential Manchester Encoding (DME) is an example of a differential, bi-phase encoding technology. DME is specified in the IEEE 802.5 standard for Token Ring local area network (LAN) topology. 

Manchester is categorized as bi-phase encoding because the signal is checked twice every bit interval, also called self-clocking. Each check is one “tick”, each bit interval equals two ticks of the clock. This removes the need for the separate clock signal that is required for Non-Return to Zero (NRZ) encoding. Instead, data and clock signals are combined into a single, two-level, self-synchronizing data stream. The clock can be "extracted" by measuring the timing of the edges.

Figure 2. In Manchester encoding, the polarity of the
transition that occurs mid-interval determines the logic.

In Manchester encoding, we see a digital modulation scheme where voltage transitions rather than voltage levels are used to represent 1s and 0s. In IEEE 802.3 Manchester, a low-to-high transition occurring in the middle of the bit interval represents logical 0, while a high-to-low transition represents logical 1 (the Thomas variant reverses this logic). Significant transitions always occur in the middle of the bit interval to ensure clock synchronization. Transitions at the start of a period are only used to reset the polarity to achieve the proper transition for the next bit. This increases error detection capabilities, compared to NRZ, but also increases the bandwidth needed to transmit the signal at the same data rate, making it a better candidate for short-distance applications.

Figure 3. Even inverted, DME signals result in same logic.

The most prominent feature that distinguishes DME from classic Manchester encoding is that, in DME only the presence or absence of a transition during the bit interval is important, not the polarity. The presence of a transition represents a logical 0, while the absence of a transition represents a logical 1. Whether the signal goes line-high or line-low depends simply on its state the previous bit interval. This increases bit rate at lower bandwidths, because one bit is guaranteed to occur every interval. It also helps with data recovery in noisy environments, like automotive, because DME allows for a data stream to be inverted, yet still be properly decoded, unlike classic Manchester where the polarity is significant. 

DME is used for 10Base-T1S Automotive Ethernet, a short-distance, low-bandwidth application with either a point-to-point or bus topology up to 25 m. 

Teledyne LeCroy offers QualiPHY compliance test solutions for 10Base-T1S, including a QPHY-10Base-T1-TDR option that automates all required MDI S-parameter tests using the WavePulser 40iX.

For more information about 10Base-T1S compliance testing, see the on-demand webinar, How to Become an Expert in Automotive Ethernet Testing, Part 1.

See also:

Automotive Ethernet MDI S-parameter Testing

Automotive Ethernet in the Vehicle

Fundamentals of Automotive Ethernet

Using Tracks to Demodulate Frequency/Phase Modulated Signals

Figure 1: A low-pass filtered track of the Frequency
measurement demodulates the linear frequency
sweep in a radar chirp. The frequency domain
FFT shows the range of the frequency change.

If you are involved in RF measurements, you will eventually need to demodulate a signal. Angle modulation of either phase or frequency are the most commonly encountered modulation types. The Frequency measurement is an all-instance timing parameter that measures the frequency of every cycle in an acquired waveform. Similarly, Time Interval Error (TIE) measures the instantaneous phase of a signal on a cycle-by-cycle basis. Track functions of these measurements, which plot the values of the measurement parameter versus time, are useful for demodulating frequency and phase modulated signals, as shown in the examples below.

Finding “Unknown” Waveform Anomalies

Figure 1: Width “exclusion” trigger captures
pulse widths outside the range of 980 ns to 1 µs.
The first anomaly captured is a width of 2.99 µs.

Using SmartTriggers® and statistics to find waveform anomalies is easy if you know the characteristics of the anomaly, but how do you find intermittent, anomalous events when you don’t know what you’re looking for? The answer: start with what you do know!  

Look for What’s “Not Normal”

A simple approach is to measure the nominal waveform, then trigger the oscilloscope on waveform elements that differ from nominal. Figure 1 shows a 500 kHz square wave with a roughly 50% duty cycle, so the pulse width is normally about 1 µs (the Width measurement shows a mean of 997 ns). This nominal width does not change significantly with any regularity and gives us a basis on which to begin looking for anomalies.

Finding Intermittent Events

Figure 1: Statistics for 1261 Width measurements
taken over 97 acquisitions on the Measure table.
Width statistics can help determine the set up
of a Glitch SmartTrigger.

Glitches, dropouts, runts, aperiodicity, missed cycles, slow edges—whatever you call them, they are irregular waveform elements that can wreak havoc with you circuit operation. Because they do not occur with regularity, they can be hard to find and correlate with whatever synchronous events may be causing them. How can you use your oscilloscope to easily find intermittent events where they occur? The answer is by judicious application of the oscilloscope’s measurement statistics and SmartTriggers®.

Measuring Dead Time in 48 V Power Converters, Part 2: Dynamic Measurements

Figure 1. P1 and P2 measure dt@lvl over the entire acquisition,
while P3 and P4 measure dt@lvl for only a single operational
cycle of zoom traces Z1 and Z3.

A primary engineering task for 48 Volt power conversion systems using bridge topologies is to ensure adequate dead time to prevent catastrophic shoot through occurring when both HI and LO FETs conduct at the same time. Being able to accurately measure dead time is therefore of critical importance. Part 1 of this series dealt with the basic dead time measurement. Part 2 will deal with studying the dynamic changes in the dead time measurement using statistical tools like tracks and histogram functions. 

As we learned in part 1, the dead time delay is measured using two instances of the measurement parameter Delta Time at Level (dt@lvl) as shown in Figure 1. 

In the Figure 1, the dt@lvl parameters P1 and P2 show the value of the last measurement in the acquisition which contains 10,000 switching transitions. The parameters P2 and P4 measure only the single timing cycle shown in the zoom traces. (Click any  image to enlarge it and see the detail.)

The values of both parameters are different, and you should ask the question: how does dt@lvl vary with time? To find the answer, turn on the measurement parameter statistics, as shown in Figure 2.

Testing for Near Field Radiated Emissions in the Time Domain

Figure 1. Triggering on a time-domain signal
likely to be coincident with radiated emissions
helps to locate where in the channel di/dt occurs.

There are three, principal root causes of the common currents that lead to radiated emissions in electronic devices:

1. Return path discontinuities 

2. Physical structures that are not tightly coupled to the return plane

3. Ground loops causing common currents in cables 

We’ll briefly demonstrate a bench top test for finding sources of near field radiated emissions caused by return path discontinuities using a real-time oscilloscope in the time domain.

Why the time domain? Although EMC compliance testing is done in the frequency domain, in the time domain we can see the signatures of near field emissions in a way that yields information about the root causes of those emissions. It is a type of pre-compliance EMC testing that can be easily done in your lab, without the expense of an anechoic chamber.

Near Field vs. Far Field Radiated Emissions

Figure 1. The near-field emissions we measure
in the lab may not be an accurate measure of
the far-field emissions on which EMC is certified. 

When we are testing a product on our bench top for EMC, we are in close vicinity to that product in a typically noisy environment. All we can measure is the near field, the electric or magnetic field strength in close proximity to our product. It’s important to keep in mind that near field measurements are not the same as the far field (3 m or more) measurements in the FCC Part 15 Radiated Emissions test described earlier, and here's why. 

Unintentional Antennas in Electric Circuits

Figure 1. Certain design features can introduce
unintentional antennas into electric circuits.

In our last post, we discussed how little radiated emissions it takes for an electronic product to fail an FCC certification test for EMC.

Where do these radiated emissions come from? No one designing an electric circuit board is designing them into their product on purpose. These sneaky antennas do not appear in the schematic. However, we can unwittingly introduce them into our product through certain styles of board and interconnect design features. It is sometimes jokingly said there are two kinds of designers: those who are designing antennas on purpose, and those who aren't doing it on purpose. We’re going to introduce two, basic models of antenna—magnetic dipole and electric dipole (Figure 1)—to reveal a secret source of radiated emissions.

Pre-compliance EMC Testing Using a Real-time Oscilloscope

Figure 1. Formula for calculating radiated power from electric
field measured at a given distance. Only a few nanowatts of
radiated power can cause a product to fail an EMC certification test.

When designing an electric circuit board, we always start with a schematic. All it tells us is the components in use, how they are connected, and what the functionality of the system is. The schematic tells us absolutely nothing about signal integrity, power integrity or electromagnetic interference (EMI). All the schematic tells us about is the connectivity.

Problems with signal integrity, power integrity and EMI all come to life when we turn that schematic into a physical implementation, because once we have connectivity established by the interconnects, the only thing interconnects are going to do is screw up our beautiful design. They're going introduce noise, and that noise is going to cause some combination of signal integrity, power integrity and EMI problems. The best we can do is to minimize its appearance and impact using best design practices.

In this series, we'll focus on design issues that affect EMI, and how you can use a real-time oscilloscope to find the root causes of EMI that negatively affect a product's electromagnetic compatibility (EMC).

Testing Power Rail Sequences in Complex Embedded Systems

Figure 1. Four power rail signals on a single grid, with cursors
measuring the time delay between the first pair in the sequence.

Embedded computing systems generally require multiple supply voltages to deliver power to the microprocessor, memory and other on-board devices. There is usually a 12- or 15-volt DC primary supply, and numerous buck or boost converters working off the primary to help provide various voltages throughout the embedded system. Most microcontrollers have a prescribed order in which the voltages must be applied to prevent problems like lockups, so an area of concern when designing deeply embedded systems is the proper sequencing of power rails as they power up or down. Power management IC’s (PMIC) or power sequencers perform many of the sequencing tasks, but during validation and when troubleshooting, the order and timing of the power sequence should be verified.

Correlating Sensor and Serial Data in Complex Embedded Systems

Figure 1: Voltage output of a temperature sensor.
As the temperature rises, the output voltage falls. 

The microcontrollers/microprocessors in deeply embedded systems often are set up to monitor and control operational parameters.  Take, for example, a deeply embedded system where a microcontroller is used to control temperature that has been sensed by a temperature sensor.  The sensor is read through one of the microcontrollers analog interfaces.  As temperature changes are sensed, the microcontroller adjusts the speed of a cooling fan, which is driven by a pulse width modulated signal. The microcontroller uses a program algorithm to convert the DC level of the sensor into a PWM signal with an appropriate duty cycle to set the fan speed to correct any changes in temperature. 

Where it is possible to probe the temperature sensor, the output is a DC signal that changes very slowly over time.  Figure 1 shows a direct measurement of the temperature sensor using a heavily filtered oscilloscope channel to minimize noise pickup.

Correlating Low to High-Speed Events in Complex Embedded Systems

Figure 1: A challenge when testing embedded systems
is to correlate events in a low-speed interface like SPI
to events in a high-speed interface like PCIe.

A common requirement when testing embedded systems is to measure the timing between signals with low data rates and those with high data rates. Looking at the functional block diagram of our typical deeply embedded system in Figure 1, we see low-speed serial interfaces like SPI and I2C along with high-speed serial links, like PCIe (often serving as the high-speed serial PHY in our diagram).

Take for example testing the initialization of the system. When power is first turned on, the ROM bios and flash memory initialize program elements that are required by the embedded system’s microprocessor. Once the initialization is complete, the microprocessor has to notify the motherboard via PCIe that it is active and ready to receive data via the high-speed serial bus. This all has to happen within 200 milliseconds. 

Debugging Complex Embedded Systems

Figure 1: A typical embedded system has many devices
utilizing a wide range of signal types and bandwidths.

In the next few weeks, we’ll present a series of posts describing the debugging of various components of embedded systems, everything from working out the timing of power on sequences to extracting analog sensor data from serial data streams. All these examples of “real world” debugging can be performed using only standard tools available on most mid-range Teledyne LeCroy oscilloscopes.

Let's start by defining what we mean by embedded system and deeply embedded system. For our purposes, an embedded system is a fixed function, self-contained control system on one printed circuit board. Typically, printed circuit boards (PCBs)  will have multiple passive devices, a few active electronic devices, analog devices, digital devices and a few serial data devices. There tends to be a microcontroller device to process data and control other components. There will also be some type of system memory, often embedded inside the microcontroller. And, there will be some power conversion devices and power distribution elements that power all the other devices in your embedded system. 

Measuring Dead Time in 48 V Power Conversion Systems, Part 1: Static Measurements

48 volt power conversion systems input a 48 VDC power bus and output other voltage levels. The key section in the conversion process is the inverter stage. The inverter subsection topology may be half bridge, full or H-bridge, or cascaded H-bridge for 3-phase systems. There is typically a filtering circuit after the inverter before power is passed on to the Load, and a control system that takes care of controlling the entire conversion system. 

Figure 1:Three common topologies for switching inverter stages. The load is connected between upper and lower power switching devices, which are selectively switched on and off to supply power to the load from the DC bus.

The three inverter topologies shown in Figure 1 are all similar in that they use stacked or “totem pole” power devices for switching. 

In operation, each of these topologies provides a path from the DC bus through the load and then to ground (0 V) by turning on selected devices. At no time should there be a direct path from the DC bus to ground, an event called “shoot through.” Designers intentionally add dead time to eliminate the risk of shoot through.

Debugging Dynamic Link Behaviors with CrossSync PHY for PCIe

Figure 1: These upstream lanes show unexpected equalization
behavior. If you only had the electrical signals to work with,
how would you begin debugging them?

Recent generations of PCI Express® rely heavily on the link equalization process to support signal integrity at bit rates of 8, 16 or 32 Gbps. In Phase 1, both sides of the link exchange TS1 ordered sets to establish an operational link. In Phase 2, the upstream port requests the downstream port to configure its transmitter equalization to compensate for the link channel. In Phase 3, the opposite happens, and the downstream port requests the upstream port to configure its transmitter equalization. 

At PCI Express compliance events, or when doing pre-compliance testing in the lab, a transmitter link equalization test is performed to determine whether a device is capable of correct link equalization in isolation. A piece of test equipment, usually a protocol-aware BERT, acts as the link partner for the device under test. The BERT requests specific preset changes from the device, in response to which the device (in theory) changes its preset to provide the correct channel compensation. The changes are captured by an oscilloscope, which is capable of visualizing the transmitter equalization changes in the electrical layer and measuring first of all, if they happen quickly enough, and secondly, if the device actually changed to the preset levels requested, which occur in a known sequence. 

But what happens when you suspect "weird" equalization behavior in a live link between two devices—for example, something off with the upstream equalization in Phase 3?  How would you capture that to begin debugging the problem? Where would you look for a clue as to what is happening?

Debugging L1 Substates Timing Errors with CrossSync PHY for PCIe

Figure 1: CrossSync PHY for PCIe lets you easily map the
electrical to the protocol layer of L1 substate events.

Debugging the L1 substates used for PCIe® power management has been a real pain point for engineers, especially those using the M.2 form factor. The L1.1 and L1.2 substates allow you to take a PCIe link to a deeper power savings state than L1 alone. L1 is entered by either of two mechanisms, an ASPM message or a Power Management message, but in both cases the net effect is that the link goes into electrical idle. Unlike conventional L1, a clock request (CLKREQ#) signal is used to enter and exit the L1 substates. Upon entry, the device or host deasserts the clock request line. By saying, “I don’t require a clock anymore,” the clock can be turned off for additional power savings. Upon exiting the L1 substates, the CLKREQ# is asserted and the reference clock resumes.

Anatomy of a PCIe Link

Figure 1: A PCIe link between root complex and end point.
Each device has its own transmitter and receiver.

Peripheral Component Interconnect Express (PCIe®) is a high performance, general-purpose input/output (I/O) interconnect designed for a wide variety of computing and communication platforms. Recent iterations of the standard take advantage of high-speed serial technology, point-to-point interconnects, switch-based technology, and packetized protocol. They rely heavily on link negotiation and link training, so much so that being able to capture and view dynamic link behaviors is essential to debugging PCIe devices. Nevertheless, it remains a pain point for PCIe engineers. Why is it so difficult? To start, let’s break down the PCIe architecture to understand what is going on.

How to Test Noisy Power Supply Outputs

Figure 1: 3.3 V output of a DC-DC converter.
The waveform shows the nominal DC level,
ripple and high frequency noise bursts.

Did you ever acquire the output of a power supply with your oscilloscope and find an unexpectedly high level of noise? Did you try adding filter capacitors only to find the noise level was not changed? 

In this post, we'll discuss how the choice of probe affects the noise present in power measurements, as well as how oscilloscope settings such as termination impedance, bandwidth and coupling can be adjusted to lessen noise and improve measurement results.

Figure 1 shows a typical DC-DC converter output measurement. The mean value of the waveform is 3.294 V.  Ripple appears at the switching frequency of 1.2 MHz, and noise in the form of high frequency bursts and baseline thickening is visible throughout.

Waveforms like this can be acquired with a 10:1 high impedance probe, a 1:1 coaxial cable connection, or a 1.2:1 rail probe using either DC or AC coupling, as available.  Figure 2 summarizes how each oscilloscope/probe configuration affects the measurement.

MAUI Studio Pro: Generating Waveforms

Figure 1: MAUI Studio Pro lets you generate
multiple waveform types from equation.

MAUI® Studio includes a simple waveform generator that enables you to create any of six standard waveforms or a DC current simply by enter a few waveform properties, such as frequency and amplitude. The waveforms are continuously generated and act like a live, repetitive waveform acquisition for simulation exercises. 

MAUI Studio Pro adds to that a true, arbitrary function generator. Numerous different waveform types can be generated from equation, and custom jitter/noise characteristics can be added to any generated waveform. 

MAUI Studio Pro: Analyzing Anyone's Waveform Data

Figure 1: A waveform file (.bin) saved on a Keysight 
oscilloscope undergoes multiple math and measure
 operations in MAUI Studio.

 Another key feature of MAUI® Studio and MAUI Studio Pro is the ability to recall waveform files saved on other vendors' oscilloscopes, as well as on Teledyne LeCroy oscilloscopes. The software supports files saved on Tektronix (.wfm), Keysight (.bin), Rohde & Schwarz (.bin) and Yokogawa (.wvf) instruments. It even lets you filter for these types when browsing for files. And with some simple editing, "time and data with header" format  Excel (.csv) files can also be recalled into MAUI Studio, extending its analysis capabilities to waveforms acquired from nearly any type of instrument or sensor.

MAUI Studio Pro: "Impersonating" Remote Oscilloscopes

Figure 1: After recalling the LabNotebook, MAUI Studio Pro
 (now simulating an HDO4024A) will "impersonate" the
WaveRunner 9404 on which the file was saved.

Our recent release of MAUI Studio Pro adds several key new features to the MAUI Studio remote oscilloscope software for Windows 10 PCs. This short series will demonstrate how to make use of these features.

One of the most useful new features is the ability to inherit the entire "personality" of an oscilloscope. By that, we mean the MAUI Studio Pro software replicates the oscilloscope model type and user interface, along with its full complement of software options. It "impersonates" the oscilloscope. There are a couple ways this can be done.

Automotive Ethernet MDI S-parameter Testing

Figure 1: MDI S-parameter tests treat the Base-T1
pair as a balance transmission line and check that
reflections don't cause either excessive power loss
or mode conversion that can disrupt the signal.

As said earlier, the automotive industry has very stringent EMC/EMI requirements, and all Automotive Ethernet standards are designed to ensure good operation even in the presence of high EMI. Not only is there the potential for interference from all the different electronic systems within the vehicle, nothing is stopping you from parking your vehicle below high-voltage transmission wires or in other high EMI fields. 

For this reason, all Automotive Ethernet standards have defined S-parameter tests to be performed at the Medium Dependent Interface (MDI). The assumption is that the single twisted pair that is the basis for all Base-T1 transmissions can be treated as a balanced, differential transmission line with some crosstalk. It is a very real-world application of S-parameters, which can seem so academic.

Two, mixed-mode S-parameters are measured at the MDI reference plane. The tests ensure that there is neither too much loss of power from reflections, nor too much mode conversion into differential signal, that it will disrupt the information of the PAM3 encoded signal.

Real-World Workload Replays on SSDs

The Problem

SSDs are expected to hit the market after undergoing rigorous sessions of testing and quality assurance. From a functional testing perspective, synthetic IO workloads have been the de facto method of testing. While synthetic workload testing is essential, it doesn’t exactly reflect the real-world environment, whether that is inside a data center or a client’s laptop. Real life workloads tend to be a lot more “bursty”, and it’s during these short bursts that SSDs run into long queues and high latency, ultimately degrading the quality of service.

In this blog post, we explore techniques to replay these real-world workloads and examine their results.

 

Overview of Real-World Workloads

First and foremost, what is a real world workload and how do I get it? Fig. 1 shows the typical process of how a real life workload is captured.

 

Fig. 1. Capturing a real-world storage workload.

Applications typically run on top of a file system that in turn push IOs to an abstracted OS storage layer before making it to the SSD. For Linux, this storage layer is the block layer, and for Windows, it can be either the DiskIO layer or the StorPort layer. IO capture tools are readily available to snoop all IOs within the storage layer. The most popular one for Linux is blktrace, and for Windows, Windows Performance Recorder is widely used capture tool. Alternatively, Workload Intelligence DataAgent (coming soon) is a powerful trace capture tool with built in intelligence to trigger and filter on user determined criteria. The outputs of these capture tools are trace files that contain all the IOs along with their timestamps and typically other information, like process IDs, CPU etc. It is these trace files that are used to generate IO replays from for offline testing.

Where can you get these IO trace files? If you work with a customer that uses your SSDs or storage subsystems, they typically collect such trace files for their own analysis purposes and may be open to sharing them. This would be the best scenario as you can get a live view of a real-world environment. If you are the SSD user, you can use the aforementioned capture tools to trace the IOs in your application environment.

Alternatively, SNIA provides a number of open-source real-life storage workloads: http://iotta.snia.org/tracetypes/3. Finally, you can always concoct your own setup- run a MySql or Cassandra database, simulate some application queries, and capture storage layer IOs. While strictly not “real-world”, this will at least give you a good sense on how application activities trickle down to storage IOs.

 

Replaying Workloads

With the workload traces on hand, it’s time to replay them in your test environment. The goal of doing so is to reproduce the issue that was caught during the production run, and also to tune or make fixes to SSD firmware to see if the issue gets resolved. If one is evaluating SSDs, this is a great way to see if the selected SSDs pass the workload criteria.

The recommended storage replay tool is the Workload Intelligence Replay. Replay files can be generated from Workload Intelligence Analytics, to run on an Oakgate SVF Pro appliance. The replay results can then be ported back to Workload Intelligence Analytics to compare with the original trace, or with other replay results. Fig. 2. shows the flow of how storage traces are captured, replayed, and compared.

Fig. 2. Process of replaying and analyzing a storage trace.

When replaying a storage workload to target drive, a number of factors must be considered to make sure the replay emulates the production environment as much as possible:

1. Target drive selection – Ideally, the DUT should have the same make and model as the drive that the production trace was captured on. If this is not possible and the target DUT has a different capacity, the replay software should be able to re-map LBAs so that they fit within the DUT. Oakgate SVF Pro Replay handles this situation by offering different LBA out of range policies, including skipping the IOs, wrapping the IOs, and linearly re-mapping IOs that exceed the LBA range. We’ve found re-mapping LBAs to be the most effective in duplicating production scenarios. 
2. Target drive prefill – It is essential the DUT gets prefilled properly to emulate the state the production drive was in before the capture happened. While it’s impossible to condition the DUT to the exact state the production drive was in, we’ve found that a simple 1x write prefill was able to duplicate production drive scenarios. Alternatively, Fiosynth offers fairly sophisticated preconditioning techniques that are reflective of data center workloads.
3. Accurate IO timing and parameters – The heart of an effective replay is software that can emulate when and what the production host sent to the device. To achieve that goal, Oakgate SVF Pro matches the replay trace file IO in terms of relative timestamp, IO size, and LBA. Fig. 3 and 4 show the LBA vs. Time and IO Size vs. Time, respectively, of a production blktrace versus that replayed by Oakgate SVF. As can be seen, the timings and values of the replayed IOs is exactly same as the production trace. The variable of interest is typically the latency of each IO and the IO queue depth and are expected to be different from the production trace.

 

Fig. 3. LBA vs time of production blktrace (blue) and the replayed trace (orange)

 Fig. 4. IO Size vs time of production blktrace (blue) and the replayed trace (orange)

Replay Experiments

Now that we’ve been primed about the intricacies of workload replay, let’s take a look at some experiments.

In all experiments run, we’ve preconditioned the drive 1x. The chosen drives were standardized to 0.5 TB. All production runs were captured when the drive was formatted to 512 bytes, so for the replay, we’ve also formatted the drive to 512 bytes.

 

Replay Repeatability

In the first set of experiments, we tackle the question of how repeatable a workload replay is. This question is important because we need to know whether the replay software can duplicate the same profile on the same drive during a production run. Even if we can duplicate the profile, it is also crucial to know whether this same profile can be regenerated after 10s or 100s of replays. If the drive shows a statistically different profile on every replay run, it can indicate that the drive does not have very stable performance.

For this experiment, the production workload we are running consists of a combination of applications, primarily: Postgresql with light traffic, and Spark + HDFS data store with large datasets that get cached and persisted onto disk. We captured a blktrace on the production machine.

 

Fig. 5 shows the latency vs time of the production blktrace over a 10 minute snapshot.

 

Fig. 5. Latency vs time for a production blktrace with a big data workload

Since we control the “production” environment, we’ve taken this same drive over to an Oakgate replay appliance and ran a replay file generated from Fig. 4’s workload. We iterated multiple rounds of replay (preconditioning between each iteration) and took those results and fed it back into WI Analytics for comparison. Fig. 6 shows 3 iterations of the replay.

Fig. 6. Latency vs time for three rounds of replay

In a quick glance, we can see that the latency spikes and their timings for the replayed results are extremely similar to the original production trace. There are some statistical differences, if we closely, which is expected. Overall, the replays have faithfully regenerated the latency profile in an offline environment, and this particular drive has shown stable results after multiple rounds of replay.

 

Replay Comparison for Different SSDs

Next, let’s run experiments on how different SSDs react to the same workload. Such a use case can very well be used to qualify different drives for a data center’s set of workloads. From a different angle, the same experiment can be run on the same SSD with different firmware to see if firmware changes are effective against a particular set of workloads.

In these experiments, we had chosen an actual data center workload that showed a particularly stressful profile. Fig. 7 shows the read latency vs. time of the production workload. We can see very big latency spikes happen, and we would like to know whether other SSDs can handle this same workload without these latency spikes. Fig. 8 shows the main obstacle the workload entails – a burst of large discard (trim) IOs that is likely causing the disk to become blocked while servicing those discards, contributing the high read latency spikes.

 

Fig. 7. Data center production blktrace.

 

Fig. 8. Discard (trim) IO sizes vs time for production blktrace.

 

Fig. 9 shows drives from various vendors that did not encounter the read latency spikes despite undergoing the same production workload. Latency scales are normalized to that of the production workload the contrast the latency differences.

 

Fig. 9. Workload replayed against drives that did not show latency spikes.

By contrast, Fig. 10 shows the set of drives that show an adverse reaction to the burst of discard IOs. Vendor F in particular never recovered to its baseline latencies after getting swamped with the discard bursts.

 

Fig. 10. Drives that reacted adversely to the replayed production workload.

 Conclusion

The ability to replay production storage workloads is an essential tool to improving or qualifying SSD real-world performance. Unlike synthetic workloads, production workloads are much more unpredictable, dynamic, and reflective of real application environments. In this blog, we discuss the various aspects of accurately replaying workloads in an offline environment and showed examples on how to properly reproduce production environments. We also showed how different SSDs can react very differently to the same production workload. Hopefully, we’ve conveyed the point that it is essential to use real-world replays to design better SSDs and better match sets of SSDs relevant to one’s real-world environment.

By Fred Tzeng, Ph.D. Software Architect

OakGate Product Family, Teledyne LeCroy

Learn more about Teledyne LeCroy OakGate Products

Automotive Ethernet in the Vehicle

Figure 1 Block diagram of a typical ADAS system
showing the in-vehicle networks used.

As all Automotive Ethernet technologies utilize a single twisted-pair cable (T1) and a point-to-point network topology, they differ primarily in their data rates and encoding methods. For the most part, the data rate determines the applications for which a particular Automotive Ethernet standard can be used. If we take the case of an automatic driver assistance system (ADAS), we can see where each Automotive Ethernet variant might best be used to replace existing automotive protocols. 

(Click on any figure to enlarge the image.)

Fundamentals of Automotive Ethernet

Figure 1: Automotive Ethernet is designed to support
increasingly complex vehicle electronic systems.

When we speak of “Automotive Ethernet”, we’re referring to a group of Ethernet interfaces intended for in-vehicle use, customized to meet the needs of the automotive industry. The first Automotive Ethernet standard was defined by Broadcom in 2011 with BroadR-Reach. Since then, IEEE has released standards for 100Base-T1, 1000Base-T1, 10Base-T1S and most recently MultiGBase-T1. Together, these standards define the general technology known as Automotive Ethernet.

Probably the first question you ask is, “Why not just use standard Ethernet?” A summary of the fundamental features of Automotive Ethernet will show how much better Automotive Ethernet is than standard Ethernet at meeting the industry’s demand for a higher speed, robust, lightweight and lower cost data interface, one that can ultimately replace the many other protocols currently used throughout the vehicle.

Five Tips to Improve Dynamic Range

Dynamic range is the ratio of the maximum signal level to the smallest signal level achievable in a measurement.  Tools with good dynamic range are especially helpful for analyzing wide dynamic range signals in which a full-scale signal must be acquired, while at the same time, very small amplitude signal details must be visible. Here are five tips for improving the dynamic range of your measurement instrument.

Mode Conversion

Figure 1: The lower-left and upper-right quadrants of this
matrix show the S-parameters that represent mode conversion
from differential to common signal, and vice versa.

As said earlier, mixed-mode S-parameters describe the general case of combinations of differential and common signals. When we speak of mode conversion in mixed-mode S-parameters, we are referring to the change of a differential signal into a common signal, or a common signal into a differential signal, as it travels the transmission line. If we look at the matrix of mixed-mode S-parameters in Figure 1, we see that those mixed mode S-parameters affected by such a mode conversion—with a different type of signal going out than what went in—are in the lower-left and upper-right quadrants.  

Let’s take the S-parameters SCD11 and SCD21 to see how the combination of single-ended S-parameters they represent reveal the source of mode conversion. If we look at SCD11, the reflected mode conversion, as a function of its single-ended S-parameters, we see:

Converting Single to Mixed-Mode S-Parameters

Figure 1: Model of two transmission lines with crosstalk
showing the transmission and crosstalk related S-parameters.

We have introduced mixed mode S-parameters and developed a formal structure for handling them. It is now time to discuss converting single-ended S-parameters into mixed-mode S-parameters. This is important because every instrument manufacturer obtains mixed mode S-parameters by first measuring single-ended S-parameters, then converting them mathematically to mixed-mode. This assumes that the interconnects being measured are passive, linear and time invariant.  Let’s begin with our model of two transmission lines with crosstalk shown in Figure 1.