[srslte-users] Measuring latency

Kewin Rausch krausch at fbk.eu
Sat Nov 3 17:20:19 UTC 2018


Sure no problem Hopeful Steffen,
have a nice programming. :-D

Cheers,
Kewin R.

On Sat, Nov 3, 2018 at 6:16 PM Steffen Heber <hopeless.heber at gmail.com>
wrote:

> Hi Kewin and Andre,
>
> Thanks for the trick. I tried using the network time protocol (ntp) and
> seems like it is working now. I really appreciate the feedback from you
> guys. That makes me little hopeful ;)
>
> Thanks,
> Hopeless Heber
>
> On Thu, Nov 1, 2018 at 3:24 AM Kewin Rausch <krausch at fbk.eu> wrote:
>
>> Hi Steffen,
>>
>> Have you considered using the TTI as tick counter? The signal must be
>> coherent or otherwise the two devices cannot keep the connection enabled.
>> If the PCs have no such precise counter, why not using the signal itself
>> (which means using usrp hw)?
>>
>> i.e: if 300 TTI are counted, then 300 milliseconds elapsed.
>>
>> Be careful that this is not always a good solution to use; depends on
>> what are you trying to do!
>>
>> Cheers,
>> Kewin R.
>>
>> On Wed, Oct 31, 2018, 7:55 PM Steffen Heber <hopeless.heber at gmail.com>
>> wrote:
>>
>>> Hi Andre and Kewin,
>>>
>>> Thank you for your suggestions.
>>>
>>> @Andre: Can you please give me any pointers for increasing the grant
>>> size of enodeb?
>>> @Kewin: As soon as I sync the time (i.e., get the time from internet), I
>>> found the hour, minute, and second same across two machines. However, after
>>> a certain time interval, there is a time drift (in millisecond range)
>>> between two machines.
>>>
>>>
>>> Thanks,
>>> Steffen
>>>
>>>
>>>
>>> On Wed, Oct 31, 2018 at 6:04 AM Kewin Rausch <krausch at fbk.eu> wrote:
>>>
>>>> Hi Hopeless Heber, :-D
>>>>
>>>> did you check that the time stamps are fine? I mean, are the machine
>>>> synced with times? Small differences can impact the computation.
>>>> So maybe receiver and transmitter are doing their tasks, but since the
>>>> timing does not have a common base (not synchronized), the final delta is
>>>> wrong.
>>>>
>>>> Cheers,
>>>> Kewin R.
>>>>
>>>> On Wed, Oct 31, 2018 at 10:56 AM Steffen Heber <
>>>> hopeless.heber at gmail.com> wrote:
>>>>
>>>>>
>>>>> I have added a couple of new fileds in one of RRC layer meassges and
>>>>> wanted to measure the end-to-end transmission delay/latency of that message
>>>>> because of additional fields. To achieve that I did the following: synced
>>>>> the time of sender and the receiver machines to the local timezone; used
>>>>> gettimeofday function to find the timestamps of message transmission (t1)
>>>>> and reception (t2) at the sender and the receiver; the transmission
>>>>> timestamp (t1) was included in the message so that the receiver can compute
>>>>> the latency, i.e., delta=t2-t1. Unfortunately, I always found delta less
>>>>> than 0 ms.
>>>>>
>>>>> Could anyone please give me any pointers to what I am doing wrong or a
>>>>> better way to compute the latency of the message?
>>>>>
>>>>> Thanks,
>>>>> Steffen
>>>>> _______________________________________________
>>>>> srslte-users mailing list
>>>>> srslte-users at lists.softwareradiosystems.com
>>>>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>>>>
>>>>
>>>> --
>>>> Le informazioni contenute nella presente comunicazione sono di natura privata
>>>> e come tali sono da considerarsi riservate ed indirizzate esclusivamente
>>>> ai destinatari indicati e per le finalità strettamente legate al
>>>> relativo contenuto. Se avete ricevuto questo messaggio per errore, vi
>>>> preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo
>>>> e-mail del mittente.
>>>> --
>>>> The information transmitted is intended only for the person or entity
>>>> to which it is addressed and may contain confidential and/or privileged
>>>> material. If you received this in error, please contact the sender and
>>>> delete the material.
>>>>
>>>
>> --
>> Le informazioni contenute nella presente comunicazione sono di natura privata
>> e come tali sono da considerarsi riservate ed indirizzate esclusivamente
>> ai destinatari indicati e per le finalità strettamente legate al
>> relativo contenuto. Se avete ricevuto questo messaggio per errore, vi
>> preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo
>> e-mail del mittente.
>> --
>> The information transmitted is intended only for the person or entity to
>> which it is addressed and may contain confidential and/or privileged
>> material. If you received this in error, please contact the sender and
>> delete the material.
>>
>

-- 
--
Le informazioni contenute nella presente comunicazione sono di natura 
privata e come tali sono da considerarsi riservate ed indirizzate 
esclusivamente ai destinatari indicati e per le finalità strettamente 
legate al relativo contenuto. Se avete ricevuto questo messaggio per 
errore, vi preghiamo di eliminarlo e di inviare una comunicazione 
all’indirizzo e-mail del mittente.

--
The information transmitted is 
intended only for the person or entity to which it is addressed and may 
contain confidential and/or privileged material. If you received this in 
error, please contact the sender and delete the material.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20181103/2946bebc/attachment.htm>


More information about the srsran-users mailing list