Jonathan Bennett wrote:
> Isn't that what CZnic has done with the Turris router?
>
> https://www.turris.com/en/mox/overview/
> I hadn't seen the Mox, that is clever. The downside is the price, and that
> they're hard to get outside Europe.
Yup.
The MOX is very nice, but
Hi Jonathan,
> On Aug 4, 2021, at 20:28, Jonathan Morton wrote:
>
> I firmly believe this is due to an I/O bottleneck in the SoC between
> the network complex and the CPU complex, not due to any limitation of
> the CPU itself. It stems from the reliance on accelerated forwarding
> hardware to
On Wed, 4 Aug 2021, Jonathan Morton wrote:
3: Leverage the Raspberry Pi ecosystem to build a CPE device that
meets our needs. This could be a Compute Module 4 (which has the
necessary I/O throughput) mounted on a custom PCB that provides
additional Ethernet ports and some reasonable Wifi AP.
Isn't that what CZnic has done with the Turris router?
https://www.turris.com/en/mox/overview/
On Wed, Aug 4, 2021 at 1:08 PM Jonathan Bennett <
jonathanbenn...@hackaday.com> wrote:
>
>
>
>>
>>
>> The Compute Module 4 exposes the same integrated Ethernet port, and a
>> PCIe lane in place of the
On Wed, 4 Aug 2021 at 21:31, Juliusz Chroboczek wrote:
> A Cortex-A53 SoC at 1GHz with correctly designed Ethernet (i.e. not the
> Raspberry Pi) can push 1Gbit from userspace without breaking a sweat.
That was true of the earlier Raspberry Pis (eg. the Pi 3 uses a brace
of Cortex-A53s) which use
Hi Mikael,
> If it's not hw accelerated, it sucks.
Fortunately, that hasn't been true in a long time. Two data points.
The WND3700v2/WNDR3800, which is now over ten years old, can easily
forward 400Mbit/s NATed IPv4 (max-sized packets) in software. To be fair,
it can saturate 1Gbit/s with
I firmly believe this is due to an I/O bottleneck in the SoC between
the network complex and the CPU complex, not due to any limitation of
the CPU itself. It stems from the reliance on accelerated forwarding
hardware to achieve full line-rate throughput. Even so, I'd much
rather have 40Mbps with
Hi Mikael,
> On Aug 4, 2021, at 15:06, Mikael Abrahamsson wrote:
>
> On Wed, 4 Aug 2021, Sebastian Moeller wrote:
>
>> I guess the point is AQM is not really that expensive, even FQ AQM, traffic
>> shaping however is expensive. But for wifi shaping is not required so AQM
>> became
On Wed, 4 Aug 2021, Sebastian Moeller wrote:
I guess the point is AQM is not really that expensive, even FQ AQM,
traffic shaping however is expensive. But for wifi shaping is not
required so AQM became feasible.
My point is that CPU based forwarding has very bad performance on some
I guess the point is AQM is not really that expensive, even FQ AQM, traffic
shaping however is expensive. But for wifi shaping is not required so AQM
became feasible.
Regards
Sebastian
On 4 August 2021 14:46:30 CEST, Mikael Abrahamsson via Bloat
wrote:
>On Wed, 4 Aug 2021, Jonathan
On Wed, 4 Aug 2021, Jonathan Morton wrote:
Linux-based CPE devices have AQM functionality integrated into the Wifi
stack. The AQM itself operates at layer 3, but the Linux Wifi stack
implementation uses information from layers 2 and 4 to improve
scheduling decisions, eg. airtime-fairness and
> I assume by WiFi what is really meant is devices that have at least one WiFi
> (layer 1/layer 2) interface. While there are queues in the MAC sublayer,
> there is really no queue management functionality ... yet ... AFAIK. I know
> IEEE P802.11bd in conjunction w/ IEEE 1609 is working on
I assume by WiFi what is really meant is devices that have at least one WiFi
(layer 1/layer 2) interface. While there are queues in the MAC sublayer, there
is really no queue management functionality ... yet ... AFAIK. I know IEEE
P802.11bd in conjunction w/ IEEE 1609 is working on implementing
13 matches
Mail list logo
