New Driver for Realtek RTL8111

[Mieze]

ok, 

 

the rsync is done. both of your forks are having some issues on my configuration. I'm seeing write speeds at around 1-2 MB/s over smb2 and a bandwith from iperf at around 12 Mbits/sec. 

with my old RTL81xx.kext I get around 60 to 70 MB/s write speeds to the network share (smb2) and iperf bandwith at around 511 Mbits/sec (still not duplex 1gigabit). and what I dont get: with my RTL81xx.kext I see around 104 MB/s write and 90MB/s read speed on my smb2 network share.... what is happening here.

I really don't want to repeat myself but your problem description exactly matches a power management issue in particular because RTL81xx.kext is a piece of junk code which not only violates the GPL deliberately but also burns CPU cycles preventing the processor from going into a deep C-State.

 

By the way, frequently switching network kexts might mess up your system causing strange behavior. I have seen this happen myself several times.

 

Mieze

[Multisaft]

ok mieze, I totally trust you, but what do I need to change to tell clover that it should not generate deep c-states? which of the different c-states are responsible for that behaviour? and is that really a problem in 10.10.5 yosemite! and not el capitan what you had reported above in your first response. and in addition, does my old x58 architecture support these deep sleep c-states?

[Mieze]

ok mieze, I totally trust you, but what do I need to change to tell clover that it should not generate deep c-states? which of the different c-states are responsible for that behaviour? and is that really a problem in 10.10.5 yosemite! and not el capitan what you had reported above in your first response. and in addition, does my old x58 architecture support these deep sleep c-states?

Frankly, I don't know how to resolve it on old hardware like 5 series mainboards because the first Hackinstosh I built had an Ivy Bridge CPU and all of my hacks I'm still using are equipped with a socket 1150 CPU. Power management is highly CPU specific and you can't apply solutions for one generation to another. Another problem is that Apple has "improved" power management with every major release of OS X in a certain way making the algorithm for C-State selection more aggressive.

 

Please send me your complete kerne logs, including a boot sequence, and an IOReg dump. Maybe I'll find some starting point for a solution.

 

Mieze

[Mieze]

As already announced a few days ago I managed to implement polled receive. Under heavy load the network stack is now allowed to switch the driver to a polled receive mode in which interrupts are disabled and the driver gets called periodically for new packets. For the polling interval I selected:

• 1ms in 10MBit mode
• 800µs in 100MBit mode
• 200µs in 1000Mbit mode

 

Performance in 1000Mbit mode is good but I haven't tested 10/100MBit throughput and it still needs some tweaking. Please keep in mind that this is experimental code. Nevertheless I'm asking everybody to test it thoroughly and give feedback. As always, I pushed the source code to GitHub.

 

Good luck testing!

 

Mieze

RealtekRTL8111-V2.2.1d0.kext.zip

[Sergio1253]

As already announced a few days ago I managed to implement polled receive. Under heavy load the network stack is now allowed to switch the driver to a polled receive mode in which interrupts are disabled and the driver gets called periodically for new packets. For the polling interval I selected:

• 1ms in 10MBit mode
• 800µs in 100MBit mode
• 200µs in 1000Mbit mode

 

Performance in 1000Mbit mode is good but I haven't tested 10/100MBit throughput and it still needs some tweaking. Please keep in mind that this is experimental code. Nevertheless I'm asking everybody to test it thoroughly and give feedback. As always, I pushed the source code to GitHub.

 

Good luck testing!

 

Mieze

 

Excellent, thank you so much Mieze! Will test later today. I saw the commit on GitHub and I was about to build

 

Muchisimas gracias!

[Multisaft]

Frankly, I don't know how to resolve it on old hardware like 5 series mainboards because the first Hackinstosh I built had an Ivy Bridge CPU and all of my hacks I'm still using are equipped with a socket 1150 CPU. Power management is highly CPU specific and you can't apply solutions for one generation to another. Another problem is that Apple has "improved" power management with every major release of OS X in a certain way making the algorithm for C-State selection more aggressive.

 

Please send me your complete kerne logs, including a boot sequence, and an IOReg dump. Maybe I'll find some starting point for a solution.

 

Mieze

 

hi Mieze,

I will try to get everything together and send it to you via private message.

[Moorre]

Mieze, Hi!

 

Thank you so much for your interest in kext development!

 

I have no questions to vers. 2.2.0. Seems to be all ok. NIC Ethernet [RealtekRTL8111]: RTL8168D/8111D: (Chipset 9)

Sorry, I have no fresh logs for 2.2.0 version, my machine running about 12 days and I have no reason to reboot it now. I'm not at home. Waiting for 10.11.4 release.

 

I'll try version 2.2.1 in a few days. Is it as always only Debug version attached upper? Because I always trying your version and if it is all ok, then I compile in XCode the Release version and use it as working stuff.

But this 2.2.1 version I can't compile in XCode with 10.11 SDK. About 13 errors to polling operator.

Can I ask you to Build Debug+Release version always for both V1 and V2 ?

[Mieze]

There is a reason why I don't publish release builds of development versions. It is work in progress which isn't ready to be used in production systems and if something unexpected happens there will be a lot of debug data in order to track down the issue which isn't the case for a release build. Beyond that, work on the driver is continuing and 2.2.1d0 is already obsolete making it futile to publish a release build.

 

By the way,I can't reproduce your problem. I downloaded version 2.2.1d0 from Github myself on another machine and successfully built the kext using Xcode 6.4 and 7.2.1 without errors.

 

Mieze

[Moorre]

Mieze! Maybe I have to build the 2.2.1 version on the other system, but strange is here:

 

[tluck]

fyi. i was able to build the latest r2.2.1d0 on el capitan Xcode 7.2.1

built it for 10.11 deployment with 10.11 SDK on 10.11.4 beta. it works just fine on my H61N-USB3 system

note: 2.2.0d0 was working just fine though!

[Mieze]

Mieze! Maybe I have to build the 2.2.1 version on the other system, but strange is here:

Looks like your copy of the source code got damaged somehow. Try to build with a new download.

 

Mieze

[Multisaft]

why do you build by yourself? i mean is it not ok to use the prebuild version of the kext? I'm just curious and want to learn.

[Mieze]

Attached to this post is version 2.2.1d2 in which I cleaned up the code and adjusted the poll interval for 100MBit mode to 1ms. Provided that nobody finds any serious issue, I will make this version the next official release. I pushed the source code to GitHub a few minutes ago.

 

Good luck testing!

 

Mieze

RealtekRTL8111-V2.2.1d2.kext.zip

Edited March 8, 2016 by Mieze

[Mrengles]

Attached to this post is version 2.2.1d2 in which I cleaned up the code and adjusted the poll interval for 100MBit mode to 1ms. Provided that nobody finds any serious issue, I will make this version the next official release. I pushed the source code to GitHub a few minutes ago.

 

Good luck testing!

 

Mieze

 

Hello Mieze

 

Thanks for all your hard work!

 

I just installed the new driver and will provide feedback in regards to my (802.3ad bonded) small office OS X server.

 

Gratitude,

 

Robert aka Mrengles

[0xPure]

Attached to this post is version 2.2.1d2 in which I cleaned up the code and adjusted the poll interval for 100MBit mode to 1ms. Provided that nobody finds any serious issue, I will make this version the next official release. I pushed the source code to GitHub a few minutes ago.

 

Good luck testing!

 

Mieze

Thank you very much!

 

I'm gonna install it because I've installed 'El Capitan' and the Internet isn't working so it's a good moment to try it ^^

 

EDIT: My Internet isn't working with this driver

[dragonmel]

Hey Mieze.. just wanted to jump in and say hi..

 

a couple questions.. did I see that you now have a driver for intel networking as well.. is yours for the DX58so Intel 82567LF Gigabit  like the 1000 driver.. how is yours different/better?

 

also, for those here with older gigabyte boards or any that are having slow thoughput..  I have had similar issues and the old lnx2mac driver works because it is not as picky on power management and irq handeling.. just food for thought.. give it a try.. not as featured or elegant as this driver but if you need speed.. its working for me..

 

I have noticed that on a recent clover build that el capitan is very sensitive to DSDT and power management.. and if its not right.. and applelpc and other power management kexts are not called for properly and devices spelled out correctly in DSDT and iopcexpoloer to match... than things go sideways quickly with sleep an performance... 

 

for example.. everything looked like it was working fine, sleep shutdown.. but lpc was not loading regularly.. once I get applelpc.kext to load, cpu temps dropped by 10c and performance both CPU and GPU increased by more than 10%.. 

[Mieze]

I ran some tests using AFP and SMB against an original iMac12,1, which seems to be a good reference for speed tests, with the latest version varying the poll interval in order to measure its influence on performance and finally decided to reduce the interval to 170µs because this seems to be the best with regard to network throughput with AFP and SMB. Values above 170µs showed a negative impact on SMB performance, whereas further decreasing the interval to 160µs and below resulted in a degradation of AFP's throughput. It looks like that this is the optimum.

 

That's why I decided to publish a new build, version 2.2.1d3, in which I adjusted the poll interval for gigabit speed to 170µs. This time I also included a release build because I'm quite sure that everything will work as expected. As always, The source code can be found on GitHub.

 

Good luck testing!

 

RealtekRTL8111-V2.2.1d3.zip

 

Hey Mieze.. just wanted to jump in and say hi..

 

a couple questions.. did I see that you now have a driver for intel networking as well.. is yours for the DX58so Intel 82567LF Gigabit  like the 1000 driver.. how is yours different/better?

 

also, for those here with older gigabyte boards or any that are having slow thoughput..  I have had similar issues and the old lnx2mac driver works because it is not as picky on power management and irq handeling.. just food for thought.. give it a try.. not as featured or elegant as this driver but if you need speed.. its working for me..

 

I have noticed that on a recent clover build that el capitan is very sensitive to DSDT and power management.. and if its not right.. and applelpc and other power management kexts are not called for properly and devices spelled out correctly in DSDT and iopcexpoloer to match... than things go sideways quickly with sleep an performance... 

 

for example.. everything looked like it was working fine, sleep shutdown.. but lpc was not loading regularly.. once I get applelpc.kext to load, cpu temps dropped by 10c and performance both CPU and GPU increased by more than 10%.. 

 

For further information about IntelMausiEthernet.kext please refer to the driver's thread at http://www.insanelymac.com/forum/topic/304235-intelmausiethernetkext-for-intel-onboard-lan/

 

Yes, you are right. El Capitan is a pain when it comes to power management and its influence on performance, in particular for us developers.

 

Mieze

[0xPure]

I ran some tests using AFP and SMB against an original iMac12,1, which seems to be a good reference for speed tests, with the latest version varying the poll interval in order to measure its influence on performance and finally decided to reduce the interval to 170µs because this seems to be the best with regard to network throughput with AFP and SMB. Values above 170µs showed a negative impact on SMB performance, whereas further decreasing the interval to 160µs and below resulted in a degradation of AFP's throughput. It looks like that this is the optimum.

 

That's why I decided to publish a new build, version 2.2.1d3, in which I adjusted the poll interval for gigabit speed to 170µs. This time I also included a release build because I'm quite sure that everything will work as expected.

 

Good luck testing!

 

Mieze

 

 

For further information about IntelMausiEthernet.kext please refer to the driver's thread at http://www.insanelymac.com/forum/topic/304235-intelmausiethernetkext-for-intel-onboard-lan/

 

Yes, you are right. El Capitan is a pain when it comes to power management and its influence on performance, in particular for us developers.

 

Mieze

You know why my ethernet isn't working with your driver? My mainboard is an ASUS M5a97 evo R2.0 and the lan... Realtek 8111F if I'm not wrong...

[Mieze]

You know why my ethernet isn't working with your driver? My mainboard is an ASUS M5a97 evo R2.0 and the lan... Realtek 8111F if I'm not wrong...

The driver is working fine with RTL8111F. In case you are having problems, please send me your kernel logs because I'm a developer, not a clairvoyant.

 

Mieze

[0xPure]

The driver is working fine with RTL8111F. In case you are having problems, please send me your kernel logs because I'm a developer, not a clairvoyant.

 

Mieze

 

Maybe isn't working for me because I must use the kernel flag npci=0x3000 and you say in the 1st post: 

• Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000. 

 

Anyways, I will send you my kernel logs. Thanks.

[spakk]

Maybe isn't working for me because I must use the kernel flag npci=0x3000 and you say in the 1st post: 

• Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000. 

 

Anyways, I will send you my kernel logs. Thanks.

@Alex,  the driver works perfect on my GigabyteBoard and I use always: npci=0x3000

look here:

 

Troubleshooting

Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine.

Use the debug version to collect log data when trying to track down problems. The kernel log messages can be found in /var/log/system.log. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant.

Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver.

Double check that you have removed any other Realtek kext from your system because they could prevent the driver from working properly.

Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000.

In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc.

In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface.

Use Wireshark to create a packet dump in order to collect diagnostic information.

Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable.

FAQ

How can I retrieve the kernel logs?

In Terminal type "grep kernel /var/log/system.log".

I want to disable Energy Efficient Ethernet (EEE) but I don't know how?

Take a look at the driver's Info.plist file. There you will find an option named enableEEE. Change its value from to . Don't forget to recreate the kernel cache after changing the value.

 

[0xPure]

@Alex,  the driver works perfect on my GigabyteBoard and I use always: npci=0x3000

look here:

 

Troubleshooting

Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine.

Use the debug version to collect log data when trying to track down problems. The kernel log messages can be found in /var/log/system.log. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant.

Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver.

Double check that you have removed any other Realtek kext from your system because they could prevent the driver from working properly.

Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000.

In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc.

In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface.

Use Wireshark to create a packet dump in order to collect diagnostic information.

Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable.

FAQ

How can I retrieve the kernel logs?

In Terminal type "grep kernel /var/log/system.log".

I want to disable Energy Efficient Ethernet (EEE) but I don't know how?

Take a look at the driver's Info.plist file. There you will find an option named enableEEE. Change its value from to . Don't forget to recreate the kernel cache after changing the value.

 

 

I don't know. I have installed another driver and is working fine, but this one doesn't work for me, that's what I mean :/

[Mieze]

Here is one more development release which makes deactivation of Active State Power Management more reliable. Source code can be found on GitHub.

 

Good luck testing!

 

Mieze

RealtekRTL8111-V2.2.1d4.zip

[Mieze]

I decided to make version 2.2.1d4 the new official release version 2.2.1 and updated the prebuilt binary in the downloads section. In case you are already using 2.2.1d4 there is no need to update because the only thing I changed is the version number.

 

Mieze 

[mitch_de]

Thanks. I dl it from the DOWNLOAD tab insanely Mac.

Q: Normally the Debug builds are bigger in file size than Release builds.

 

In the 2.2.1 build , it´s the first build where the debug build is smaller size than Release build.

Is the build in the Release folder really the the release build or perhaps copy mistake the debug build?

Thanks