<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>