Re: [Bloat] vyatta in AT&T 5G gear
On Mon, 15 Oct 2018, Dave Taht wrote: Vyos (the open source fork of vyatta) was one of the first to add fq_codel support... I wonder http://linuxgizmos.com/att-releases-white-box-spec-for-its-linux-based-5g-routers/ Isn't Vyos just running the Linux kernel for forwarding? So they received fq_codel for free when the Linux kernel got support for it? They just had to make it configurable? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] vyatta in AT&T 5G gear
On 2018-10-16 11:31, Mikael Abrahamsson wrote: On Mon, 15 Oct 2018, Dave Taht wrote: Vyos (the open source fork of vyatta) was one of the first to add fq_codel support... I wonder http://linuxgizmos.com/att-releases-white-box-spec-for-its-linux-based-5g-routers/ Isn't Vyos just running the Linux kernel for forwarding? So they received fq_codel for free when the Linux kernel got support for it? They just had to make it configurable? Yes, according to this blog post, http://www.five-ten-sg.com/mapper/blog/Bufferbloat%20solved%20with%20Vyos "Now that Vyos "helium" is available with a Linux 3.13 kernel, the fq_codel queueing discipline can be used to solve many bufferbloat issues. The nightly "lithium" builds contain my patches that allow fq_codel to be used via the native Vyos configuration system." Anyway it's nice to see the Vyatta heritage living on in it's various forms (the AT&T "production hardened" Vyatta, to the Ubiquity EdgeMax and some UniFi devices, to the VyOS open version and now the future plans with dNOS -> DANOS. /Stefan ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] vyatta in AT&T 5G gear
On Tue, 16 Oct 2018 11:59:18 +0200 Stefan Alfredsson wrote: > On 2018-10-16 11:31, Mikael Abrahamsson wrote: > > > On Mon, 15 Oct 2018, Dave Taht wrote: > > > >> Vyos (the open source fork of vyatta) was one of the first to add > >> fq_codel support... I wonder > >> > >> http://linuxgizmos.com/att-releases-white-box-spec-for-its-linux-based-5g-routers/ > >> > >> > > > > Isn't Vyos just running the Linux kernel for forwarding? So they > > received fq_codel for free when the Linux kernel got support for it? > > They just had to make it configurable? > > > > Yes, according to this blog post, > http://www.five-ten-sg.com/mapper/blog/Bufferbloat%20solved%20with%20Vyos > > "Now that Vyos "helium" is available with a Linux 3.13 kernel, the > fq_codel queueing discipline can be used to solve many bufferbloat > issues. The nightly "lithium" builds contain my patches that allow > fq_codel to be used via the native Vyos configuration system." > > Anyway it's nice to see the Vyatta heritage living on in it's various > forms (the AT&T "production hardened" Vyatta, to the Ubiquity EdgeMax > and some UniFi devices, to the VyOS open version and now the future > plans with dNOS -> DANOS. > > /Stefan > > > There are two basic components to network OS, the control plane and the data plane. VyOs has the old V1 which is filesystem based control plane and kernel dataplane. DaNoS has yang/netconf database based control plane (in Go) and DPDK (or switch offload?) based dataplane. Ubiquity redid the control plane as well, and uses their own hardware for dataplane. So more of "my grandfather's ax"... ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] vyatta in AT&T 5G gear
On Tue, Oct 16, 2018 at 8:06 AM Stephen Hemminger wrote: > > On Tue, 16 Oct 2018 11:59:18 +0200 > Stefan Alfredsson wrote: > > > On 2018-10-16 11:31, Mikael Abrahamsson wrote: > > > > > On Mon, 15 Oct 2018, Dave Taht wrote: > > > > > >> Vyos (the open source fork of vyatta) was one of the first to add > > >> fq_codel support... I wonder > > >> > > >> http://linuxgizmos.com/att-releases-white-box-spec-for-its-linux-based-5g-routers/ > > >> > > > > > > Isn't Vyos just running the Linux kernel for forwarding? So they > > > received fq_codel for free when the Linux kernel got support for it? > > > They just had to make it configurable? > > > > > > > Yes, according to this blog post, > > http://www.five-ten-sg.com/mapper/blog/Bufferbloat%20solved%20with%20Vyos > > > > "Now that Vyos "helium" is available with a Linux 3.13 kernel, the > > fq_codel queueing discipline can be used to solve many bufferbloat > > issues. The nightly "lithium" builds contain my patches that allow > > fq_codel to be used via the native Vyos configuration system." > > > > Anyway it's nice to see the Vyatta heritage living on in it's various > > forms (the AT&T "production hardened" Vyatta, to the Ubiquity EdgeMax > > and some UniFi devices, to the VyOS open version and now the future > > plans with dNOS -> DANOS. > > > > /Stefan > > > > > > > > There are two basic components to network OS, the control plane and the > data plane. VyOs has the old V1 which is filesystem based control plane > and kernel dataplane. DaNoS has yang/netconf database based control plane > (in Go) and DPDK (or switch offload?) based dataplane. Ubiquity redid > the control plane as well, and uses their own hardware for dataplane. > > So more of "my grandfather's ax"... so in other words we should have done a dpdk version long ago. And even then, this white box brags of the "deep buffering" in the switch chip. ... and I have an initial report of 2 seconds of buffering on one of the first 5G devices. Sigh. And what was so wrong with the "everything as a file" model?? double sigh. > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] vyatta in AT&T 5G gear
On 16/10/2018 17:14, Dave Taht wrote: > And what was so wrong with the "everything as a file" model?? On a single box - not a lot. On a 5G network, which might consist of 10^3 - 10^5 boxes you need aggregation and abstraction layers. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] vyatta in AT&T 5G gear
On Tue, 16 Oct 2018 08:14:36 -0700 Dave Taht wrote: > On Tue, Oct 16, 2018 at 8:06 AM Stephen Hemminger > wrote: > > > > On Tue, 16 Oct 2018 11:59:18 +0200 > > Stefan Alfredsson wrote: > > > > > On 2018-10-16 11:31, Mikael Abrahamsson wrote: > > > > > > > On Mon, 15 Oct 2018, Dave Taht wrote: > > > > > > > >> Vyos (the open source fork of vyatta) was one of the first to add > > > >> fq_codel support... I wonder > > > >> > > > >> http://linuxgizmos.com/att-releases-white-box-spec-for-its-linux-based-5g-routers/ > > > >> > > > > > > > > Isn't Vyos just running the Linux kernel for forwarding? So they > > > > received fq_codel for free when the Linux kernel got support for it? > > > > They just had to make it configurable? > > > > > > > > > > Yes, according to this blog post, > > > http://www.five-ten-sg.com/mapper/blog/Bufferbloat%20solved%20with%20Vyos > > > > > > "Now that Vyos "helium" is available with a Linux 3.13 kernel, the > > > fq_codel queueing discipline can be used to solve many bufferbloat > > > issues. The nightly "lithium" builds contain my patches that allow > > > fq_codel to be used via the native Vyos configuration system." > > > > > > Anyway it's nice to see the Vyatta heritage living on in it's various > > > forms (the AT&T "production hardened" Vyatta, to the Ubiquity EdgeMax > > > and some UniFi devices, to the VyOS open version and now the future > > > plans with dNOS -> DANOS. > > > > > > /Stefan > > > > > > > > > > > > > There are two basic components to network OS, the control plane and the > > data plane. VyOs has the old V1 which is filesystem based control plane > > and kernel dataplane. DaNoS has yang/netconf database based control plane > > (in Go) and DPDK (or switch offload?) based dataplane. Ubiquity redid > > the control plane as well, and uses their own hardware for dataplane. > > > > So more of "my grandfather's ax"... > > so in other words we should have done a dpdk version long ago. And even then, > this white box brags of the "deep buffering" in the switch chip. > > ... and I have an initial report of 2 seconds of buffering on one of > the first 5G devices. > > Sigh. > > And what was so wrong with the "everything as a file" model?? Two things were an issue. At scale, the filesystem was a bottleneck and it would have been harder to implement netconf/yang model as required by the big boy market. Filesystem works as toy. (see plan 9) ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] vyatta in AT&T 5G gear
Jan Ceuleers writes: > On 16/10/2018 17:14, Dave Taht wrote: >> And what was so wrong with the "everything as a file" model?? > > On a single box - not a lot. > > On a 5G network, which might consist of 10^3 - 10^5 boxes you need > aggregation and abstraction layers. I was mostly just venting. Still... I'd hoped that the next generation fios gear would get bufferbloat right... and with all the 5G boasting about the 1ms mac, that they'd get queuing delay below 20ms also. I was also hoping the DOCSIS 3.1 line cards would get it right... It has been a disappointing day. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat