[srslte-users] Measuring latency

[Steffen Heber]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20181103/73fd075f/attachment.htm>