Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64

Joel Wirāmu Pauling
On 28 August 2018 at 05:26, Joseph Mayer <[hidden email]> wrote:

> Joel,
>
> Are you saying you gave up on using the PCIe at all?
>
> There's a 4-lane PCIe connector on the Rock64 right, aren't those
> dedicated lanes, and, if they'd somehow be shared with any other
> hardware, then you should still have supposedly >90% of the 16gbps
> capacity available?
>
> Did you try connecting some multiport 1gbps or 10gbps PCIe NIC?

That's where my Wireless card goes - so it's not very useful.


My general experience with the Arm boards SBC's vs the Intel SoC's is
the Arm SBC's generally have screwed up some fundemental Bus sharing
in their designs (either placing the USB controller on so it shares
bandwidth with the GMAC) or Exposing only a Single X4 PCI lane (which
inevitably get's used by Wireless - unless you want to stick with the
onboard wireless which suffers from the first problem).


>
> Geekbench figures indicate that RK3399 and Celeron N3160 should perform
> fairly similarly.
>
> https://browser.geekbench.com/v4/cpu/search?q=rk3399
> https://browser.geekbench.com/v4/cpu/search?utf8=%E2%9C%93&q=n3160
> https://ark.intel.com/products/91831/Intel-Celeron-Processor-N3160-2M-Cache-up-to-2_24-GHz


The first test I normally subject my boxes too is localhost flent
(which is mostly netperf/iperf3/iperf under the hood) which provides a
bunch of test suites which are relatively good at finding out where
the Packet gen/receive limits are and if there is jitter - and provide
a starting point for further investigation. Irtt (which is written in
go) is also a really useful tool to figure out latencies (it times
sleep accuracy) on the SoC's.

Note the Arm boards don't have AES-NI either, so once you start
playing with VPN it get's pretty bad in comparison. (Some of the newer
arms do have AES offloads but - implementations are varied, the H3/H5
sunxi platform is where I am focused on at the moment - but not for
network stuff)
>
> On August 27, 2018 5:51 PM, Joel Wirāmu Pauling <[hidden email]> wrote:
>> I do actually have an rk3399 (firefly) - like you I also had high hopes for it.

Reply | Threaded
Open this post in threaded view
|

Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64

Joel Wirāmu Pauling
In reply to this post by Aaron-3
Hi Aaron - I have a Rangely c2xxx sitting on my desk right now. It's a
lanner rebadged as Nuage NSG-E.

This platform is able to do around 3.6gbit through it without
encryption (and around 1.3gbit total if encryption is turned on
everything). This one has 4 Intel igb 345 cards and 2 i210's - it's
designed as an SDN box. I use it with Openvswitch; but it's dual core
only and struggles with enough resources to be useful for dpdk (it
also has to use the older UIO shim drivers due to not supporting
undirected IO on the NIC cards) ; so ovs sans dpdk - if it had 4 cores
it might be a bit better. There is some QAT offload stuff that is a
PITA to get working as intel dropped support for that particular SoC
flavour years ago.

Despite it having far more ports,hardware watchdog, serial console and
gpio's which my cheap n3160's lack (2* realtek cards) the n3160 is
actually better performing.

On 28 August 2018 at 04:55, Aaron <[hidden email]> wrote:

> Have you considered any of intel’s atom c2000 or c3000 series SoC? I have openbsd running with several services, multiple vlans and a 500 down 20 up internet connection I can saturate on a c2000 series board
>
> Sent from my iPhone
>
>> On Aug 26, 2018, at 5:26 AM, Carlos López <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I am considering to buy an ARM based device to use it with OpenBSD as a personal/portable firewall, IDS and Tor gateway.
>>
>> My only requirements are:
>>
>> a/ OpenBSD well hardware's supported
>> b/ Best network throughput
>>
>> It seems Raspberry 3 B+ maybe the best option, but I am not pretty sure.
>>
>> Any advice?
>>
>> --
>> Greetings,
>> C. L. Martinez
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64

jungle Boogie
In reply to this post by C. L. Martinez
Hi Carlos,

Check out this reddit post with similar questions.

https://www.reddit.com/r/openbsd/comments/966wpe/running_on_a_sbcsoc_rock64_rpi_beaglebone_etc
Reply | Threaded
Open this post in threaded view
|

Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64

Karel Gardas
In reply to this post by Patrick Wildt-3
On Mon, 27 Aug 2018 21:48:17 +0200
Patrick Wildt <[hidden email]> wrote:

> On Mon, Aug 27, 2018 at 01:49:47PM +0200, Karel Gardas wrote:
> > On Sun, 26 Aug 2018 15:52:48 +0200
> > Patrick Wildt <[hidden email]> wrote:
> >
> > > On the MacchiatoBin we don't support the onboard ethernet yet.  On the
> > > EspressoBin we do support the ethernet controller, but the connected
> > > switch is a mess that I don't dare to support.  Got other stuff to do.
> > > Though I am working on partial EspressoBin support for the upcoming
> > > Turris Mox.
> >
> > What do you plan to support on Mox? Just basic module? If so, do you plan to support USB too so one can at least connect second NIC over USB? I see CZ.NIC does not make module with just another NIC and if you claim switch is a mess I'm curious how to make from this a router with >1NIC.
> >
> > Thanks!
> > Karel
>
> I pledged for the basic module, module B (mPCIe) and module D (SFP).
> The SoC actually has 2x Gigabit Ethernet NICs.  I figure they will use
> the first NIC for the basic module Ethernet and the other NIC will be
> connected to the SGMII line that runs over the connector.  So in my
> setup I will have the SFP slot connected to the second NIC.
>
> Their C and E modules provide further ports using a managed switch.
> Using that one as a dumb switch should be possible, but dynamically
> configuring port groups on the switch is something that we have no
> support for at the moment.  You might be able to change u-boot to
> initialize the switch with a VLAN tagged mode, but I cannot give any
> promises.  If you're interested you can probably tag with ccardenas@,
> who'd probably like to support the switch as well.
>
> USB works out of the box.  The Ethernet controller should work as well,
> same as the Clearfog.  SD card support is ongoing effort, but shouldn't
> be too much work since I got it going on the Armada 8040 as well.  PCIe
> hopefully follows afterwards.

Sounds very good! Thanks for all this information. By any chance, do you know if the docs for this managed switch is freely available? Or is it classical Marven no-no NDA thing?

Thanks!
Karel

Reply | Threaded
Open this post in threaded view
|

Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64

Joseph Mayer
In reply to this post by Joel Wirāmu Pauling
On August 28, 2018 3:04 AM, Joel Wirāmu Pauling <[hidden email]> wrote:

> On 28 August 2018 at 05:26, Joseph Mayer [hidden email] wrote:
>
> > Joel,
> > Are you saying you gave up on using the PCIe at all?
> > There's a 4-lane PCIe connector on the Rock64 right, aren't those
> > dedicated lanes, and, if they'd somehow be shared with any other
> > hardware, then you should still have supposedly >90% of the 16gbps
> > capacity available?
> > Did you try connecting some multiport 1gbps or 10gbps PCIe NIC?
>
> That's where my Wireless card goes - so it's not very useful.

In other words you'd have more use of two two-lane PCIe ports.

(Which I don't know if the RK3399 could drive in itself. PCIe switch
chips which convert four PCIe lanes upstream to 2x or 3x four PCIe
lanes downstream, seem to be generally pricy.)

I'd wonder what performance you got if you put the wired ethernet on
PCIe and wireless on USB.

> My general experience with the Arm boards SBC's vs the Intel SoC's is
> the Arm SBC's generally have screwed up some fundemental Bus sharing
> in their designs (either placing the USB controller on so it shares
> bandwidth with the GMAC) or Exposing only a Single X4 PCI lane (which
> inevitably get's used by Wireless - unless you want to stick with the
> onboard wireless which suffers from the first problem).

I'd like to learn to know if-how-how much the "screwed up some
fundamental" applies to the RK3399 and the MacchiatoBin/EspressoBin
boards.

> > Geekbench figures indicate that RK3399 and Celeron N3160 should perform
> > fairly similarly.
> > https://browser.geekbench.com/v4/cpu/search?q=rk3399
> > https://browser.geekbench.com/v4/cpu/search?utf8=✓&q=n3160
> > https://ark.intel.com/products/91831/Intel-Celeron-Processor-N3160-2M-Cache-up-to-2_24-GHz
>
> The first test I normally subject my boxes too is localhost flent
> (which is mostly netperf/iperf3/iperf under the hood) which provides a
> bunch of test suites which are relatively good at finding out where
> the Packet gen/receive limits are and if there is jitter - and provide
> a starting point for further investigation. Irtt (which is written in
> go) is also a really useful tool to figure out latencies (it times
> sleep accuracy) on the SoC's.
>
> Note the Arm boards don't have AES-NI either, so once you start
> playing with VPN it get's pretty bad in comparison. (Some of the newer
> arms do have AES offloads but - implementations are varied, the H3/H5
> sunxi platform is where I am focused on at the moment - but not for
> network stuff)

(Note, Sunxi don't do PCIe so you're stuck with XHCI there. Also
Sunxi's Allwinner A64 has around 25% of the performance rating of the
RK3399 on Geekbench.)

AES performance is an interesting point.

12