Ah, I’m not using pppoe so perhaps that’s significant? I have a straight 
ethernet set up, em0 as uplink, em1 connected to a dumb switch, em2 connected 
to a dumb WiFi AP. I measured the speed using fast.com on my mobile, laptop, 
desktop, as well as downloading large files from different servers and CDNs. As 
pointed out elsewhere in this thread, that test only covers full size packets. 
Since my APU2 is an edge router/firewall for my home network, I pretty much 
only get full size TCP packets, and some low throughput UDP packets. All in the 
kernel, i.e. pf, since the router doesn’t really generate traffic of its own.

Peter

> On Nov 4, 2017, at 10:49 AM, miraculli . <miracu...@gmail.com> wrote:
> 
> Hi,
> 
> i´ve also an APU2 as router.
> The uplink connection (16Mbit/s) is via pppoe(4) on em0
> and i couldn´t manage to messure the throughput of this interface:
> - iftop doesn´t work on pppoe and shows nothing on em0. 
> - ifperf also calculates some strange numbers (14669317741 Gbits/sec)
> when trying to connect to one of the public iperf-servers from
> https://iperf.fr/iperf-servers.php
> 
> how do you messure the performance?
> 
> 
> 2017-11-04 18:24 GMT+01:00 Peter Faiman <peterfai...@gmail.com>:
> > On Nov 4, 2017, at 09:53, Chris Cappuccio <ch...@nmedia.net> wrote:
> >
> > Rupert Gallagher [r...@protonmail.com] wrote:
> >>
> >> You seem to say that handling larger packets is a feature of having 
> >> limited CPU. I disagree.
> >>
> >
> > Rupert, I'm saying that a slower CPU can process less packets per second.
> >
> > The important measurement is packets-per-second. The APU has plenty of
> > memory bandwidth to handle large volumes of data. For adequate CPU power,
> > you have to either lower the cost of processing (make software better/more
> > efficient) or you have to distribute the cost across the 4 cores of the APU2
> > (make software execution parallel).
> >
> >>> The same traffic level, with 1500 byte packets generates 6 times more 
> >>> packets per second than that traffic level with 9000 bytes packets.
> >>
> >> You divided 9000 by 1500 without mistakes. Congratulations.
> >>
> >
> > The point was clearly lost on you.
> >
> >>> There is ongoing work to improve the network stack performance on boxes 
> >>> like the APU2 (which have 4 cores). You will see improvements. If you 
> >>> want it better today, you need a faster box. Chris
> >>
> >> The apu2c4 is fast enough to saturate its Intel 1Gbits/sec link. It has 
> >> three of those. If you connect all three to the switch, you get 3Gbps shy. 
> >> No need for a faster box. You rather need a faster switch, class 7 S-FTP 
> >> wires (better than class 6), and 2.5Gbps lan cards for clients.
> >
> > No, you don't need any of that. You have no idea what you are talking about.
> >
> > The APU requires software crafted to evenly distribute PER-PACKET PROCESSING
> > cost across multiple cores. That is what is happening in OpenBSD today. It 
> > has
> > been happening for years, and it is getting closer to becoming a reality 
> > with
> > OpenBSD + APU2, as well as other chipsets/platforms.
> >
> > For a couple years now, we've had interrupts processed by one core, PF on
> > another, and other parts of the kernel on a third core. But to accelerate
> > packet processing alone, we need interrupts handled on multiple cores,
> > PF processing handled on multiple cores. This is hard work.
> >
> > By the way, what I'm describing is the general-purpose OS approach towads
> > this problem. If you want to turn computer hardware into routers with little
> > other concern, the go-to platform is DPDK + VPP. It is something like an
> > order of magnitude faster than any general purpose OS (OpenBSD, Linux) at
> > packet pushing.
> >
> > https://www.reddit.com/r/networking/comments/6upchy/can_a_bsd_system_replicate_the_performance_of/dlvdq2e/
> >
> > Chris
> 
> Thank you for this explanation. My uplink is only 240mbit and my APU2 handles 
> that perfectly, so I’m not having any of these problems. But the insight into 
> the current state of networking was great! :)
> 
> Peter
> 
> 
> 
> -- 
> +49.179.1448024
> Karl-Kunger-Straße 68
> D - 12435 Berlin

Reply via email to