PC-Engines APU2

[RTM]

I found this over on the pfsense hardware forum, apparently PC-engines have released beta versions of their upcoming APU2 boards, and they are looking pretty nice.

Of note is the fact that the Realtek NICs have been replaced with Intel i210AT or i211AT's, and that there is now support for AES-NI. All in all it looks like a very nice platform for a router.

Currently stated specs:

APU2B4:
CPU: AMD GX-412TC (1GHz quad core w. AES-NI)
RAM: 4GB ECC
NICs: 3x Intel I210AT
Current price: 142.4 CHF ~ 144.57 USD

APU2B2:
CPU: AMD GX-412TC (1GHz quad core w. AES-NI)
RAM: 2GB non-ECC
NICs: 3x Intel I211AT
Current price: 123.28 CHF ~ 125.16 USD

EDIT: It is probably also worth mentioning, that currently you need to apply for permission to buy either of these boards.

 

[EffrafaxOfWug]

Nice - I saw these before and discounted them for a router project due to the realtek's, nice to see them listening to their users.

On a related note... are there any well-supported 802.11ac miniPCIe cards around yet or is the prevailing wisdom for pfsense to use a separate WAP?

 

[mstone]

Nice - I saw these before and discounted them for a router project due to the realtek's, nice to see them listening to their users.

Ironically, the latest OpenBSD release finally got the performance of the realtek cards up to the level as the linux drivers. (IOW, this is really a non-issue.) OTOH, if they can put in the intel parts for the same money and it makes some people feel better I guess that's fine also.

On a related note... are there any well-supported 802.11ac miniPCIe cards around yet or is the prevailing wisdom for pfsense to use a separate WAP?

My prevailing wisdom is to separate the WAP functionality from the firewall regardless of the OS. A simple firewall will run forever, a WAP is always going to be flakey. Unless you're 100% wireless, why not give your wired clients 100% uptime instead of hobbling them with the problems of wireless?

 

[EffrafaxOfWug]

Ironically, the latest OpenBSD release finally got the performance of the realtek cards up to the level as the linux drivers. (IOW, this is really a non-issue.)

I was always under the impression that for common-or-garden file transfers in linux or BSD the realtek's were perfectly adequate, it's just for all that weird edge-case stuff (loads small packets, jumbo frames, lotsa different MTUs) that stability and performance were suspect. As such intel NICs basically became shorthand for "ninety nine times out of a hundred it'll work for any scenario" whereas realtek had the opposite reputation. Trust is an easy thing to lose but very difficult to gain.

A simple firewall will run forever, a WAP is always going to be flakey. Unless you're 100% wireless, why not give your wired clients 100% uptime instead of hobbling them with the problems of wireless?

It's a question of efficiency and ease of management mostly, if you're going to the effort of building a whole computer already then adding a couple of miniPCIe cards and some antennas is childs play and will only add a couple of extra watts to the power budget. Not sure why restarting the wireless would have any effect on the wired ethernet...? I've had good results with the ath9k stuff on linux, including in AP mode, and if the wireless went pop as it did in some of the earlier kernel versions it was just a simple rmmod/modprobe to reset it. Does pfsense not let you restart the wireless separately?

 

[mstone]

I was always under the impression that for common-or-garden file transfers in linux or BSD the realtek's were perfectly adequate, it's just for all that weird edge-case stuff (loads small packets, jumbo frames, lotsa different MTUs) that stability and performance were suspect. As such intel NICs basically became shorthand for "ninety nine times out of a hundred it'll work for any scenario" whereas realtek had the opposite reputation. Trust is an easy thing to lose but very difficult to gain.

Yes, that's another way of saying "some people didn't notice 10 years worth of hardware development". The capabilities of the last 3 or 4 versions of the 8169/8111/etc are very different from the original versions. Intel's chips have changed a lot in a decade, also. The drivers were a huge factor for a long time, but re(4) seems to be getting better. There are still reasons to get a high end NIC, but none of those reasons matter much for a low-powered firewall.

It's a question of efficiency and ease of management mostly, if you're going to the effort of building a whole computer already then adding a couple of miniPCIe cards and some antennas is childs play and will only add a couple of extra watts to the power budget. Not sure why restarting the wireless would have any effect on the wired ethernet...? I've had good results with the ath9k stuff on linux, including in AP mode, and if the wireless went pop as it did in some of the earlier kernel versions it was just a simple rmmod/modprobe to reset it. Does pfsense not let you restart the wireless separately?

If you were able to magically make the wireless come back with a modprobe you were lucky. Of course the entire idea that it's "easy" to just log in to a firewall to manually reset a wireless card (while the wireless is flaked out until you get to that) vs just not worrying about that at all kinda makes the point.

 

[EffrafaxOfWug]

If you were able to magically make the wireless come back with a modprobe you were lucky. Of course the entire idea that it's "easy" to just log in to a firewall to manually reset a wireless card (while the wireless is flaked out until you get to that) vs just not worrying about that at all kinda makes the point.

IIRC there was something that showed up in the syslog that we did to automatically run the rmmod/modprobe. Worked fine for us until the problem was fixed in a newer kernel.

Is wireless flaking out really that common a thing still? And does it require a restart? Had zero problems with wireless on my home routers (draytek's) for the last eight years, other than wireless being generally crappy for anything needing more than a couple MB/s throughput. And if you've got your wireless in a separate WAP, and it requires restarting if the wireless dies, how do you go about rebooting it...?

Follow up to the ath9k seems to be the ath10k but miniPCIe cards and info on the driver in either linux or BSD seems rather thin on the ground now. Sucks that there's now a requirement for firmware however

 

[mstone]

Is wireless flaking out really that common a thing still?

Yes, anytime the technology is bumped. It takes years to get all the open source drivers sorted.

Had zero problems with wireless on my home routers (draytek's) for the last eight years, other than wireless being generally crappy for anything needing more than a couple MB/s throughput.

Well, if you're happy with the performance of an 8 year old wireless network then I guess that's fine. If you want good wireless performance I return to suggesting just getting a WAP with current technology and plugging it into a nice reliable firewall.

And if you've got your wireless in a separate WAP, and it requires restarting if the wireless dies, how do you go about rebooting it...?

Most of them have a watchdog process which will automatically reboot.

 

[EffrafaxOfWug]

Maybe I'm missing something here, but why does "wireless stops working" == reboot?

Think you misunderstood me; been using draytek routers since 2001, draytek routers/APs since 2007, currently using their 802.11ac router. It never crashes or drops wireless and neither did the two routers that preceded it. But I've still never seen a wireless AP (and I've used pretty much every brand) that'll shunt more than 1-5MB/s on a good day with the wind behind it.

 

[mstone]

But I've still never seen a wireless AP (and I've used pretty much every brand) that'll shunt more than 1-5MB/s on a good day with the wind behind it.

I'm sorry, I haven't had an AP that slow in quite a while, and can't tell you what's going on there.

 

[fred0r]

Just received my APU2 Board - its awesome

 

[EffrafaxOfWug]

Inquiring minds would like to know - empirically, how awesome, and to the nearest decimal place how many people did you have to kill?

Seriously though, what's your use-case?

 

[fred0r]

i'm using it as my router on a 100mbit vdsl-link.
i'm specially interested in the AES-NI and the acceleration for VPN-Traffic to tunnel my 'Home-Traffic' through a VPN-Provider.

 

[EffrafaxOfWug]

Depends a great deal on how your VPN provider does things. If it's a generic IPsec or SSL and they let you use your own software then the linux versions at least have has AES-NI support for a couple of years now... but not sure what support in ditros like pfsense is like. If instead they provide you with their own VPN client then all bets are off.

Even so, CPUs in these even without any hardware acceleration should be able to do AES256 at at least 100MB/s (that's 8 times faster than your pipe) without breaking a sweat so I don't think you have anything to worry about performance wise.

 

[fred0r]

I've read that PFSense has Support for AES-NI in recent 64bit-Installs for IPSec / Openssl.

 

[EffrafaxOfWug]

Aye, but I've no experience with the AMD implementation of AES-NI and even with the intel one it doesn't have 100% support of all cipher suites. If you've got a pfsense install running on it you can verify what crypto module openssl thinks it's got access to like so:

/usr/bin/openssl engine -t -c

Are cryptographic accelerators supported - PFSenseDocs

 

[fred0r]

I get:

[2.2.5-RELEASE][root@pfSense.localdomain]/root: /usr/bin/openssl engine -t -c
(cryptodev) BSD cryptodev engine
 [RSA, DSA, DH]
  [ available ]
(rsax) RSAX engine support
 [RSA]
  [ available ]
(dynamic) Dynamic engine loading support
  [ unavailable ]

 

[EffrafaxOfWug]

I'm no BSD/pfsense expert but I'd expect to see at least AES-128-CBC in that list if AES-NI was working properly... are you sure the module is loaded? Dunno how pfsense handles module loading but IIRC you should be able to load it manually from the command line with `kldload aesni` and then re-run the openssl command.

 

[fred0r]

Heh - you're right - just booted up from usb - normally i use linux but i havent even seen that it is missing..

[2.2.5-RELEASE][root@pfSense.localdomain]/root: /usr/bin/openssl engine -t -c
(cryptodev) BSD cryptodev engine
[RSA, DSA, DH, AES-128-CBC, AES-192-CBC, AES-256-CBC]
  [ available ]
(rsax) RSAX engine support
[RSA]
  [ available ]
(dynamic) Dynamic engine loading support
  [ unavailable ]

 

[mstone]

I'm no BSD/pfsense expert but I'd expect to see at least AES-128-CBC in that list if AES-NI was working properly... are you sure the module is loaded? Dunno how pfsense handles module loading but IIRC you should be able to load it manually from the command line with `kldload aesni` and then re-run the openssl command.

You don't need an openssl engine to use AES-NI. You should see a dramatic difference with and without -evp on the speed test, that's AES-NI being used automatically. Engines were needed for crypto accelerators which needed the kernel to manage access to a device (like crypto accelerator PCI cards or VIA padlock's on-die implementation). Some systems provide a device for access to AES-NI for backward compatibility with legacy software, but that's typically slower than using AES-NI directly.

 

[Deleted member 6667]

Hello,
has anyone tested this with Voyage Linux yet?

Regards