Wes Simpson
Delivering video over packet networks requires a certain amount of discipline to ensure the receiver is neither overwhelmed by bursts of excessive amounts of data, nor starved by inadequate flow rates. For constant bit-rate streams, a good analogy is a placid stream of water—a smooth, constant flow without ripples or waves.
Inside a broadcast facility, uncompressed SDI signals (SD, HD or faster) have traditionally been transmitted at constant bit rates with tight tolerances on binary clock rates. Clock rate deviations are called “jitter,” and are constrained to be a small fraction of the overall bit rate.
On an HD-SDI link running at 1.485 Gbps, the alignment jitter is constrained to be 0.2 unit intervals, or 135 picoseconds. In other words, the clock rate of the bit stream cannot vary by more than the amount of time that it takes light in a vacuum to travel 4 cm. Clearly, SDI streams have very placid behaviors.
In packet networks, data transmission behavior is completely different. Bits are transmitted in groups (packets) at the speed of the underlying connection; and then the link is empty until the next packet is ready to go.
Fig. 1: 200 Mbps video signal carried on a 1 Gbps Ethernet link For example, consider a Gigabit Ethernet link that is carrying a constant bit-rate 200 Mbps video stream (including overhead). A perfectly well-behaved source could transmit this signal as a stream of 10,000-bit (1250 byte) packets (which would each take 10 microseconds to transmit); followed by a gap of no data for 40 microseconds (enough time to send 40,000 bits); followed by another packet, another gap, and so on. (This is analogous to a duty cycle of 20 percent.) Fig. 1 shows this constant bit-rate stream being transmitted as a series of data bursts.
Given their inherent bursty nature, measuring packet streams can be tricky. One important objective of measuring a packet stream is to determine if the stream possesses placid flow characteristics (i.e. the packets are regularly spaced and the stream requires only a minimal amount of buffering at the receiver). One way to characterize the stream is by measuring the Peak to Average Ratio (PAR).
To make a PAR calculation, the packet stream is measured to find both the peak data rate and the average data rate, and then taking the ratio. In a perfectly placid stream, the PAR would equal 1, meaning that there were no data peaks above the average bit rate.
One problem with the calculation of PAR is that it is highly dependent on the sampling window used for the measurement, the selection of which can significantly skew the results.
Consider the perfect 200 Mbps stream mentioned above. If the sampling window for the PAR was very short (say, 5 microseconds) then the measured data rate would be 1 Gbps if the window coincided with a data packet and zero if the window did not coincide.
Fig. 2: Peak to Average Ratio Measurement with 5 microsecond sampling window In Fig. 2, the measured bit rate for sampling window A would be 1 Gbps; for window B around 500 Mbps; and zero for windows C and D. The average bit rate for all the sampling windows on the stream would be 200 Mbps, but the peak data rate (encountered in window A) would be 1 Gbps. In this scenario, the PAR would be 5 to 1, even with perfect spacing between packets.
Using a longer measurement window would help to correct this measurement, but it would open up other error possibilities.
Fig. 3: Two streams with same peak bit rate using 125 microsecond sampling window Consider a 125 microsecond sampling window, as shown in Fig. 3A. In this case, the individual bit-rate measurements would vary between 240 Mbps (if three full data packets happened to fall within the sampling window) and 160 Mbps (if only two packets fell into the window).
The average bit rate across all the sampling windows would still be 200 Mbps, so this sampling window size would give a PAR measurement of 240/200 or 1.2. This is closer to the ideal of 1.0, but not quite there. A bigger problem is that the PAR measurement would be the same for a stream where several packets are bunched together within one sampling window, thereby allowing a data rate peak to go undetected.
This is shown in Fig. 3B, which also has a PAR of 1.2, but clearly does not exhibit the smooth, regular flow characteristics of a well-behaved, placid data stream.
The only way to get a PAR exactly equal to 1 for a placid data stream is to use a sampling window that is exactly equal to the transmission time of one packet plus one inter-packet gap (which would be 50 microseconds in the above example). Unfortunately, maintaining this equality requires the sampling window to change every time the stream’s bit rate changes, as well as every time the underlying network speed changes. This makes PAR calculation difficult, and probably not the best choice for making measurements in a packet network.
The next installment of this column will look at some other techniques for characterizing placid packet streams.
Wes Simpson is an independent consultant and educator for IP and video technology. He is currently developing an online course for SMPTE and a classroom course for IEEE BTS. Wes will be at VidTrans 2015 in Marina del Rey, Feb. 24–26.
