Is Atom J1900 enough for this setup?



  • Hi,

    I know this CPU don't have EAS-NI implemented. But maybe he has enough power for my network setup
    I have small network with 20 clients on 3 different VLAN's. At this time I have pfsense running on my XenServer but I'm not really happy with this setup.

    What I need is a box with 4 NIC's for my 20 clients. Except packet filter I need suricata and 2 VPN connections. I have a VDSL connection with 100/40 MB. VPN is not the primary focus. Different boards with 4 NIC's and CPU with EAS-NI are a bit too expensive for me at this time. If the CPU is too weak I can better stay on my VM on XenServer

    Tobi



  • @Tobi:

    If the CPU is too weak I can better stay on my VM on XenServer

    If your VM can handle the load just stay there.  No reason to go for dedicated hardware if you don't need it.



  • @whosmatt:

    If your VM can handle the load just stay there.

    The problem is that pfSense and Citrix XenServer is not the best combination. I have many problems with it
    But I think I'll buy APU2C4.



  • a j1900 would be fine. an apu would also be fine for the wan, but may be a bottleneck for routing between gigabit vlans.



  • The problem is that pfSense and Citrix XenServer is not the best combination. I have many problems with it
    But I think I'll buy APU2C4.

    APU2C4 is running at ~1,xGHz and the J1900 or Intel 2930 at ~2,xGHz so if the AES-NI will not be the deal breaker
    here in that game I would be looking for a Jetway NF9HG-2930, you may be able to insert 8 GB instead of 4 GB and
    you get one NIC (Intel based) more and the PSU can be connected likes the APU2C4 directly on the board.



  • Hi
    I have the J1900 with around 20 devices online full time, multiple users and one remote user via IPSEC VPN.

    The connection is 62 down and 18 up with pfSense doing the PPPOE connection via the modem.

    At pretty much full load on the network and with the remote user downloading from a local NAS, the CPU maxed at about 17% usage. That was with the WAN under full load.

    It feels like it could take quite a bit more before it has an issue.



  • Thx for the answers.

    I don't know if AES-NI will be the "deal breaker" - and this is my big "problem". I think more CPU frequency is better here for routing and FW. I'm unsure what about my VPN connections. I have VDSL 100/40 Mbit and no more then 2 VPN connections (OpenVPN)



  • @Tobi:

    I think more CPU frequency is better here for routing and FW

    This is and old recommendation since current pfsense is fully multi-threaded. So generally more cores lessor frequency is preferred to fewer cores and higher frequency.



  • @mir:

    @Tobi:

    I think more CPU frequency is better here for routing and FW

    This is and old recommendation since current pfsense is fully multi-threaded. So generally more cores lessor frequency is preferred to fewer cores and higher frequency.

    I certainly wouldn't make such a statement. It's true that some work was done on PF (around FreeBSD 10) to make it more multithread friendly but packet filtering and address rewriting are by their nature very hard to adapt to processing by multiple threads.

    If someone like Henning Brauer writes "And the possible pf MP gains are drasticly overrated anyway" you have to start asking if multithreading actually accomplishes any major performance improvements in PF:

    http://marc.info/?l=openbsd-misc&m=140481012425889&w=2



  • not everything is multithreaded, and some rss aware network drivers fallback to one queue when altq is enabled. (popular igb driver included).  per core performance is important, extra cores will help tho when more services are been run on the box e.g. processing pfblockerng feeds, an idle core can be allocated instead of one processing wan traffic.

    Also for what its worth I agree with Henning Brauer, I think FreeBSD would benefit much more from porting the newest PF from openbsd in performance and features, but instead there was a focus put on multi threading which I think overall is less beneficial.