Understanding IP Networks - Measuring Line Speeds

In the last article, we took a deeper look at the packet analyzer Wireshark. In this article, we continue the theme of looking at a network from a broadcast engineers’ point of view so they can better communicate with the IT department, and look at one of the most misunderstood concepts in the IT industry – network line speeds.

In the analogue days, broadcast engineers used frequency responses to measure line capability. An audio twisted pair had a bandwidth of at least 20KHz and video had a bandwidth of approximately 8MHz. As we moved to digital audio AES3 and SDI SD these requirements increased to 3Mb/s and 270Mb/s respectively.

Digital audio and video systems send high and low voltages to represent the one’s and zero’s. However, at the higher frequencies we need to take into consideration the analogue qualities of the transmission cable and equalizing circuits. Return loss, reflections and phase distortion are all significant factors needing consideration.

When speaking to the IT department, we might think that we should no longer worry about these qualities as signal paths are defined in bits per second. An internet line might be defined as 200Mb/s and an SFP link might be defined as 1Gb/s.

Telegraphers Equations

IT engineers tend to be product specialists in their own fields of Microsoft, Linux and Cisco. Very few of them will study transmission theory in the way broadcast engineers have in the past, especially those who worked in transmitters. This can lead to some very frustrating and confusing conversations between IT and broadcast engineers.

An IT engineer might tell you that the bandwidth of a circuit is 200Mb/s, or the delay is negligible. At this point a broadcast engineers blood would boil as they have flashbacks to their Telegrapher’s equations and two port networks. The simple answer is that IT engineers think in terms of service level agreements, if a Telco has provided a circuit with 200Mb/s capacity then they assume and expect it to be true.

Ethernet packet has overhead from header and CRC reducing data throughput.

Ethernet packet has overhead from header and CRC reducing data throughput.

IT engineers think of network capacity in terms of bits/second, as opposed to broadcast engineers who think in terms of bandwidth, return loss, phase distortion and reflections. Further problems arise when we start discussing actual data throughput in a system.

Headers Consume Bandwidth

Broadcast engineers will assume a 10MHz point to point network will allow them to send signals with 10MHz bandwidths. As IT networks are based on packets of data, there is an inherent loss of data in the system due to the headers and spaced distribution. A 10Mb/s circuit might only have a useful data-rate of 9.5Mbps.

Ethernet data packets are generally split into two parts, the header and payload. The header includes information such as send and receive addresses, payload types, packet counts and flags. The payload will be a protocol type such as IP, which will also contain a header and payload.

Drilling down into the ethernet packet we have the four octets of Cyclic Redundancy Check (CRC), and twelve octets of inter-packet gap appended to the end of the frame.

Octets Are Not Bytes

When discussing networks, engineers use octets instead of bytes to represent eight bits. This is to remove any ambiguity as computer science tells us a byte is “a unit of information”, which is based on the hardware design of the computer, and could be as easily eight bits, ten bits or one hundred bits.

Our ethernet packet frame generally consists of 1,542 octets, or 12,336 bits. Only the payload is available to us which is 1,530 octets, or 12,240 bits. If a camera uses UDP/IP to send its data over ethernet a further 20 octets are lost in the ethernet payload to the UDP header and CRC information leaving 1,510 octets, or 12,080 bits, all resulting in approximately 98% data throughput.

Reduced Capacity

The theoretical maximum of 98% assumes no congestion. The IT engineer is expecting 200Mb/s, but the Telco is providing 196Mb/s of usable data. Clearly the Telco will dispute this as they will show you they are providing a 200Mb/s circuit, and the fact that you are using 2% of it on packet header information is your problem not theirs. To the letter of the contract they are probably correct.

This may not sound a lot, but if you suddenly find your network has a 2% reduction in capacity, you could find yourself with some difficult questions to answer when approaching the Finance Director for more cash.

When analyzing network throughput, a thorough understanding of protocols must be achieved.

IPerf line speed testing.

IPerf line speed testing.

Transmission Control Protocol (TCP) sits on top of IP/Ethernet and provides a reliable connection based system to allow two devices to exchange data. Video and audio distribution generally doesn’t use TCP/IP; its data integrity is very high, but the throughput is very low.

TCP works by sending a group of datagrams and then waits for an acknowledge packet from the receiver, if the “Ack” isn’t received then the same packets are resent, eventually timing out and sending an error to the user if too many of these errors happen in succession. If the “Ack” is received by the sender the next group of packets are sent. Data throughput is reduced and is the price we pay for this data guarantee.


UDP/IP protocols, which SMPTE-2022 uses to transport video and audio, is a “fire and forget” system. The camera outputs the datagram and doesn’t use any form of testing to see if it was received at the destination, such as a vision mixer. SMPTE-2022-5 has forward error correction (FEC) built into it to provide some resilience over the network.

“IPerf” is used to actively measure the maximum achievable bandwidth in an IP network, it’s the closest tool we have for measuring a networks capacity and is released under the BSD license. It runs on two computers, a transmit at one end of the network and receive at the other. It works by flooding the link with IP datagrams and using the receiver to check their validity, consequently the measurement is destructive to other users of the network and must be used in isolation.

Understand What You Are Measuring

Operating as a command line tool IPerf can make many different measurements, from UDP/IP line-speed to TCP throughput. TCP measurements will always be slower as IPerf will be measuring the speed of the protocol, not the network line-speed.

When working with the IT department great care must be taken in understanding what exactly you are measuring.

Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

Building On IP COTS

Transitioning to IP improves flexibility and scalability, both of which are achievable using COTS IT equipment. But can COTS solve every challenge? Or does broadcasting still have some unique and more demanding requirements that need further attention? In this article,…

The Move Towards Next Generation Platforms

Whenever I’m asked about my opinion on the transition to IP, I always state that the impact can’t be appreciated until its history is understood. This brings into context the need for broadcasters to educate and surround themselves wit…

Taming The Virtualized Beast

Without doubt, virtualization is a key technological evolution focus and it will empower many broadcast and media organizations to work differently, more efficiently and more profitably.

Essential Guide: IP – A Practical Application

As broadcasters accelerate IP migration, we must move from a position of theory to that of practical application. Hybrid solutions to integrate SDI, AES, MADI, and IP will be needed for many years to come, even with green field sites,…

Broadcasters Now Need To Care About Quality Viewing Experiences

Thanks to Over-the-Top (OTT) streaming video, content owners and broadcasters have a very different relationship with the end consumer – often a direct one.