[srsran-users] Periodic latency oscillations in srsenb

Wed Feb 1 10:49:16 UTC 2023

Hello,

We had the same issue with another implementation when trying to measure
the effect of some security settings on latency. We figured that this is
caused by physical frame timing; indeed when looking at the absolute
arrival times of downlink ping messages modulo the frame length all
messages arrived at the same offset. The downlink ping message will always
arrive in a certain (small) number of frames, and the time it takes for
that frame to be ready will overshadow a lot of other effects. We
circumvented this pattern by setting the interval in the ping command to
not align with any frame timings (107 ms in our case).

Best,
Thijs Heijligenberg

On Wed, Feb 1, 2023 at 11:08 AM Sackman (US), Ronald W <
ronald.w.sackman at boeing.com> wrote:

> Hello Serhat,
>
>
>
> Unfortunately I do not know the fix for this, but just wanted to say that
> we have observed this same latency
>
> behavior running SRSRAN 21.10.1.  It complicates our TCP throughput
> performance testing, please let us know
>
> if you determine the root cause and/or a fix.
>
>
>
> Thank you,
>
> Ron
>
>
>
> *From:* srsran-users <srsran-users-bounces at lists.srsran.com> *On Behalf
> Of *Serhat Arslan
> *Sent:* Monday, January 30, 2023 10:14 AM
> *To:* srsran-users at lists.srsran.com
> *Cc:* Ali Abedi <abedi at stanford.edu>
> *Subject:* [EXTERNAL] Re: [srsran-users] Periodic latency oscillations in
> srsenb
>
>
>
> EXT email: be mindful of links/attachments.
>
>
>
>
> Hi,
>
> We are using srsLTE v20.04 for some experiments and we are able to connect
> our multiple Samsung phones (different models) to Internet through our
> srsenb. However something has attracted our attention that we are surprised
> to see.
>
> When we ping the server that is running the srsenb and srsepc from our UE,
> we get latency readings that are decreasing each second until it hits ~20ms
> and then immediately jumps back to ~60ms. Then it repeats this cycle. The
> UE is stationary right next to our software radio and there is no other
> traffic in the network. An exemplary output of the pings are shared below.
>
> We have also tested this in v22.10, but the behavior didn’t change despite
> a little decrease in the latency values. Does anyone have an idea why the
> latency varies this way, and is there a way to make it more stable, ie.
> with some configuration etc.?
>
> Regards,
>
> Serhat Arslan
>
> 64 bytes from 172.16.0.4: icmp_seq=234 ttl=64 time=59.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=235 ttl=64 time=58.0 ms
> 64 bytes from 172.16.0.4: icmp_seq=236 ttl=64 time=56.5 ms
> 64 bytes from 172.16.0.4: icmp_seq=237 ttl=64 time=54.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=238 ttl=64 time=52.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=239 ttl=64 time=51.6 ms
> 64 bytes from 172.16.0.4: icmp_seq=240 ttl=64 time=49.6 ms
> 64 bytes from 172.16.0.4: icmp_seq=241 ttl=64 time=47.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=242 ttl=64 time=46.5 ms
> 64 bytes from 172.16.0.4: icmp_seq=243 ttl=64 time=44.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=244 ttl=64 time=42.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=245 ttl=64 time=41.4 ms
> 64 bytes from 172.16.0.4: icmp_seq=246 ttl=64 time=39.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=247 ttl=64 time=38.0 ms
> 64 bytes from 172.16.0.4: icmp_seq=248 ttl=64 time=36.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=249 ttl=64 time=35.3 ms
> 64 bytes from 172.16.0.4: icmp_seq=250 ttl=64 time=34.1 ms
> 64 bytes from 172.16.0.4: icmp_seq=251 ttl=64 time=32.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=252 ttl=64 time=31.2 ms
> 64 bytes from 172.16.0.4: icmp_seq=253 ttl=64 time=30.0 ms
> 64 bytes from 172.16.0.4: icmp_seq=254 ttl=64 time=27.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=255 ttl=64 time=26.3 ms
> 64 bytes from 172.16.0.4: icmp_seq=256 ttl=64 time=24.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=257 ttl=64 time=22.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=258 ttl=64 time=22.2 ms
> 64 bytes from 172.16.0.4: icmp_seq=259 ttl=64 time=20.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=260 ttl=64 time=18.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=261 ttl=64 time=56.9 ms
> 64 bytes from 172.16.0.4: icmp_seq=262 ttl=64 time=55.6 ms
> 64 bytes from 172.16.0.4: icmp_seq=263 ttl=64 time=54.2 ms
> 64 bytes from 172.16.0.4: icmp_seq=264 ttl=64 time=52.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=265 ttl=64 time=51.5 ms
> 64 bytes from 172.16.0.4: icmp_seq=266 ttl=64 time=50.4 ms
> 64 bytes from 172.16.0.4: icmp_seq=267 ttl=64 time=48.5 ms
> 64 bytes from 172.16.0.4: icmp_seq=268 ttl=64 time=47.5 ms
> 64 bytes from 172.16.0.4: icmp_seq=269 ttl=64 time=45.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=270 ttl=64 time=43.6 ms
> 64 bytes from 172.16.0.4: icmp_seq=271 ttl=64 time=42.4 ms
> 64 bytes from 172.16.0.4: icmp_seq=272 ttl=64 time=40.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=273 ttl=64 time=38.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=274 ttl=64 time=37.4 ms
> 64 bytes from 172.16.0.4: icmp_seq=275 ttl=64 time=35.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=276 ttl=64 time=33.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=277 ttl=64 time=32.4 ms
> 64 bytes from 172.16.0.4: icmp_seq=278 ttl=64 time=30.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=279 ttl=64 time=28.8 ms
> 64 bytes from 172.16.0.4: icmp_seq=280 ttl=64 time=27.5 ms
> 64 bytes from 172.16.0.4: icmp_seq=281 ttl=64 time=25.6 ms
> 64 bytes from 172.16.0.4: icmp_seq=282 ttl=64 time=23.4 ms
> 64 bytes from 172.16.0.4: icmp_seq=283 ttl=64 time=21.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=284 ttl=64 time=20.5 ms
> 64 bytes from 172.16.0.4: icmp_seq=285 ttl=64 time=18.7 ms
> 64 bytes from 172.16.0.4: icmp_seq=286 ttl=64 time=56.9 ms
> 64 bytes from 172.16.0.4: icmp_seq=287 ttl=64 time=54.6 ms
> 64 bytes from 172.16.0.4: icmp_seq=288 ttl=64 time=53.3 ms
>
>
>
>
> _______________________________________________
> srsran-users mailing list
> srsran-users at lists.srsran.com
>
> https://urldefense.com/v3/__https://lists.srsran.com/mailman/listinfo/srsran-users__;!!HJOPV4FYYWzcc1jazlU!_93P03YX9uZ0-2KA-gOLAFzXJ7R15VesfJU1Br9YngW9nlFGbvMFE_4QREpKlgjqWOSNZWfz_IPt7gi-APdIbFj7C1Z5JiUm$
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20230201/0c5d72ee/attachment-0001.htm>