Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Dealing With Latency for Performance Improvements

More stuff in the cloud can lead to problems

This article originally appeared in TV Technology.

Latency is a continual concern, impacting nearly all forms of media and communication systems. It can be evident in an internet connection, a server, a disk system and in an IP network. We’re hearing a lot more about latency as we move from the SDI-world to real-time video over IP.

Latency is defined as the time interval (or period) between a stimulus and a reaction or response. Latency can be a “physical” property — as in the velocity of propagation (VoP) in a cable referenced to the frequency of the signal carried and is based upon the materials used in the fabrication of that cable.

Latency can also be a “signal transport” property, such as in the time of flight (ToF) — i.e., the methodology describing the time it takes an object, particle or acoustic, electromagnetic or other wave to travel a distance through a medium.

Fig. 1: Typical causes of latency due to propagation delay of the links (Dlink) and in processing delay at the nodes (Dnode) which must be accounted for in system design. ToF might include how the elements in a network (transmitters, receivers, switches and transducers) are engineered; while VoP is influenced, in part, by choice of cabling itself (e.g., Belden 1694A compared to 1855 for video or Cat-5 vs Cat-6a for IP).

Video latency — especially in a packetized IP-network — can affect reliability, stability and the ability to properly switch a line of video. Practices described in SMPTE RP168, the recommended practice defining the vertical interval switching point for video, help govern how real-time video-over-IP systems address the packetization of essence for live (real-time) video systems.

The needs for a live stream of video compared to feeding a monitor wall or encoder take on different perspectives, which must be carefully considered as signals negotiate segments of any network.

Latency in the recovery and reassembling of packets in a video signal transport network can affect the time it takes to reconstruct a complete frame (field) of video. Too much latency and you have a time inconsistency causing skipped frames or stuttering video.

Buffer capabilities also affect performance. If the network switch’s buffer is insufficient, the impact can result in an incomplete packet resolution, which could cause a series of video frames to be lost or a switch-routing or connection to fail — thus generating another improperly displayed image or a total loss of signal.

Performance and latency go together when looking at any system solution or application, which depends upon consistent and deterministic delivery of data. In today’s media implementations, audio and video essence (the data, sometimes called the payload) can take on variances depending upon where the data is presented in the workflow. One relevant and timely perspective (for the professional video industry) is embedded in the Real-time Transport Protocol (RTP) characteristics of networking; i.e., how the signals are impacted in a streaming-video vs. a file-based workflow.

Interested technical readers should read and understand such terminologies as RFC 3550 (the transport protocol for real-time applications) and RFC 4175 (the RTP payload format for uncompressed video) — both openly available and developed through the IETF (Internet Engineering Task Force).

Servers bring with them their own set of latency and performance issues. Insufficient memory sizing; poorly managed caches or processor core(s) that cannot keep up with the signal throughput demands, which will result in a slowing of applications; signal throughput delays; or, in the worst case, computational errors, which hinder synchronization with the overall system’s demands.

Multicore servers available today have plenty of CPU power; yet getting that power to or from the network may be an issue. Network interface cards and host bus adaptors can be a server bottleneck if not properly configured, specified or implemented.

Traditionally these I/O components were locked to a single core processor. However, by using other resources, such as hypervisors and resource-side scaling (RSS), performance is increased by allowing the interface cards to distribute the I/O processing across multiple processor cores.

Another server virtualization technique deals with sorting the I/O tasks to the right virtual machine. This technique involves what is referred to as “virtual machine device queuing.” This VMDQ technology is productized by vendors who make I/O and processor cards. It allows the Ethernet adaptor to communicate with established hypervisor products to group packets per the best needs of the VM they are intended to be directed to.

Storage solutions intended for media production have their own set of throughput, performance and latency issues, which are generated by varying factors. At the single disk root-level, and the most notable or easy to understand, are the impacts of “rotational latency” (sometimes called “rotational delay”), which is based in part on the rotational speed of the drive.

This is a physical factor prevalent in every spinning magnetic disk or optical disc drive medium. Rotational latency is measured as the time that it takes the data on the drive platter in a sector to be positioned beneath the head for the read (or the write) process. The worst-case time-period number is found when the drive data has just passed the head, and the command to retrieve that data can only be met when the drive needs to complete a full revolution before being properly positioned to read that data.

Other factors include “seek time,” the time for the actuator arm to travel to the proper track on the drive; and “access time,” also called “response time,” the time it takes for a drive to transfer the data from the specified track to the drive electronics.

These factors are cumulative and affect performance, but in recent times we’ve seen additives to the storage mix that help alleviate performance-latency issues.

Solid-state devices, as complete replacements for HDDs or as supplemental caches for HDDs, help manage performance issues by (in the latter case) putting frequently accessed data into SSD caches. Here, routine calls for operational data or system metadata are stored in SSD devices, so accessing the HDD is reduced, improving efficiencies.

When editing applications know that they will frequently be playing a clip from the primary timeline, the well-designed app often instructs storage management to put that data into SSD. Timeline performance is improved and latency is decreased because the SSD has a significantly faster access time than does the HDD.

Storage systems should be demonstrated per the user’s specific implementations. For example, a NAS system designed specifically for media and entertainment will employ characteristics that can’t be met by other non-M&E storage solutions. One known evaluation test used in storage demos is to compare the load time of a set of files from a central storage array to the active NAS used in editorial or shared collaborative production.

Another is to check the ability to accurately scrub the video and audio in a high-resolution file (e.g., a 4K full-resolution sequence) and see how closely and smoothly the audio tracks the video.

Significant differences can be achieved by marrying the appropriate operating system (OS) to the file system, which traditionally have separate roles. When the file system is aware of the underlying disk structure, values are added.

In the past, file systems were traditionally created only on a single disk at a time. When two (non-RAIDed) disks were employed, two separate file systems would be created.

In a RAID configuration, this situation is avoided because the OS looks at only a single “logical disk,” which is likely comprised of many physical disks, on top of which the operating system places a file system.

In software RAID, the file system living on top of the RAID transform sees it is dealing with only a single drive. The implementation reduces read/write process complexities and hence improves performance. One pertinent example is ZFS (originally developed by Sun Microsystems, now Oracle), which is conceived of a combination volume-manager and file system. The concept allows the creation of many file systems that share a common pool of available storage. The storage system could be grown automatically because the file system is aware of the physical disk layout. This permits existing file systems to be grown automatically when additional disks are added to the pool. The new volume-space is then made available to every one of the file systems.

The evolution of storage “additives” is what storage vendors and solutions providers continually do to “build a better mouse trap,” as the colloquial saying goes. Users will inevitably keep changing their storage solutions because the improvements make consequential differences in their workflows. Pooling resources and using a storage manager product to relegate where that storage is used in the enterprise is just another way to extend the usefulness of legacy and in service storage.

Karl Paulsen is CTO at Diversified ( and a SMPTE Fellow. Read more about this and other storage topics in his book “Moving Media Storage Technologies.” Contact Karl at [email protected].