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

“sent_buf_size”,
and 
“recv_buf_size”
. The buffer size is 
chosen among five values: 1024, 2048, 4096 and 16.384 byte. 
The ICMP packet header at the MAC layer is 64B and we add 
4032B payload more, thus, the ICMP packet is 4kB in total. 
The RTT results are shown in Fig.5. 
Fig. 5. 
RTT MEAN Latency and Standard Deviation on USRP E100 
platforms 
It is important to note that in Tx side, USRP FIFOs/SRAM 
performs all of the buffering. Consequently, we cannot really 
buffer anything in the embedded computer. The Linux kernel 
in the embedded computer just waits for the notification that 
space is available in the USRP before committing more 
packets. In Rx side, GPMC driver performs all the buffering. 
Therefore the USRP sample rate does not play a role in case of 
buffering scheme. However, it contributes much to the latency 
of generating samples. 
The effect of UHD buffer sizes on GNU Radio/USRP1 
platform is mentioned in [18, 19]. By our experiment on USRP 
E100, Tx UHD Buffer size 
“sent_buf_size”
has no role in the 
Tx latency. It is because when samples are collected enough to 
generate a packet, it is sent right away without waiting for Tx 
UHD buffer to get full. In the other hand, Rx buffer size 
“
recv_buf_size”
plays a key role to the latency since samples 
received from GPMC bus are moved to this buffer. When the 
Rx UHD buffer is fulfilled, samples are transmitted to the GNU 
Radio. It is the same as our analytical latency in the section III. 
In the case of timestamp approach, we create two programs, 
one is very simple Tx program called 
hw_latency_test
with no 
GNU Radio component, generating sample from UHD driver. 
Its purpose is to reduce the delay introduced in GNU Radio 
software. Another is a GNU Radio program named 
full_latency_test
which leverages some SDR radio components 
such as QAM modulation, filters, and decoders. Because of 
three places that we put the timestamp, the results indicate 
three components 
∆
software, 
∆
UHD + 
∆
UsrpB and 
∆
GPMC + 
∆
hardware (Fig.6). 
Fig. 6. 
MEAN Tx latency results of timestamp approaches 
We transmit 512 samples (4kB) and conduct 1000 trials to 
get the average latency and standard deviation for each part of 
the latency. It shows that the experimental results of the 
(
∆
UHD + 
∆
UsrpB) and (
∆
GPMC + 
∆
hardware) are just little 
higher than the analytical latency in the section III (Fig.6). 
In case of the approximation approach, we conducted 100
tests with different 
rt
time values by calculating the number of 
successful transmissions as well as the number of failures. In 
order to compare with the analytical latency results and the two 
other experimental methods, we also choose the same 
parameters: 1024 samples (4kB) to transmit at 2Msps USRP 
sample rate. The results are the total latency of the bus 
transmission and USRP hardware: 
∆
bus + 
∆
hardware (Fig.7). 
13
13

---

Fig. 7. The total bus and hardware latency results from experimental and 
analytical approaches 
The latency in the timestamp method (1.480ms) is smaller 
than the approximation method (1.495). The latency from 
analytical approach is the smallest (1.417). It is reasonable 
because when analyzing the latency, we can only estimate the 
minimum 
∆
GPMC. The experimental 
∆
GPMC could be 
different. The timestamp method could be increased due to the 
timestamp procedure running along with the main program. In
the approximation approach, the approximated time 
rt
is 
always higher than the real latency. This is the understandable 
reason for the different results between two experimental 
approaches. 
For the relations between RTT and the latency from other 
two approaches, note that when the UHD buffer size is equal to
GPMC packet size (4kB for example), we can assume that the 
Tx latency = Rx latency. In this case, whenever an ICMP 
packet is received, the Rx UHD buffer gets full and 
immediately transfers the data to GNU Radio. Therefore, RTT 
= 2*(Tx latency + Rx latency). In other words, Tx latency = Rx 
latency = RTT/4 = 4.75ms.
Besides ∆bus
(0.667ms) and 
∆hardware
(0.25 + 0.25 = 0.5ms)
, ∆software in this case 
contains the time for reading and conducting TUN/TAP file 
descriptor, reading and processing 4kB ICMP packets into 
samples, user-space and kernel-space interaction. Assumed that 
GNU Radio processes samples at the rate 2Msps, thus, it takes 
at least 0.5ms to generate a 4kB ICMP packet. Thus, the delay 
due to the TUN/TAP component and 
ping
utility is about 
3.083ms. The results basically show that the time for 
processing at the host computer dominates the whole latency of 
the GNU Radio/USRP E100 SDR platform. 
A
CKNOWLEDGMENT
This research was supported by World Class University 
program funded by the Ministry of Education, Science and 
Technology through the National Research Foundation of 
Korea (R31-10100). 
R
EFERENCES
[1] Ettus Research LLC., 
“Universal Software Radio Peripherals”, 
http://www.ettus.com. 
[2] GNU Radio.,
http://gnuradio.org/redmine/projects/gnuradio/wiki. 
[3]
Wikipedia., ”Software Defined Radio”, 
http://en.wikipedia.org/wiki/Software-defined_radio. 
[4] M. Cummings and S. Haruyama., 
“FPGA in the software radio”, 
IEEE Communications Magazine, 1999. 
[5]
“WARP: Wireless open Access Research Platform”, 
http://warp.rice.edu/trac. 
[6] ANSI/IEEE std 802.11 part 11.
, “Wireless LAN medium access 
control (MAC) and Physical Layer (PHY) Specification”, IEEE 
press, 1999. 
[7]
K. Tan, J.Fang, J.Fang, et al., “SORA: High Performance 
Software Radio Using General Purpose Multi-core Proce
ssors”, 
6th USENIX Symposium on Networked Systems Design and 
Implementation 2009, USENIX, 2009. 
[8]
T. Schmid. O. Sekkat, and M. Srivastava., “An experimental 
study of network performance impact of increased latency in 
SDRs”, WiNTECH’07, 2007.
[9] S. Valentin, H. 
von Malm, and H. Karl., “Evaluating the gnu 
software radio platform for wireless testbeds”, Technical Report 
TR-RT-06-273, 2006. 
[10] G. Nychis, T. Hottelier, Z. Yang, S. Seshan and P. Steenkiste., 
“Enabling Mac protocol implementations on Software
-Defined 
Radi
os”, Proceedings of the 6
th USENIX Symposium on 
Networked Systems Design and Implementation, USENIX, 
2009. 
[11]
Y. Lin, Hyunseok Lee, Yoav Harel, Mark Woh, et al., “SODA: 
A low-
power architecture for software radio”. Proceedings of 
the 33rd International Symposium on Computer Architecture, 
ISCA, vol.1, pp. 89-100, 2006. 
[12]
A. Jow, C. Schurgers, and D. Palmer., “CalRadio: A Portable, 
Flexible 802.11 Wireless Research Platform”, 1st International 
Workshop System Evaluation for Mobile Platforms, San Juan, 
Puerto Rico, 2007. 
[13]
Wikipedia., “Universal Software Radio Peripheral”, 
http://en.wikipedia.org/wiki/Universal_Software_Radio_Periphe
ral. 
[14]
L. Choong., “Multi
-channel IEEE 802.15.4 packet capture using 
software defined radio”, UCLA Networked and Embedded 
Sensing Lab, 2009.
[15]
Ettus Company LLC., “Daughterboard products“, 
https://www.ettus.com/product/category/Daughterboards.
[16]
Universal Hardware Driver., “wiki”, 
http://ettus-
apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki. 
[17] TUN/TAP Interface Tutorial., 
http://backreference.org/2010/03/26/tuntap-interface-tutorial/. 
[18]
J.C. O’Sullivan, P. Di Francesco, U.K. Anyanwu, L. A. DaSilva, 
and A. B. MacKenzie., “Multi
-hop MAC Implementations for 
Affordable SDR Hardware”, 
IEEE Symposia on New Frontiers 
on Dynamic Spectrum Access Networks (DySPAN). poster 
paper, pp. 632-636, 2011. 
[19] A. Puschmann
,
M. Kalil and A. Mitschele-Thiel.,
“Implementation and Evaluation of a Practical SDR Testbed”
,
4th International Conference on Cognitive Radio and Advanced 
Spectrum Management (CogART), 2011. 
[20] P.D. Sutton, J. Lotze, H. Lahlou, S.A. Fahmy, K.E. Nolan, B. 
Ozgul, T.W Rondeau, J. Noguera, L.E Doyle.,
“
Iris: An 
Architecture for Cognitive Radio Networking Testbeds
”,
IEEE 
Communications Magazine, vol. 48, 2010.
14
14