<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hello Luca</p>
<p><br>
</p>
<p>The current PGW is a policer. What the next version will be, I'm not sure. <br>
</p>
<p><br>
</p>
<p>However on parts of the Huawei RAN the policing rate is set to be a shaper speed on the eNodeB (radio antenna). 1000 packets deep. And it not only shapes down to 30Mb, but tries to aggregate packets to keep a level speed whenever using the radio interface.
Meaning holding back packets a bit to try and get to 30Mbit when sending in bulk in case of less than 30Mbit user traffic. 30Mbit being an example subscription speed.
<br>
</p>
<p><br>
</p>
<p>We are rolling out a fix to turn of that Huawei shaper, but it is not done nation wide yet.<br>
</p>
<p><br>
</p>
<p>The test device is in a lab area, using close to, but not entirely the same as production 5G setup from Ericsson. Here there should not be any shapers involved in the downstream path here. There is however a bloated buffer on the upstream path which we
are working on correcting. <br>
</p>
<p><br>
</p>
<p>The curl graphs are "time to complete a curl download of x file size", using a apache webserver running bbr.</p>
<p><br>
</p>
<p><br>
</p>
<p>-Erik<br>
</p>
<p><br>
</p>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>Fra:</b> Luca Muscariello <muscariello@ieee.org><br>
<b>Sendt:</b> 19. november 2020 14:32<br>
<b>Til:</b> Taraldsen Erik<br>
<b>Kopi:</b> Jesper Dangaard Brouer; priyarjha@google.com; bloat; Luca Muscariello<br>
<b>Emne:</b> Re: [Bloat] BBR implementations, knobs to turn?</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div class="gmail_default" style="font-family:monospace">Hi Erick,</div>
<div class="gmail_default" style="font-family:monospace"><br>
</div>
<div class="gmail_default" style="font-family:monospace">one question about the PGW: is it a policer or a shaper that you have installed?</div>
<div class="gmail_default" style="font-family:monospace">Also, have you tried to run a ping session before and in parallel to the curl sessions?</div>
<div class="gmail_default" style="font-family:monospace"><br>
</div>
<div class="gmail_default" style="font-family:monospace">Luca</div>
<div class="gmail_default" style="font-family:monospace"><br>
</div>
<div class="gmail_default" style="font-family:monospace"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Nov 19, 2020 at 2:15 PM <<a href="mailto:erik.taraldsen@telenor.com">erik.taraldsen@telenor.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
Update:<br>
The 5G router was connected to a new base station. Now the limiting factor of throughput is the policer on the PGW in mobile core, not the radio link itself. The SIM card used is limited to 30Mbit/s. This scenario favours the new server. I have attached
graphs comparing radio link limited vs PGW policer results, and a zoomed in graph of the policer<br>
<br>
<br>
We have Huawei RAN and Ericsson RAN, rate limited and not rate limited subscriptions, 4G and 5G access, and we are migrating to a new core with new PGW (policer). Starting to be a bit of a matrix to set up tests for.<br>
<br>
<br>
-Erik<br>
<br>
<br>
________________________________________<br>
Fra: Jesper Dangaard Brouer <<a href="mailto:brouer@redhat.com" target="_blank">brouer@redhat.com</a>><br>
Sendt: 17. november 2020 16:07<br>
Til: Taraldsen Erik; Priyaranjan Jha<br>
Kopi: <a href="mailto:brouer@redhat.com" target="_blank">brouer@redhat.com</a>; <a href="mailto:ncardwell@google.com" target="_blank">
ncardwell@google.com</a>; <a href="mailto:bloat@lists.bufferbloat.net" target="_blank">
bloat@lists.bufferbloat.net</a><br>
Emne: Re: [Bloat] BBR implementations, knobs to turn?<br>
<br>
On Tue, 17 Nov 2020 10:05:24 +0000 <<a href="mailto:erik.taraldsen@telenor.com" target="_blank">erik.taraldsen@telenor.com</a>> wrote:<br>
<br>
> Thank you for the response Neal<br>
<br>
Yes. And it is impressive how many highly qualified people are on the<br>
bufferbloat list.<br>
<br>
> old_hw # uname -r<br>
> 5.3.0-64-generic<br>
> (Ubuntu 19.10 on xenon workstation, integrated network card, 1Gbit<br>
> GPON access. Used as proof of concept from the lab at work)<br>
><br>
><br>
> new_hw # uname -r<br>
> 4.18.0-193.19.1.el8_2.x86_64<br>
> (Centos 8.2 on xenon rack server, discrete 10Gbit network card,<br>
> 40Gbit server farm link (low utilization on link), intended as fully<br>
> supported and run service. Not possible to have newer kernel and<br>
> still get service agreement in my organization)<br>
<br>
Let me help out here. The CentOS/RHEL8 kernels have a huge amount of<br>
backports. I've attached a patch/diff of net/ipv4/tcp_bbr.c changes<br>
missing in RHEL8.<br>
<br>
It looks like these patches are missing in CentOS/RHEL8:<br>
[1] <a href="https://git.kernel.org/torvalds/c/78dc70ebaa38aa3" rel="noreferrer" target="_blank">
https://git.kernel.org/torvalds/c/78dc70ebaa38aa3</a><br>
[2] <a href="https://git.kernel.org/torvalds/c/a87c83d5ee25cf7" rel="noreferrer" target="_blank">
https://git.kernel.org/torvalds/c/a87c83d5ee25cf7</a><br>
<br>
Could missing patch [1] result in the issue Erik is seeing?<br>
(It explicitly mentions improvements for WiFi...)<br>
<br>
--<br>
Best regards,<br>
Jesper Dangaard Brouer<br>
MSc.CS, Principal Kernel Engineer at Red Hat<br>
LinkedIn: <a href="http://www.linkedin.com/in/brouer" rel="noreferrer" target="_blank">
http://www.linkedin.com/in/brouer</a><br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote>
</div>
</div>
</div>
</body>
</html>