Bad network performance on apu2c4

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bad network performance on apu2c4

Christer Solskogen-3
Hi!

I have a APU2C4 running OpenBSD-current (or.. .pretty current, from 27th of
October) - and according to iperf I'm not getting the speed that I was
expecting.

Between the APU and the other machines I have I get: 465 Mbits/sec - While
between two other machines, connected to the same switch I get 939
Mbits/sec. So I'm pretty sure that APU is to blame.

ifconfig:
em0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST>
mtu 1500
        lladdr 00:0d:b9:41:6f:c8
        index 1 priority 0 llprio 3
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
        inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255

I've tried different MTU sizes as well, but it does not seem to have any
effect.
Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Dimitris Papastamos
On Wed, Nov 01, 2017 at 09:14:03AM +0100, Christer Solskogen wrote:
> Hi!
>
> I have a APU2C4 running OpenBSD-current (or.. .pretty current, from 27th of
> October) - and according to iperf I'm not getting the speed that I was
> expecting.
>
> Between the APU and the other machines I have I get: 465 Mbits/sec - While
> between two other machines, connected to the same switch I get 939
> Mbits/sec. So I'm pretty sure that APU is to blame.

Do you use the APU as a router?  If so you shouldn't run iperf on the
APU.  Run iperf/tcpbench between two machines connected on different
interfaces on the APU.

see rfc2544 for more details

Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Christer Solskogen-3
On Wed, Nov 1, 2017 at 10:35 AM, Dimitris Papastamos <[hidden email]> wrote:

> On Wed, Nov 01, 2017 at 09:14:03AM +0100, Christer Solskogen wrote:
> > Hi!
> >
> > I have a APU2C4 running OpenBSD-current (or.. .pretty current, from 27th
> of
> > October) - and according to iperf I'm not getting the speed that I was
> > expecting.
> >
> > Between the APU and the other machines I have I get: 465 Mbits/sec -
> While
> > between two other machines, connected to the same switch I get 939
> > Mbits/sec. So I'm pretty sure that APU is to blame.
>
> Do you use the APU as a router?  If so you shouldn't run iperf on the
> APU.  Run iperf/tcpbench between two machines connected on different
> interfaces on the APU.
>
>
Yes, I do use it as a router normally, but these number are when it is not.

--
chs
Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Stuart Henderson
On 2017-11-01, Christer Solskogen <[hidden email]> wrote:

> On Wed, Nov 1, 2017 at 10:35 AM, Dimitris Papastamos <[hidden email]> wrote:
>
>> On Wed, Nov 01, 2017 at 09:14:03AM +0100, Christer Solskogen wrote:
>> > Hi!
>> >
>> > I have a APU2C4 running OpenBSD-current (or.. .pretty current, from 27th
>> of
>> > October) - and according to iperf I'm not getting the speed that I was
>> > expecting.
>> >
>> > Between the APU and the other machines I have I get: 465 Mbits/sec -
>> While
>> > between two other machines, connected to the same switch I get 939
>> > Mbits/sec. So I'm pretty sure that APU is to blame.
>>
>> Do you use the APU as a router?  If so you shouldn't run iperf on the
>> APU.  Run iperf/tcpbench between two machines connected on different
>> interfaces on the APU.
>>
>>
> Yes, I do use it as a router normally, but these number are when it is not.

Forwarding is kernel-only and should be faster than userland sending. So if
you're trying to determine performance when used for forwarding, you need to
have other machine/s sending and receiving packets for the test.



Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Christer Solskogen-3
On Thu, Nov 2, 2017 at 7:24 PM, Stuart Henderson <[hidden email]>
wrote:

> Forwarding is kernel-only and should be faster than userland sending. So if
> you're trying to determine performance when used for forwarding, you need
> to
> have other machine/s sending and receiving packets for the test


The thing is the the uplink to my ISP is supposed to be 500Mbit/sec. But I
only get around 400MB/s, which seems a bit low for a gigabit interface.
Problem is not with the ISP, as I've tested with an old-ish laptop. (I even
get a bit more than 500Mbit/s!)
Perhaps current is using some extra debug-stuff that slows things down?
Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Sterling Archer
On Fri, Nov 3, 2017 at 12:10 AM, Christer Solskogen
<[hidden email]> wrote:

> On Thu, Nov 2, 2017 at 7:24 PM, Stuart Henderson <[hidden email]>
> wrote:
>
>> Forwarding is kernel-only and should be faster than userland sending. So if
>> you're trying to determine performance when used for forwarding, you need
>> to
>> have other machine/s sending and receiving packets for the test
>
>
> The thing is the the uplink to my ISP is supposed to be 500Mbit/sec. But I
> only get around 400MB/s, which seems a bit low for a gigabit interface.
> Problem is not with the ISP, as I've tested with an old-ish laptop. (I even
> get a bit more than 500Mbit/s!)
> Perhaps current is using some extra debug-stuff that slows things down?

No, you'll get the same result with release or stable, or at least, I do,
using forwarding on an apu2c4.

You can check if you're dropping packets with sysctl net.inet.ip.ifq.drops
(and net.inet6.ip6.ifq.drops if you're using ipv6). If that returns
anything else
than 0, you can tweak net.inet.ip.ifq.maxlen and net.inet6.ip6.ifq.maxlen.
4096 seems to be a good value for me, I get around 460Mbps up and down
with that set.

--
:wq!

Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Stuart Henderson
In reply to this post by Christer Solskogen-3
On 2017/11/03 00:10, Christer Solskogen wrote:

> On Thu, Nov 2, 2017 at 7:24 PM, Stuart Henderson <[hidden email]>
> wrote:
>
>     Forwarding is kernel-only and should be faster than userland
>     sending. So if
>     you're trying to determine performance when used for forwarding,
>     you need to
>     have other machine/s sending and receiving packets for the test
>
>
> The thing is the the uplink to my ISP is supposed to be 500Mbit/sec.
> But I only get around 400MB/s, which seems a bit low for a gigabit
> interface.
> Problem is not with the ISP, as I've tested with an old-ish laptop. (I
> even get a bit more than 500Mbit/s!)
> Perhaps current is using some extra debug-stuff that slows things down?
>

You may get a little more with tweaks, but the real answer is the ongoing work
to improve SMP in the OpenBSD network stack. I like the APU2 but that's
a rather fast connection and running fairly close to current limits.

Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Christer Solskogen-3
On Fri, Nov 3, 2017 at 2:15 AM, Stuart Henderson <[hidden email]>
wrote:

> On 2017/11/03 00:10, Christer Solskogen wrote:
> > On Thu, Nov 2, 2017 at 7:24 PM, Stuart Henderson <[hidden email]>
> > wrote:
> >
> >     Forwarding is kernel-only and should be faster than userland
> >     sending. So if
> >     you're trying to determine performance when used for forwarding,
> >     you need to
> >     have other machine/s sending and receiving packets for the test
> >
> >
> > The thing is the the uplink to my ISP is supposed to be 500Mbit/sec.
> > But I only get around 400MB/s, which seems a bit low for a gigabit
> > interface.
> > Problem is not with the ISP, as I've tested with an old-ish laptop. (I
> > even get a bit more than 500Mbit/s!)
> > Perhaps current is using some extra debug-stuff that slows things down?
> >
>
> You may get a little more with tweaks, but the real answer is the ongoing
> work
> to improve SMP in the OpenBSD network stack. I like the APU2 but that's
> a rather fast connection and running fairly close to current limits.
>

Ok, thanks for the explanation ! :-)

--
chs
Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Rupert Gallagher
In reply to this post by Christer Solskogen-3
openbsd "current"... is it 6.1 or 6.2?

if 6.2, was it better with 6.1?

From a later message of yours, you mention ISP upload, but the OP did not mention it. Are you testing on LAN, WAN or internet?

Out of curiosity, I just tested an apu2c4 server with obsd 6.1, against a windows 10 client on LAN with a 1Gbit CISCO switch in between and 9K MTU on both sides, using iperf3 -P10. The result is a spectacular 950Mbits/sec.

Sent from ProtonMail Mobile

On Wed, Nov 1, 2017 at 09:14, Christer Solskogen <[hidden email]> wrote:

> Hi! I have a APU2C4 running OpenBSD-current (or.. .pretty current, from 27th of October) - and according to iperf I'm not getting the speed that I was expecting. Between the APU and the other machines I have I get: 465 Mbits/sec - While between two other machines, connected to the same switch I get 939 Mbits/sec. So I'm pretty sure that APU is to blame. ifconfig: em0: flags=8b43  mtu 1500 lladdr 00:0d:b9:41:6f:c8 index 1 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 I've tried different MTU sizes as well, but it does not seem to have any effect. ,broadcast,running,promisc,allmulti,simplex,multicast>
Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Chris Cappuccio
Rupert Gallagher [[hidden email]] wrote:
> Out of curiosity, I just tested an apu2c4 server with obsd 6.1, against a windows 10 client on LAN with a 1Gbit CISCO switch in between and 9K MTU on both sides, using iperf3 -P10. The result is a spectacular 950Mbits/sec.
>

This is not a regression. The APU2 has limited CPU power and can handle larger packets much better than typically internet-routable 1500 byte packets. The same traffic level, with 1500 byte packets generates 6 times more packets per second than that traffic level with 9000 bytes packets. 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

Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Rupert Gallagher
On Sat, Nov 4, 2017 at 01:51, Chris Cappuccio <[hidden email]> wrote:

> Rupert Gallagher [[hidden email]] wrote:

>>> Out of curiosity, I just tested an apu2c4 server with obsd 6.1, against a windows 10 client on LAN with a 1Gbit CISCO switch in between and 9K MTU on both sides, using iperf3 -P10. The result is a spectacular 950Mbits/sec.

>> This is not a regression.

> ????

>> The APU2 has limited CPU power and can handle larger packets much better than typically internet-routable 1500 byte packets.

> You seem to say that handling larger packets is a feature of having limited CPU. I disagree.

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

>> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Chris Cappuccio
Rupert Gallagher [[hidden email]] 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

Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Peter Faiman
> On Nov 4, 2017, at 09:53, Chris Cappuccio <[hidden email]> wrote:
>
> Rupert Gallagher [[hidden email]] 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
Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

miraculli .
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 <[hidden email]>:

> > On Nov 4, 2017, at 09:53, Chris Cappuccio <[hidden email]> wrote:
> >
> > Rupert Gallagher [[hidden email]] 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 | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Rupert Gallagher
In reply to this post by Chris Cappuccio
Look, I know what I am talking about. I have an apu that does what I said using negligible cpu load. And there is nothing fancy with it.

Sent from ProtonMail Mobile

On Sat, Nov 4, 2017 at 17:53, Chris Cappuccio <[hidden email]> wrote:

> Rupert Gallagher [[hidden email]] 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
Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Stuart Henderson
In reply to this post by Peter Faiman
On 2017-11-04, Peter Faiman <[hidden email]> wrote:
> 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! :)

But it doesn't handle 240Mbit/s, *unless* the packets are large.

If somebody sends 240Mb/s of minimal sized packets at you, it won't cope.

Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Chris Cappuccio
In reply to this post by Rupert Gallagher
Rupert Gallagher [[hidden email]] wrote:
> Look, I know what I am talking about. I have an apu that does what I said using negligible cpu load. And there is nothing fancy with it.

I see. Sorry, until you said this, I was not convinced that you knew. Having
read these words, it's now apparent to me that you are an expert in this area
and I was terribly wrong to try and correct you.

Chris

Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Peter Faiman
In reply to this post by Stuart Henderson
> On Nov 4, 2017, at 13:15, Stuart Henderson <[hidden email]> wrote:
>
>> On 2017-11-04, Peter Faiman <[hidden email]> wrote:
>> 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! :)
>
> But it doesn't handle 240Mbit/s, *unless* the packets are large.
>
> If somebody sends 240Mb/s of minimal sized packets at you, it won't cope.

Probably. I’ve never tried, it’s a home router so I only use that kind of bandwidth for stream connections. At full download it’s got two cores at about 45%, which is consistent with what you said about core separation of tasks, and maximum speed.
Reply | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Peter Faiman
In reply to this post by miraculli .
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 . <[hidden email]> 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 <[hidden email]>:
> > On Nov 4, 2017, at 09:53, Chris Cappuccio <[hidden email]> wrote:
> >
> > Rupert Gallagher [[hidden email]] 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 | Threaded
Open this post in threaded view
|

Re: Bad network performance on apu2c4

Christer Solskogen-3
In reply to this post by Rupert Gallagher
On Thu, Nov 9, 2017 at 1:42 AM, Rupert Gallagher <[hidden email]>
wrote:

> New speed record today: 963Mbps between apu2c4 and a PC, both ways.
>
>
I never get above 550Mbit with pf enabled.
12