[srsran-users] R: Periodic latency oscillations in srsenb

[Corrado Puligheddu]

Hi all,

I just want to add that I also observed the same behaviour in srsLTE 19.09 and unfortunately I still don’t know what is causing it.
Interestingly, the latency values are somehow related to the probing periodicity.

https://lists.srsran.com/pipermail/srsran-users/2020-May/003608.html

Regards,
Corrado

Da: Sackman (US), Ronald W
Inviato: mercoledì 1 febbraio 2023 11:10
A: Serhat Arslan; srsran-users at lists.srsran.com
Cc: Ali Abedi
Oggetto: Re: [srsran-users] Periodic latency oscillations in srsenb

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20230201/dab32ec6/attachment.htm>