Official Realtek Driver Binary 1.95 For 2.4.4 Release

  • Netgate Administrator

    The missing description is unlikely to matter.

    I was more interested in the queue or interrupt loads on your CPU cores while testing. igb will use multiple CPU cores by default. re usually isn't but this is new hardware so....

    CPU usage between those NICs looks to be inline with the throughput at least.


  • @breakaway Thanks, you save me!!!

  • @Rico

    THANKS! it works (on Xigmanas 12.1)

    Do you know if WOL works? I tried to activate it, but I wasn't been able to make it work. Not sure if it's something that I do or it's just that it's not implemented in the driver (or the board for that matters).

    Thank you

  • LAYER 8 Rebel Alliance

    Nope sorry, I don't own any Realtek Card. 😊


  • Netgate Administrator

    Now that there is a FreeBSD package for this I would use that over a, relatively, unknown binary source:

    pkg add

    That would be much easier if it was in our repo though. Let me see...


  • Netgate Administrator

    Should be in snaphots soon.

  • Netgate Administrator

    Looks good:

    [2.5.0-DEVELOPMENT][admin@apu.stevew.lan]/root: pkg search realtek
    realtek-re-kmod-v196.04_2      Kernel driver for Realtek PCIe Ethernet Controllers

    So do:
    pkg install realtek-re-kmod
    echo 'if_re_load="YES"' >> /boot/loader.conf.local

    Then reboot and check the boot logs for:

    re0: <Realtek PCIe GbE Family Controller> port 0x1000-0x10ff mem 0xf7a00000-0xf7a00fff,0xf7900000-0xf7903fff irq 16 at device 0.0 on pci1
    re0: Using Memory Mapping!
    re0: Using 1 MSI-X message
    re0: ASPM disabled
    re0: version:1.96.04
    re0: Ethernet address: 00:0d:b9:37:30:10

    Current version should be installed every time. It's built against our kernel source etc.

    It's unlikely this will be backported to 2.4.5 but far easier (and probably safer) to use in 2.5 when it's released or in snapshots now.


  • @stephenw10 For some reason I cannot seem to get this to load.
    I had the previous driver loaded on 2.4.5 but have upgrade to 2.5.0-Development

    I've followed your instructions, it appears to install OK, but I can't see it in kldstat nor does my log look like yours. Do you have any suggestions on what i might be doing wrong?

    [2.5.0-DEVELOPMENT][]/boot: cat loader.conf.local

    My logs

    Dec 12 13:04:04	kernel		re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xe000-0xe0ff mem 0x81300000-0x81300fff,0xa0100000-0xa0103fff irq 16 at device 0.0 on pci1
    Dec 12 13:04:04	kernel		re0: Using 1 MSI-X message
    Dec 12 13:04:04	kernel		re0: Chip rev. 0x2c800000
    Dec 12 13:04:04	kernel		re0: MAC rev. 0x00100000
    Dec 12 13:04:04	kernel		miibus0: <MII bus> on re0
    [2.5.0-DEVELOPMENT][]/boot: kldstat
    Id Refs Address                Size Name
     1   25 0xffffffff80200000  3ae7ee0 kernel
     2    1 0xffffffff846fa000     1000 cpuctl.ko
     3    1 0xffffffff846fb000     8c90 aesni.ko
     4    1 0xffffffff84704000     37f8 cryptodev.ko
     5    1 0xffffffff84708000      b28 coretemp.ko
     6    1 0xffffffff84709000    26fe8 ipfw.ko
     7    1 0xffffffff84730000    10e18 dummynet.ko
    [2.5.0-DEVELOPMENT][]/boot: pkg info | grep realtek
    realtek-re-kmod-v196.04_2      Kernel driver for Realtek PCIe Ethernet Controllers
    [2.5.0-DEVELOPMENT][]/boot/modules: ls -al
    total 1300
    drwxr-xr-x   2 root  wheel      512 Dec 12 13:42 .
    drwxr-xr-x  10 root  wheel     1536 Dec 12 13:32 ..
    -r-xr-xr-x   1 root  wheel   106328 Nov 11 13:23 bwi_v3_ucode.ko
    -r-xr-xr-x   1 root  wheel  1168400 Nov 20 04:51 if_re.ko
    -rw-r--r--   1 root  wheel      148 Dec 12 13:29 linker.hints

  • Nevermind, I had so many other issues I've rolled back to 2.4.5 so it's probably moot.

  • Netgate Administrator

    Hmm, looks like you have everything right. You could try this additional line in loader.conf.local, though I did not need it here, the loader looks there anyway:



  • Hi all,

    New to the pfSense world but wanted to follow up on this discussion. I've successfully compiled & installed the latest if_re.ko drivers from Realtek, v1.96.04, for my RTL8111/8168/8411 Gigabit ethernet controller (re0 interface). They are loaded upon boot without issue, as per kldstat and looking at logs in the web UI (Status > System Logs > System > General).
    This is an integrated controller on my motherboard (old P7H55-M PRO from Asus) which I'm testing for use as WAN in a homelab setup while I wait for my Intel NICs for LAN. The link is also recognized as 1Gbps as per ifconfig (1000Base-T <full-duplex>).

    I am facing performance issues though when benchmarking with iperf3. Using Cat5e or Cat6 cabling all around, with short runs from the firewall to my client, and have tried new cables as well.

    Using iperf3, when re0 is the SERVER, I get about 450Mbps. When re0 is the CLIENT, I get a big range, but about 450-600Mbps on average, sometimes peaking at 800Mbps for an entire run if I'm lucky. Retry (Retr column) is almost always all 0 or thereabouts.

    The same client can easily get 900+ Mbps with another iperf3 server on the network.

    I looked into CPU and memory usage during the tests, plenty of free memory on the system (8GB RAM on system), swap not in use at all. As for the CPU (Intel Core i3-530), usage looks something like this, with lots of idle room...

    CPU:  0.7% user,  0.0% nice,  8.0% system, 16.7% interrupt, 74.6% idle

    I was wondering if anyone faced similar performance issues, with lack of consistency seeming to occur as well (although never a steady 900Mbps+ or even 800Mbps+)? I saw that @nitewolfgtr and @stephenw10 spoke a bit about performance issues on a 2.5G card, but never came to any conclusions.


  • @networkingmicrobe I had the same issue with my Qotom with the built in realteks. It seemed to have some magic stop around 450mbits, sometimes though it would go up to 600mbits. There appeared to be plenty of CPU left but it just maxed out. I replaced it with a new box with Intel NIC's and hit wire-speed gigabit easily.

  • Netgate Administrator

    @networkingmicrobe said in Official Realtek Driver Binary 1.95 For 2.4.4 Release:


    That's a 2 core 4 thread CPU so 74% idle could be 1 virtual core at 100%. Potentially the core running iperf.
    Try running top -aSH while you test.

    Better to test through the firewall rather than to or from it directly.


  • @networkingmicrobe If you want to benchmark pfSense on a particular device and setup. run iperf through pfSense not on it.

    It has been said MANY times on the fourms.

    Using iperf on the pfsense system itself is not a valid gauge at routing performance.

  • @networkingmicrobe I'm not entirely sure, but I suspect that the driver is limited in that one TCP/UDP stream can only utilize one core on the CPU, simply put, 450Mbps is what a single core on your CPU (Intel Core i3-530) can handle if you run iperf with one client thread (should be default).

    You can test that by running iperf on the client side with more threads using -P (that's a capital P), something like:

    iperf -c -P 4

    Will run the client with 4 threads, each opening their own TCP stream (adjust IP address to whatever you are using).

  • @napsterbater correct, it is not a valid gauge at routing performance, however I suspect that @networkingmicrobe is attempting to find out wether or not his NIC is capable of sending data close to the 1Gbit linespeed, not the actual routing throughput.

  • @griffo - Thanks for the tip, looking forward to my Intel NICs then! Interesting that this seems to keep happening with integrated (on-motherboard) Realtek NICs, though.

    @stephenw10 - You bring up a good point, thanks. That result I pasted above was actually from top -aSH. In that case, I'd expect the same results on an Intel NIC (over PCIe), since it may be an issue with single-core clock speed. It looks like cpu0 (first core) is being used the most during a single-stream iperf3 test, with WCPU% of [idle{idle: cpu0}] dropping down during the test to about 50% and then back to 99% after.
    I tried increasing the number of parallel streams to 2, and then 4, like @Cybermaze suggested, but saw same results in terms of throughput (~400Mbps) and core utilization (mostly cpu0, perhaps some of core1 too).

    @Napsterbater - I realize benchmarking pfSense is best done by going through the firewall, but what I wanted to simulate here was the maximum theoretical line speed by testing to the WAN port directly. I realize it's not at all indicative of performance through the firewall on other LAN devices, but is a 'sanity check' I'd like to try first, if that makes sense, to see if I can ever get the theoretical ~1Gbps line speeds expected to begin with. Basically what @Cybermaze suggested in their comment above.

    Thanks all for your quick and informative replies, perhaps it's just a limitation of my onboard NIC for some reason.

  • Netgate Administrator

    iperf3 is in fact single threaded and will only ever use one CPU core. The -P switch can make it run multiple client streams, which can take advantage of multiqueue NICs for interrupt load, but it will still only use one CPU core on the client and server machine for iperf itself. Which is another good reason to test through the firewall.

    If you need to test like that try running multiple iperf servers or clients on different ports simultaneously.


  • @Cybermaze - Small update, using multiple client streams into a pfSense iperf3 server yields similar results as a single stream of ~400-450Mbps.
    However, I noticed when using multiple client streams when pfSense is the client and another device is the server, I can get steady 800Mbps throughput, much closer to theoretical 1000Mbps max line speed. Interesting...

    I'll look into running multiple iperf servers simultaneously as well, thanks @stephenw10.

  • Finally got around to adding some gigabit Intel NICs to the build, and sure enough I can easily obtain 960+ Mbps both to the firewall (to see WAN theoretical max speed) and through the firewall. So definitely something funky going on with the onboard Realtek NIC, like @griffo mentioned, despite using the latest drivers v1.96.04 from Realtek. Not crucial to fix I guess, but still interesting to note for others who may have similar issues in the future.