Realtek device driver update
-
Driver support is a FreeBSD issue, not pfSense. "perform fine on many OSs" is subjective. I've had to deal with many Realtek NICs over the years and while they may stream Netflix fine, if you try to remotely approach 1Gb speeds, you will seriously hose the computer. The best Realtek I've seen managed to get my Intel i5 quad core to about 70% cpu(90k interrupts per second) usage while only peaking about 1.4Gb/s. Compare that to my Intel i210 NICs that are getting 1.9Gb/s+ while hanging out around 1-5% cpu(3k interrupts per second). These tests were done in Windows where Realtek has the best driver support.
Well, that doesn't match my experience. Since "realtek network card" details basically nothing about the chipset in question, I can't comment more than that.
In my experience the 8169, 8188 and 8111 were all pretty bad under load on Windows, Linux, MacOS and BSD. There are a few more chips but those are the ones that stood out to me. They are of course not as bad as the Nvidia nForce/MCP or Atheros L2 and L1 chips.
-
@johnkeates:
Driver support is a FreeBSD issue, not pfSense. "perform fine on many OSs" is subjective. I've had to deal with many Realtek NICs over the years and while they may stream Netflix fine, if you try to remotely approach 1Gb speeds, you will seriously hose the computer. The best Realtek I've seen managed to get my Intel i5 quad core to about 70% cpu(90k interrupts per second) usage while only peaking about 1.4Gb/s. Compare that to my Intel i210 NICs that are getting 1.9Gb/s+ while hanging out around 1-5% cpu(3k interrupts per second). These tests were done in Windows where Realtek has the best driver support.
Well, that doesn't match my experience. Since "realtek network card" details basically nothing about the chipset in question, I can't comment more than that.
In my experience the 8169, 8188 and 8111 were all pretty bad under load on Windows, Linux, MacOS and BSD. There are a few more chips but those are the ones that stood out to me. They are of course not as bad as the Nvidia nForce/MCP or Atheros L2 and L1 chips.
The numbers also don't particularly mean anything (they basically indicate the attachment type). The letters indicate what level of functionality is implemented. It's somewhat opaque, but honestly much easier to get a clear explanation of than intel's naming mess. (Quick: what's the difference between an i219-LM, an i219-V, an i211, an i350, an x520, and an x710? And that's probably about 10% of intel's current part list.)
Just to throw out some actual data, the only rtl I have online at the moment is an 8111G on a N3150 (1.6GHz braswell/atom). It hits about 1.86Gbps with a few hundred interrupts per second on linux–and that interface happens to be a on a software bridge, which probably impacts the performance a bit.
-
I think this is for FreeBSD not pfSense to fix.
For whatever reason FreeBSD does not implement the latest realtek driver, which has been shown time and time again to fix issues on realtek hardware (check the FreeBSD forums and mailing lists).
It is possible no one has ever done a PR to get the driver updated, I havent checked that.
Realtek hardware is adequate on windows for home and light business environments,, the issue on FreeBSD is the driver.
If you not willing to update the driver, I highly recommend disabling checksum offloading for realtek hardware to resolve various issues, this doesnt solve everything on realtek but fixes about 90% of observed issues I have seen over the past decade or so. Since realtek has no interrupt moderation feature, one option to also consider is enabling polling, which will moderate the interrupts OS side.
-
I think this is for FreeBSD not pfSense to fix.
For whatever reason FreeBSD does not implement the latest realtek driver, which has been shown time and time again to fix issues on realtek hardware (check the FreeBSD forums and mailing lists).
It is possible no one has ever done a PR to get the driver updated, I havent checked that.
Realtek hardware is adequate on windows for home and light business environments,, the issue on FreeBSD is the driver.
If you not willing to update the driver, I highly recommend disabling checksum offloading for realtek hardware to resolve various issues, this doesnt solve everything on realtek but fixes about 90% of observed issues I have seen over the past decade or so. Since realtek has no interrupt moderation feature, one option to also consider is enabling polling, which will moderate the interrupts OS side.
Polling is no longer available in 2.4 as only legacy and broken hardware used to profit from that.
-
polling works as I tested it, but yeah I did my own custom kernel with it available and had to be configured in the terminal not GUI.
Thanks for clarifying its no longer officially supported.
-
-
Sorry I updated my reply now as you replied again.
On 2.4.1 and newer tho the pfSense kernel is no longer in a public repo (or at least wasnt a month or so ago) so a custom kernel now no longer is possible, when I enabled it was on 2.4 dev.
-
I've been running successfully with Realtek NICs for a long time now using Realtek's official driver compiled and loaded as a module.
@TheNarc: Any chance you would have a step-by-step about how to compile the driver and the tools' setup? I gave a try but ran into lots of warnings and errors and the compilation failed. I might not have had the right compiler. FreeBSD 11.1 continues to be a challenge for me.
-
Yeah I'll try to do this when I get a chance. I just want to make sure I can give it the effort it deserves, because there are a good number of steps involved and I won't be doing anyone any favors if I try to slap something together quickly that glosses over or omits certain things :) I've always done it in Virtualbox too, which simplifies some things but complicates others. For example, in my case the path of least resistance for getting the compiled driver off the FreeBSD VM was to SCP it to a Linux machine on the same network running SSH. But that's not going to be the path of least resistance for most setups, probably. Anyway, yes, I will try to remember to do this, it just may not be in the very near future . . .
-
For example, when 2.4.0 became available, before upgrading I recompiled the Realtek driver on a FreeBSD 11.1 machine and uploaded it to /boot/kernel/ on my pfSense machine. Then I applied the 2.4.0 pfSense upgrade. And that's all I had to do, if I recall correctly. I don't think the 2.4.0 upgrade even removed the if_re_load="YES" from /boot/loader.conf.local that is needed to use the compiled Realtek driver instead of the one built into the kernel.
I think the main takeaway is that using this compiled Realtek driver is not officially supported by Netgate/pfSense, so it's very much buyer beware. But my experience has been good so far, and I think it's reasonable to assume - though there's no guarantee - that the current v1.94 Realtek driver which I compiled under FreeBSD 11.1 should work for all FreeBSD 11.x releases, but that a recompilation will be required for the first version of pfSense based on FreeBSD 12.x.
Thank you!
Just some thinks to mention, the 1.94 driver you posted works fine with CI327. However, I needed to put in following lines:
hw.pci.enable_msix="1"
hw.re.msi_disable="1"Without msix re1 wouldnt work. No single packet captured from that interface with tcpdump.
-
With regard to a write-up on how to compile this Realtek driver, user jovimon made a great one:
https://forum.pfsense.org/index.php?topic=103841.msg775568#msg775568Here's a direct link to it as well:
https://gist.github.com/jovimon/524e116471f249626fd2ccd141f3fe05 -
I have an alternate method to install this driver using only your pfSense instance:
- Edit two files using "Diagnostics" > "Edit File":
- /usr/local/etc/pkg/repos/FreeBSD.conf
- /usr/local/etc/pkg/repos/pfSense.conf
ChangeFreeBSD {enabled: no}to#FreeBSD {enabled: no}, this comments out these lines and enables the FreeBSD repository.
- Run the following commands in "Diagnostics" > "Command Prompt":
pkg update -r FreeBSDpkg install -y realtek-re-kmod
- Re-Disable the FreeBSD Repositories (undo the change in step 1), netgate has them disabled for a reason
- Edit /boot/loader.conf.local using "Diagnostics" > "Edit File":
if_re_load="YES" if_re_name="/boot/modules/if_re.ko"- Reboot your firewall
- Run
dmesgusing "Diagnostics" > "Command Prompt" and search for your interfaces in the output to verify the version
The RealTek RealTek Driver with some enhancements has made it into the FreeBSD repos.
-
@sdf_iain Thanks for this information. Do you happen to know whether this is the latest (v1.96) driver? Also, are any details available with respect to the "enhancements"?
-
It is the 1.96 driver, but I don't know what all changes have been made.
I'm not sure what the exact differences are, but the source is here if you want to try to compare.
Looks like it might take a bit to compare the two files and see what the exact differences are (mostly because the order of things is different). If I had to guess I'd say the RealTek driver's changes are incorporated into the FreeBSD version of the driver, but that's a guess. diff shows that the order of things (methods, imports, variables) is different.
-
That source appears to be for the standard FreeBSD driver, that's built into pfSense anyway.
Is that kernel module loading something different?
Steve
-
@stephenw10
My mistake that kernel module SAYS it's the 1.96_04 version from RealTekI linked the wrong source, here's the link to the module in ports:
https://svnweb.freebsd.org/ports/head/net/realtek-re-kmod/I have to admit that I do not know how that patch file is applied.
EDIT:
A quick dig into the Makefiles seems to imply that the driver is downloaded (from a FreeBSD Cache), then updated using the patch file, and finally built. -
Are you testing that in 2.5 I assume?
-
@stephenw10
2.4.5-RELEASE-p1, the RealTek RealTek driver is generally required for stability. -
Hmm, interesting that pkg only appeared to exist in head.....
-
@stephenw10
Its a very new package. If pfSense was configured to track quarterly instead latest in/etc/pkg/FreeBSD.conf, then the package wouldn't be visible.It is possible that it will show up in the branch 2020Q4, when that gets created.
