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 <
usrp-users@lists.ettus.com> 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 <derek.ko...@ettus.com>
> To: Hojoon Yang <omnibu...@kaist.ac.kr>
> CC: usrp-users <usrp-users@lists.ettus.com>
> 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 <
> usrp-users@lists.ettus.com> 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
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


-- 
-Keith Kotyk
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to