Re: [SPAM] Re: APU4 hardware network interfaces tied together
Stuart Henderson [s...@spacehopper.org] wrote: > > Do you have evidence to back this up? People were saying the same about > PCEngines not being reliable compared to Soekris too. It all seems nonsense. > Old rpi 1 and 2 machines are still running fine doing the job they were > intended to do. I'm not claiming there's anything amazing about them but > if they're capable of doing the job in the first place I don't see any > real concern about hardware reliability. > After some 100 APU units, both the realtek and intel based ethernet chip versions, the only failure I've had is when one of the RTC batteries blew up all over the board. And I've used the GPIO extensively. The boards are very reliable in my experience. The Soekris reputation went south when they used a buggy intel chip, which is really a problem with Intel and not Soekris, but unfortunately that probably helped to end Soekris.
Re: [SPAM] Re: APU4 hardware network interfaces tied together
On 2020-11-17, Mihai Popescu wrote: >> The combination of the computer and switch together can be considered a > router. > > I have Mikrotik hAP ac2 in test for a few days. That is exactly something > like this, 4 cores ARM for routing, switch attached for vlan'ed interfaces, > plus wifi. And it is a real charm as performance and price. But it does not > run OpenBSD and I miss the simplity of it mostly. This is how I was able to > see the big difference compared to ISP router. Agreed on all counts.. (you will find it hard to beat hAP ac2 for price:performance, it's sad the hardware is not open). > I already have a Netgear managed switch around here, with VLAN > capabilities. I think I will go for RPi4. Mark K. told me on arm@ that it > lacks storage and hardware acceleration for crypto used in ipsec and maybe > VPN, but I will not use it. I use only pppoe as a hardware challenger. > > Did you run RPi4 in this scenario, is there good throughput, please? What > do you use as storage? I haven't run it in this scenario. I've done a bit of network performance testing on the pi4 I occasionally use for ports work and was very pleasantly surprised by how well the onboard nic worked. I might give it a go sometime though, my APU was a bit slow for my current connection, the slightly faster amd64 I replaced it with makes an annoying noise ;) For storage I have uefi firmware on a cheap small microsd, main OpenBSD install on a usb3 sandisk ultra fit (the small ones) which I'm pretty happy with. (If I was running Linux on it I'd look for a drive supporting UASP though that doesn't really matter for a router which won't be doing all that much disk io).
Re: [SPAM] Re: APU4 hardware network interfaces tied together
> The combination of the computer and switch together can be considered a router. I have Mikrotik hAP ac2 in test for a few days. That is exactly something like this, 4 cores ARM for routing, switch attached for vlan'ed interfaces, plus wifi. And it is a real charm as performance and price. But it does not run OpenBSD and I miss the simplity of it mostly. This is how I was able to see the big difference compared to ISP router. I already have a Netgear managed switch around here, with VLAN capabilities. I think I will go for RPi4. Mark K. told me on arm@ that it lacks storage and hardware acceleration for crypto used in ipsec and maybe VPN, but I will not use it. I use only pppoe as a hardware challenger. Did you run RPi4 in this scenario, is there good throughput, please? What do you use as storage? Thank you.
Re: [SPAM] Re: APU4 hardware network interfaces tied together
On 2020-11-16, Noth wrote: > Buy a switch, and buy the APU4. Two ports don't get used, so what? For starters, that means you at least might as well use APU2 instead (which is often easier to buy - not all vendors have the APU4 - PCEngines don't sell direct in some countries other than to business customers). (and the price *difference* between APU2E0 and APU4 at some vendors is enough to buy a pi4...) > It'll be more reliable long term than a RPi4. Do you have evidence to back this up? People were saying the same about PCEngines not being reliable compared to Soekris too. It all seems nonsense. Old rpi 1 and 2 machines are still running fine doing the job they were intended to do. I'm not claiming there's anything amazing about them but if they're capable of doing the job in the first place I don't see any real concern about hardware reliability. > A router with only one physical port isn't a router, it's a host, no > matter how many vlans you throw at it. The combination of the computer and switch together can be considered a router. Plenty of "hardware" routers just have 1 or 2 real network interfaces (either on the SOC or a separate device) and run a larger number of ports off a vlan capable switch chip - sure it's in one box and looks like a coherent unit, but architecturally no different. Yes there are drawbacks of doing it this way but some advantages too. (There are other options like some of the Octeon boxes, which can often be bought second-hand for similar prices to RPi4, but I don't know what sort of router performance can be expected from them, and if they don't work out they're not reusable in nearly as many other roles as RPi4 or the other arm64 boards supported by OpenBSD would be).
Re: [SPAM] Re: APU4 hardware network interfaces tied together
Buy a switch, and buy the APU4. Two ports don't get used, so what? It'll be more reliable long term than a RPi4. A router with only one physical port isn't a router, it's a host, no matter how many vlans you throw at it. Cheers, Noth On 16/11/2020 18:06, Mihai Popescu wrote: bridge(4), and add a vether ... Reading thru man pages I see there are other options: switch, aggr, trunk, etc. I barely understand these, since IP is an ugly business. My intention is to replace ISP router with something based on OpenBSD I can configure myself. I see now that APU4 is too much, I am inclined to try RPi4 with an USB network interface. If anyone has any other suggestion, please email me directly to ease the list. Thank you all.