Yeah, use Intel NICs of you can. You can find a PCI card and it will almost certainly be compatible. Of course anything with 32bit PCI slots will be relatively ancient as will the cards to go in it so that reliability is a factor.
The SG-1100 is not really comparable as it's a complete ARM SoC.
@tman222 There are no additional expansion cards in the system. This is running on bare metal. Keep in mind when I had cable internet (1 gbps / 20 mbps) I achieved 960-980 mbps download under the same configuration. I do not have random id generation enabled. I have tried it with and without hyperthreading. I have also tried it with and without turbo boost. Nothing seems to help. This is why I am leaning towards an incompatibility between the modem and the network card but I am open to ideas and suggestions prior to buying a new NIC. Thanks.
If you can find one that uses a supported driver (I don't think there are any at the moment), then it would almost certainly not reach anywhere near line rate. How close you get depends entirely on the hardware, though.
What is your use case? Almost certainly you'd be better off with something geared more toward high performance at that level, like TNSR.
I'll second @provels suggestion - I think the i340-T4 provides great bang for the buck. I bought two of these on Amazon (at different times) over the last year and both have worked great (in fact one of them is currently being used in a pfSense box).
If it were me, given the price here and looking at the seller reputation, I'd probably roll the dice on this. But the choice is ultimately is yours. I do recall that one of the i340 I received was actually an OEM IBM version, but again, it has worked just fine.
If you are set on 10Gbit NIC's, I'd also take a look at Chelsio cards which are very well supported in pfSense/FreeBSD. One can find good deals on the T520. I've used both the T520-SO-CR and T540-SO-CR with pfSense without any troubles.
Hope this helps.
First check the BIOS can see any temperature values. Usually they will display at least CPU temp, often some other thermal zones where sensors exist. If those are all enabled they are usually passed to the OS via ACPI but it maybe another crappy BIOS that has DSDT values tested, and marked as, Windows only. In which case just make sure you're on the latest BIOS.
Fixing that is almost certainly more effort that it's worth.
The last time this came up:
This is also Zen micro-architecture CPU so the same applies. It may require amdsmn which only appeared in FreeBSD 12.
Yup NMI is almost 100% a hardware fault. In the 0.1% cases where is seems to be OK with other OSes it's something specific that FreeBSD is hitting and there's nothing you can do about it anyway. So swap it out.
@suplantor Just making assumptions but... Shouldn't the Silicom drivers work? Not sure which model you have, but start with the link below and drill down to your card. Drivers available for multiple OSs including FreeBSD.
@stephenw10 Thanks Steve, yep the VLAN biz will all be handled at the switch, the pfSense facing port is a trunk and from there just as you cautioned, each port will need be placed in an access mode for the proper VLAN it needs to join, that's a manual task and care will be the key playbook!
Short answer: you can't.
To do so would require compiling from source and creating all the required components for that specific board. ARM is not like x86, there isn't a generic installer for all ARM devices.
a Six core Xeon wouldn't be able to handle 10GbE?
higher cpu frequency would be better
also a 6 year old cpu is far less performant then a recent one ...
i would even dare to say that a current-gen i3 cpu would perform better with pfsense than that xeon you are using
Go to Diag > Command Prompt and execute mount -p. You should see something like:
/dev/diskid/DISK-9E18E959s2a / ufs rw,noatime 1 1
devfs /dev devfs rw 0 0
/dev/diskid/DISK-9E18E959s1 /boot/u-boot msdosfs rw,noatime 0 0
/dev/md0 /tmp ufs rw 2 2
/dev/md1 /var ufs rw 2 2
devfs /var/dhcpd/dev devfs rw 0 0
You can see on that SG-3100 the root filesystem / is mounted 'noatime'.
If yours is not go to Diag > Edit File an open /etc/fstab. Edit the / line to include noatime. So it would probably just be rw. Change it to rw,noatime.
Note that breaking the fstab with a typo will probably make the system unbootable until it's corrected so....
Reboot to apply that change. Run mount -p again to be sure.
@Gertjan said in pfSense custom build hardware with Realtek port dilemma:
edit : wtf : @stephenw10 : more then 18 K posts ...
Yeah it's a problem. I'm trying to cut down!
Probably not. Fortigate used special purpose chips (usually ASICs) in their devices to get the throughput they need and those are not accessible without their code. The 90D appears no different:
Combines a RISC-based CPU with Fortinet’s proprietary SPU content and network processors for unmatched performance
So you might get the management plane running pfSense if that part is x86 but you won't get any of switch ports available and performance will be..... limited!
Or it may just not be possible at all.
If you are looking to have a go at compiling pfSense, or anything, you would not likely be using the same hardware.
pfSense requires relatively low powered hardware to run but you probably want something much more powerful to compile on unless you don't mind waiting.
Also pfSense itself does not contain any compile tools so compiling and running on the same hardware would require some sort of dual boot setup with FreeBSD.
@lifespeed said in Supermicro Xeon D X10SDV-4C+-TP4F with 10Gb SFP+ pfSense compatibility?:
@tman222, thanks for sharing your experiences. It sounds a little flaky, but not insurmountable. It sounds like a few people are looking forward to some fixes in the new version, which is not the greatest position to be in.
I'm not sure there are many other good options for 10Gb SFP router hardware.
Hi @lifespeed - the other option would be to use an SFP+ add-on card. I have used both the Chelsio T520 and T540 SFP+ cards (in fact the T540 is currently installed) and these have been rock solid.
I seem to be having some instability issues with my APU2C. It was running OK for over a week. This morning the orange lights on each NIC were not flashing and all connected clients were receiving a self-assigned IP address.
The only way to resolve this was to reboot I had a look through the logs but couldn't find anything. My grafana dashboard shows that something odd started to occur around midnight:
CPU temperature on average is about 53 degrees Celsius and it is running the latest BIOS v184.108.40.206||spoiler||
Just want to let you guys know: I have the Qotom Q575G6 with Multi WAN Gigabit and Suricata running. IPsec VPN brings the CPU up to 40% usage. I'm really happy with this device. It's running flawless and very fast.
ZFS seems the most vigorous FS available in pfS, that's why I moved over from UFS to ZFS. The (re)install is a breeze, with a current config file at hand.
My APU2C4 has ECC and to me this and the ZFS FS seems max what I can do against sudden power surges, that being said, I would always use the "halt" command before I pull the power cord ;)
@bouke Kudos for pointing out the flaky mSATA issue link, didn't knew that.
@phatty that is unfortunate. I did find some old documentation on features that were made available to customers like AT&T, but unfortunately, AT&T never implemented them. One of the features was a Pass-Through for customer data, which allowed the gateway to also perform the required tasks that allow it to work on AT&T's ATM network. I'd describe it as a smart Bridged Mode that doesn't prevent the gateway from doing what it needs to do. They have many different options to implement what is needed, but I have a feeling that they aren't doing it to force you to upgrade to an OC3 or similar connection. :/
50% CPU usage on that dual core CPU is probably 100% on one core if you;re checking on the dashboard.
Suricata can use the other core bringing it up to 100% total. You would have to check at the command line to see the CPU usage breakdown: top -aSH.
That is more that I would have thought but the single thread rating of the E4500 is significantly higher than, say, the J1900 that has been seen to be limited to ~500Mbps PPPoE. Though those Celerons seem particularly effected by this for some reason.
Just to add in case people still have pppoe performance caps due to cpu power, make sure you enable powerd on units that support intel turbo.
Without powerd turbo clocks wont kick in. powerd isnt just for power saving.
Also it seems "some" igb chips do support rss properly with pppoe, I switched to a pppoe isp last month and see my rss is working properly on the igb driver. I have 2 queues for both isr and igb, the rx is almost a 50/50 split, and its tx thats lopsided at 90/10.
Yeah, I would ask on the OpenWRT forum: https://forum.openwrt.org/
But.... get the x86 image. Try to make it boot from it. Check the console output toi see what it working and what isn't. Make changes as necessary.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive for past announcements.