Yeah, and I’m probably drastically over-simplifiying and what not, but something about the scheduler seeing that you’re only moving itty bitty packets for pings and how it then schedules airtime. It’s supposedly being addressed in a future release, and you’ll see better and more consistent ping times if there’s other traffic moving that the pings can piggy back along.
From: [email protected] [mailto:[email protected]] On Behalf Of Nathan Anderson Sent: Sunday, June 19, 2016 2:40 AM To: [email protected] Subject: Re: [Telrad] Latency ? Did you ever get any response to this? -- Nathan From: [email protected] [mailto:[email protected]] On Behalf Of Shayne Lebrun Sent: Thursday, June 02, 2016 8:15 AM To: [email protected] Subject: Re: [Telrad] Latency ? We see the same thing; ping the UE from the gateway, pings are way better than pinging the gateway from the UE. I’ve opened a ticket with Telrad about it, we’ll see what they say. From: [email protected] [mailto:[email protected]] On Behalf Of Nathan Anderson Sent: Thursday, May 5, 2016 4:27 AM To: [email protected] Subject: Re: [Telrad] Latency ? Okay, so here are some test results taken from a connectorized UE jumpered directly to a Compact on a test bench. I ran two sets of pings: one directed towards the UE's WAN from outside of the EPC, and one from behind the UE directed at its gateway. Both sets of pings were happening simultaneously: they were started less than a second apart, and terminated less than a second apart. I used the exact same ping utility (busybox v1.11.2) for both sets to keep things as consistent as possible. The first set is from outside the EPC, aimed at the UE: # ping X.X.X.X PING X.X.X.X (X.X.X.X): 56 data bytes 64 bytes from X.X.X.X: seq=0 ttl=64 time=22.392 ms 64 bytes from X.X.X.X: seq=1 ttl=64 time=22.264 ms 64 bytes from X.X.X.X: seq=2 ttl=64 time=22.195 ms 64 bytes from X.X.X.X: seq=3 ttl=64 time=22.115 ms 64 bytes from X.X.X.X: seq=4 ttl=64 time=22.039 ms 64 bytes from X.X.X.X: seq=5 ttl=64 time=21.947 ms 64 bytes from X.X.X.X: seq=6 ttl=64 time=21.861 ms 64 bytes from X.X.X.X: seq=7 ttl=64 time=45.849 ms 64 bytes from X.X.X.X: seq=8 ttl=64 time=20.754 ms 64 bytes from X.X.X.X: seq=9 ttl=64 time=20.675 ms 64 bytes from X.X.X.X: seq=10 ttl=64 time=20.579 ms 64 bytes from X.X.X.X: seq=11 ttl=64 time=20.545 ms 64 bytes from X.X.X.X: seq=12 ttl=64 time=20.417 ms 64 bytes from X.X.X.X: seq=13 ttl=64 time=20.342 ms 64 bytes from X.X.X.X: seq=14 ttl=64 time=20.257 ms 64 bytes from X.X.X.X: seq=15 ttl=64 time=20.188 ms 64 bytes from X.X.X.X: seq=16 ttl=64 time=20.318 ms 64 bytes from X.X.X.X: seq=17 ttl=64 time=30.111 ms 64 bytes from X.X.X.X: seq=18 ttl=64 time=19.938 ms 64 bytes from X.X.X.X: seq=19 ttl=64 time=19.864 ms 64 bytes from X.X.X.X: seq=20 ttl=64 time=19.782 ms ^C --- X.X.X.X ping statistics --- 21 packets transmitted, 21 packets received, 0% packet loss round-trip min/avg/max = 19.782/22.592/45.849 ms The second set is from a host behind the UE, aimed at its default gateway: # ping X.X.X.1 PING X.X.X.1 (X.X.X.1): 56 data bytes 64 bytes from X.X.X.1: seq=0 ttl=63 time=25.990 ms 64 bytes from X.X.X.1: seq=1 ttl=63 time=23.539 ms 64 bytes from X.X.X.1: seq=2 ttl=63 time=48.543 ms 64 bytes from X.X.X.1: seq=3 ttl=63 time=84.442 ms 64 bytes from X.X.X.1: seq=4 ttl=63 time=40.399 ms 64 bytes from X.X.X.1: seq=5 ttl=63 time=76.254 ms 64 bytes from X.X.X.1: seq=6 ttl=63 time=32.215 ms 64 bytes from X.X.X.1: seq=7 ttl=63 time=18.079 ms 64 bytes from X.X.X.1: seq=8 ttl=63 time=104.120 ms 64 bytes from X.X.X.1: seq=9 ttl=63 time=60.024 ms 64 bytes from X.X.X.1: seq=10 ttl=63 time=95.929 ms 64 bytes from X.X.X.1: seq=11 ttl=63 time=51.792 ms 64 bytes from X.X.X.1: seq=12 ttl=63 time=87.808 ms 64 bytes from X.X.X.1: seq=13 ttl=63 time=43.642 ms 64 bytes from X.X.X.1: seq=14 ttl=63 time=79.552 ms 64 bytes from X.X.X.1: seq=15 ttl=63 time=35.511 ms 64 bytes from X.X.X.1: seq=16 ttl=63 time=71.428 ms 64 bytes from X.X.X.1: seq=17 ttl=63 time=17.340 ms 64 bytes from X.X.X.1: seq=18 ttl=63 time=63.279 ms 64 bytes from X.X.X.1: seq=19 ttl=63 time=89.245 ms 64 bytes from X.X.X.1: seq=20 ttl=63 time=55.202 ms ^C --- X.X.X.1 ping statistics --- 21 packets transmitted, 21 packets received, 0% packet loss round-trip min/avg/max = 17.340/57.349/104.120 ms The UE was not moving any network traffic at the time of the test except for the pings and the small amount needed to echo the results of the ping test that was happening behind the UE back to me over an SSH session. The parameters for the network were QCI 6, 15MHz channel, cell-radius 10km, subframe profile 1, special-subframe profile 3. UE consistently achieved full modulation in both directions. Regardless of whether your single-channel split-mode with antennas not aimed exactly 180 degrees away from each other is unsupported or not (it is), or whether using that configuration has the potential to cause Bad Things(tm) to happen (it does), I think we can safely say that it is irrelevant as far as the RTT discrepancy you are observing goes. This is something that you see on a lab system in an isolated and controlled environment. -- Nathan From: [email protected] [mailto:[email protected]] On Behalf Of Nathan Anderson Sent: Wednesday, May 04, 2016 7:03 AM To: Telrad List Subject: Re: [Telrad] Latency ? I can't say for sure, but I rather doubt that this phenomenon is attributable (at least in your case) to your split sector deployment. Given that we are seeing similar things and we are not using split sector, and that you continued to see widely variable results after shutting down the other 2 RF ports, it just seems highly unlikely that they are related. The RTT results you detailed in this last message & initiated from UE look very similar to what we see, although I have never seen it jump as high as 185. Later on, I will try coax-cabling a UE up to a Compact directly and see if the results are any different, and post back with the results. That would at least eliminate an imperfect RF environment as a variable. -- Nathan From: [email protected] [mailto:[email protected]] On Behalf Of Ian Fraser Sent: Wednesday, May 04, 2016 6:37 AM To: [email protected] Subject: Re: [Telrad] Latency ? The router is a CCR1009-8G-1S running 6.32.2. ICMP to/from any device on the LAN segment returns 0ms. This eNB is running in Split Sector with Alpha 65 degree antennas. Vertical separation is nill. Horizontal separation is about 60". They are offset about 120 degrees from one and other. Nick informed me yesterday that this configuration is not supported and may be the cause of the problem. I had a tech testing yesterday on QCI 6 with RAN 3&4 running and then shutdown. His perception was that idle ping from the UE to the Router Interface facing the EPC was more consistent although it still oscillated from like 44, 81, 31, 183, 64, 105, 95, 28, 85 etc. with RAN 3&4 disabled. I'm not well versed but the KPI's from the test period did not show any significant differences in error rates or retransmissions, with or without the second sector disabled, that I could see. Speedtest's graph did look to be more consistent with RAN 3&4 off though. Anyone else running a similar physical deployment ? Thanks Ian On 5/3/2016 8:00 PM, Nathan Anderson wrote: Ian is talking about initiating a ping from the outside to the UE vs. initiating a ping from the UE (or behind the UE) to the outside, and I'm not sure from your response whether you were interacting with that distinction or not? We have also noticed a similar phenomenon, although the RTT for us when initiating from the UE doesn't seem as drastic as Ian described. Average RTT from outside to UE when that particular UE is relatively idle is usually around 25ms. Average RTT from the UE to outside (gateway router on our network) is about 60ms or so, but it can oscillate pretty wildly within a range from the mid-20s to about 100. So what the customer sees while running a ping test is measurably worse than what we see when we run a ping test to the customer. (That Ian is seeing higher RTT to a gateway device internal to his network vs. a host out on the internet makes me wonder if his router is simply not prioritizing self-generated ICMP responses vs. forwarding traffic; the 120ms+ he is reguarly seeing might be an optical illusion of sorts.) Despite this, we really haven't had any issues directly attributable to this, so I haven't been super-concerned thus far. I wonder if it has something to do with the timing of how download & upload slots are allocated, and perhaps if we were using a subframe profile with a more even down/up ratio, the difference might be reduced? As far as the question about gaming goes, one of my coworkers is apparently a fairly avid gamer, and we stuck him on Telrad LTE and he says it has been rock-solid for him, no complaints, A++ experience. In contrast, we had a user that we installed during the trial who constantly griped about gaming performance, but unfortunately when it came to trying to troubleshoot his issues, he was more than unhelpful. (He is no longer on the network.) I suppose if you have any complainers, it might be worth a shot trying QCI 7 to see what effect that has on that customer's experience. -- Nathan From: [email protected] [mailto:[email protected]] On Behalf Of Matthew Carpenter Sent: Tuesday, May 03, 2016 7:08 AM To: Telrad List Subject: Re: [Telrad] Latency ? Those are close to the same numbers I see here. Ping times will stay down around 30-40ms, until the UE starts to transmit. Then ping times will jump to around 100ms and higher. The QCI is set for 6 (non-GBR) with a packet delay budget of up to 300ms. So at anytime the ping times could move around up to 300ms. Matt Carpenter Amarillo Wireless On Mon, May 2, 2016 at 1:24 PM, Ian Fraser <[email protected]> wrote: With the UE in NAT mode and the EPC co-located at the tower site what should typical latency be from the Client PC to the Router Interface facing the EPC at the Site? I see typically 22 to 26ms from the Router at the tower side to the UE's public IP. But from Client PC > UE > eNB> EPC> Router interface it's 80 to 100ms or higher. This is an eNB with no other UE's on it, and range is set for 30km. UE has no load on it. Oddly the 'ping' on speedtest.net comes in, in the 50 to 60ms range with the Headend is 2 hops away, but pinging the Headend IP from the Client PC is 120ms or more. Cheers, Ian _______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> https://ipmcdn.avast.com/images/2016/icons/icon-envelope-tick-round-orange-v1.png Virus-free. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> www.avast.com
_______________________________________________ Telrad mailing list [email protected] http://lists.wispa.org/mailman/listinfo/telrad
