Investigating Latency in gnu software Radio with usrp embedded Series sdr platform

particular circumstance. There is a real-time scheduling 
mechanism in GNU Software Radio that sets the priority of the 
program to be highest, resulting in reducing waiting time. 
Another reason cause 
∆
software is buffering scheme. It is the 
FIFO 32kB buffer in Linux (64kB in Windows, generally the 
buffer size is equal the page size of the O.S). As a flow-graph 
design, GNU Radio contains blocks connected in serial; each 
block processes data in its buffer and generates data to the next 
buffer (Fig. 1). These default buffers are same size, equal to the 
page size. Assumed that samples are generated at a constant 
rate, if buffer size increases, throughput increases, and latency 
also increases. For example, a processor generates samples at 
2Msps, thus, it takes 4ms to fulfill the buffer. 
DSP Block 1
DSP Block 2
DSP Block 3
Buffer
Buffer
Buffer
Fig. 1. 
Buffers on GNU Radio Flow-graph structure 
C. Latency in Bus Communication (
∆
bus) 
This delay is because of buffering schemes at UHD driver 
(denoted as ∆UHD)
, at USRP bus controller buffer (denoted as 
∆UsrpB)
; and transmission time at GPMC bus (denoted as 
∆GPMC)
. 
∆
UHD is the time to fulfill samples to UHD buffer (Tx 
path) or the time to unpack packets (Rx path). For Tx path,
once the amount of data is sufficient for generating a GPMC 
packet (default packet size at 2kB), this packet is transmitted
using 
send_multiple_packet
mode. If the packet size is larger 
than the buffer size, the buffer is full even the packet is not 
generated yet, then 
send_one_packet
mode is activated. In this 
mode, packets are divided into small parts to be sent. For Rx
path, data in the buffer is transferred to GNU Radio whenever 
it is full, no matter how many packets are inside. The default 
UHD buffer size and GPMC packet size in USRP E100 are 
4kB and 2kB, respectively. The UHD buffer size is 
recommended as the multiple of packet size and can be 
changed by setting two parameters 
send_buff_size
and 
recv_buff_size
. 
∆
UsrpB is because of 2kB Tx/Rx FIFO GPMC buffers. 
USRP E100 uses memory-mapped ring mechanism for 
communicating between FPGA and memory through the 
GPMC bus. The size of each element in the ring buffer is 4kB.
Each element is also divided into 2kB blocks. Whenever a 
block is filled, it is activated to transmit by a polling 
mechanism without waiting for the whole 4kB element buffer 
to be full. 
To estimate the ∆GPMC, 
we use the 
benchmark_rate
utility 
in UHD to measure the maximum rates for GPMC buses. The 
result shows that the maximum data rate through GMPC is 
about 48Mbps (12Msps), thus the minimum ∆GPMC 
is s the 
size of data divide by 48Mbps. For instance, to transmit 4kB
data through GPMC bus, the minimum 
∆
GPMC is
4kB×8/48Mbps = 0.667ms. 
D. Latency in USRP device (
∆
hardware) 
The latency is because of buffering scheme at 4kB Tx/Rx 
FPGA FIFO buffers, controlled by the GPMC controllers. In 
Tx path, when USRP buffer receives a packet, the bus 
controller immediately transfers the packet to FPGA buffer 
before interpolating at FPGA Codecs to DAC and sends out via 
antenna. In this case, 
∆
hardware is negligible since all 
processes are implemented in hardware with high-speed system 
bus between USRP buffers and FPGA buffers. In Rx path, on 
the other hand, FPGA buffer is filling by the samples which are 
sampling from the antennas to generate GPMC packets before 
sending to USRP buffer. Assumed that the processing time at 
FPGA Codecs and ADC, and system bus delay are negligible. 
The 
∆
hardware in this case is proportional to the USRP sample 
rate. 
11
11

---

Fig. 2 presents latency analysis on the transmission and the 
reception of 4kB data on USRP E100 with default GPMC 
packet size (2kB). Assumed that the processor constantly 
generates samples at 2Msps for Tx and USRP sample rate for 
Rx is also at 2Msps. The GNU Radio processes samples from 
UHD buffer is at 8Msps. All the kernel-space/user-space 
interaction delays are negligible, 
Fig. 2. Tx/Rx 4kB Latency Analysis on GNU Radio/USRP E100 platforms
The Rx
∆
UHD is higher than Tx
∆
UHD because in Rx path, 
the 4kB Rx UHD buffer needs to be full before committing to 
GNU Radio. In Tx path, instead, 4kB Tx UHD buffer needs to 
collect only 2kB to generate GPMC packet before transmitting. 
The Tx UHD Buffer does not need to wait until it is full. The 
analysis indicates that in Tx path, the packet size plays an 
important role, contributes to Tx
∆
UHD. In Rx, instead, the 
UHD buffer size contributes to Rx
∆
UHD. 
IV. E
XPERIMENTAL 
L
ATENCY 
M
EASUREMENT ON 
GNU
R
ADIO
/USRP E100 P
LATFORMS
For experimentally measuring the latency in the SDR 
platforms, we use three approaches. The first approach is 
measuring the RTT by Linux 
ping
utility using the SDR 
platform. The second method is to timestamp at some places in 
the Tx/Rx path. The last approach is to measure the delay 
between FPGA and the memory of the E100 embedded system. 
A.
TUN/TAP with Tunnel Utility to Measure RTT
In the first approach, to establish a communication between 
two SDR platforms, a GNU Rradio utility called 
tunnel,
which 
allows tunneling any kinds of IP traffic through the SDR 
system, and Linux TUN/TAP modules are used. This utility 
creates a virtual Ethernet interface using the TUN/TAP 
modules. To measure the RTT, ping utility generates ICMP 
request packets and sends to the virtual Ethernet interface. The 
tunnel takes over the packets and sends to the network stack by 
injecting the packet using OS 
“write()”
operation. In Rx path, 
once USRP receives a packet, it revokes by a thread associated 
with PHY and passes the received packet up to the TUN/TAP 
interface via 
“
read()”
operation. Basically, the RTT in this case 
consists of application latencies (Linux processes, network 
stack, TUN/TAP components, read/write file descriptor) and 
SDR platform latency (Fig.3).