We routinely operate in the 200 usec window, so if the best you can do is 20 
milli-seconds, there is something you are not doing very well in your 
application.


1Gb ethernet is not helping but is not the source of multi-millisecond delays.


We run on windows with a 2667 Xeon processor and intel 710-DA2 NIC.

> On July 5, 2018 at 11:26 AM Keith k via USRP-users 
> <[email protected]> wrote:
> 
>     Hello Hojoon
> 
>     I've also been battling this issue. A couple other things you are going 
> to need to be aware of is even though your application has two threads that 
> you program, UHD also spawns its own threads to control the USRP and they are 
> quite hungry for resources. Something that has been helping me is to isolate 
> cpu cores and purely dedicate my UHD applications to run on those isolated 
> cores.
> 
>     On Thu, Jul 5, 2018 at 2:25 PM, Hojoon Yang via USRP-users 
> <[email protected] mailto:[email protected] > wrote:
> 
>         > >         Hi, Derek.
> >         Thanks for detailed answer.
> >          
> >         I'm using ubuntu 14.04 and kernel version 4.2.0-42-generic and USRP 
> > X300 with two UBX-160 which is connected to the host PC via 1G ethernet.
> > 
> >         In my application, the lowest delta value that works reliably is 
> > 20ms. The definition of reliability means that there is no 'L' for one 
> > minute during the execution of the application.
> > 
> >         I want the delta value to be 3~4 ms.
> > 
> >         so, since the problem is latency in OS side, I cannot improve the 
> > delta value even if I upgrade my host PC to good one. Am I right?
> > 
> >         the number of thread in the application may affect the latency? My 
> > application use two thread only. Since there are 4 cores in my host PC, I 
> > believe it barely affects the latency.
> > 
> >         To sum it up, to achieve 3~4 ms delta value (based on your delta 
> > value(5~20ms), I believe 3~4ms delta can be achieved), I should change the 
> > OS in the host PC to low latency linux kernel.
> > 
> >         Please correct me if I'm wrong. Thanks again!
> >          
> >          
> > 
> >             > > >             ----------------------- Original 
> > Message-----------------------
> > >             From: Derek Kozel < [email protected] 
> > > mailto:[email protected] >
> > >             To: Hojoon Yang < [email protected] 
> > > mailto:[email protected] >
> > >             CC: usrp-users < [email protected] 
> > > mailto:[email protected] >
> > >             Sent date: 2018-07-05 22:11:03 GMT +0900 (ROK)
> > >             Subject: Re: [USRP-users] timed transmission LATE issue
> > > 
> > >             Hello Hojoon,
> > > 
> > >             You will have to profile your system to determine the minimum 
> > > delta that works reliably on your system, as well as choosing a 
> > > definition for reliable. Networking stacks nearly always have stochastic 
> > > delays due to the various context switches and scheduling issues with 
> > > transferring data to and from a user program and the actual network 
> > > hardware. On the USRP side the FPGA provides a much more deterministic 
> > > behavior because the logic is exclusively serving the network traffic. 
> > > The DRAM buffer on the transmit side is there to absorb some of the 
> > > variability of the host computer network stack, but it can only do that 
> > > if there is enough time delay between samples being sent by the program 
> > > and when the DAC must be producing the associated analog signal.
> > > 
> > >             In practice I have always used a few (5-20) ms and found it 
> > > to be reliable for transmissions lasting up to an hour, but you will have 
> > > to test your specific setup. Different OS network stacks have different 
> > > options for tuning to reduce both the average and peak latency of the 
> > > network drivers. I'm not an expert in them but there are a variety of 
> > > good resources online. In applications demanding both small latency and 
> > > high reliability moving to a realtime Linux environment can help in 
> > > meeting those hard deadlines. I believe that some of the LTE and GSM 
> > > projects have been successful with that approach.
> > > 
> > >             Regards,
> > >             Derek
> > > 
> > >             On Thu, Jul 5, 2018 at 12:34 PM, Hojoon Yang via USRP-users 
> > > <[email protected] mailto:[email protected] > wrote:
> > > 
> > >                 > > > >                 Hi,
> > > >                  
> > > >                 I am using USRP X310 with two UBX-160 daughterboards.
> > > >                  
> > > >                 In my application, I am using timed transmission, for 
> > > > example,
> > > >                  
> > > >                 start transmission at (usrp_get_time_now() + delta)
> > > >                  
> > > >                 My question is, what is the smallest delta value that 
> > > > can be successful in the *real world*? Theoretically, the delta can be 
> > > > any value, if the host can send the packet to the USRP fast enough.
> > > > 
> > > >                 Suppose we have a PC which have i7-8700k CPU and the PC 
> > > > only runs this application. when I set the delta 1ms, Can I avoid late 
> > > > 'L'?
> > > > 
> > > >                 Best regards,
> > > >                 Hojoon
> > > > 
> > > >                 ______________________________ _________________
> > > >                 USRP-users mailing list
> > > >                 [email protected] 
> > > > mailto:[email protected]
> > > >                 
> > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 
> > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > > > 
> > > > 
> > > >             > > > 
> > > 
> > >         > > 
> >         ______________________________ _________________
> >         USRP-users mailing list
> >         [email protected] mailto:[email protected]
> >         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > 
> > 
> >     > 
> 
> 
>     --
>     -Keith Kotyk
>     _______________________________________________
>     USRP-users mailing list
>     [email protected]
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to