Jump to content

New Driver for Realtek RTL8111

Realtek RTL8111 driver

  • Please log in to reply
549 replies to this topic

#141
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 688 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

I've captured the traffic with Wireshark and found a lot of malformed SMB packets. I used to send received packets up the network stack without the ethernet CRC and now changed it so that the upper level now gets the full packet including the 4 byte CRC checksum. I don't know why, but Wireshark shows that the number ob SMB errors has been radically reduced to only a few instead of hundreds.

With the attached version performance has improved too. I've got the following results with Blackmagic Disk Speed Test over SMB:

Realtek (Server) <---> Broadcom in iMac 2011 (Client)
Read: ~75MB/sec
Write: 5-50MB/sec but very unstable (It's strange! I'm able to boost this value up to more then 60BM/sec (stable) when doing an AFP write simultaneously!!!)

Broadcom in Mac mini 2011 (Server) <---> Realtek (Client) I guess the slow HD of Mac mini is the limiting factor here!
Read: 40-60MB/sec
Write: 40-60MB/sec

Mieze

@Maniac10: Please try this version too in order to see if it resolves the Parallels issue!


Performance with this version seems slightly better, but not the order of magnitude (and more) we should be seeing. I'm now getting 3-4MB/sec reads...

I will do some tests with BlackMagic later just so we are using the same performance test...

I also tried setting delayed_ack=0 as suggested here: http://www.techkaki....ds-in-mac-os-x/
It didn't seem to help...

#142
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Performance with this version seems slightly better, but not the order of magnitude (and more) we should be seeing. I'm now getting 3-4MB/sec reads...

I will do some tests with BlackMagic later just so we are using the same performance test...

I also tried setting delayed_ack=0 as suggested here: http://www.techkaki....ds-in-mac-os-x/
It didn't seem to help...


I'm in a hurry: Try too disable EEE too! I assume that there is an unfavorable interference between EEE shutting down the transmitter in phases of inactivity and the SMB protocol timing. I will test this later when I have time.

Mieze

Edited by Mieze, 20 May 2013 - 03:11 PM.


#143
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 688 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

I'm in a hurry: Try too disable EEE too! I assume that there is an unfavorable interference between EEE shutting down the transmitter in phases of inactivity and the SMB protocol timing. I will test this later when I have time.

Mieze


Tried disabling EEE (also tried disabling the other options in Info.plist). No joy here. Also tried running debug version, just to see if there was any bad things happening. Only one 'replaceOrCopyPacket' failed message (filtered for 'rtl8111'):

May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: PCI power management capabilities: 0xffc3.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: PME# from D3 (cold) supported.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: PCIe link capabilities: 0x00073c11, link control: 0x0143.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: Warning: PCIe ASPM enabled.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: EEE support disabled.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: TCP/IPv4 segmentation offload disabled.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: TCP/IPv6 checksum offload disabled.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: RTL8168E/8111E: (Chipset 14) at 0xffffff80ef536000, 10:1f:74:f2:f7:ef
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: MSI interrupt index: 1
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: kIOEthernetWakeOnMagicPacket added to filters.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: Already in power state 1.
May 20 08:25:29 ProBook-ML kernel[0]: RTL8111: Ethernet address 10:1f:74:f2:f7:ef
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: No medium selected. Falling back to autonegotiation.
May 20 08:25:31 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
May 20 08:25:58 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.

BTW, thanks for all your help on this...

I may play w/ Slice's driver next and see if I can get it to negotiate link speed @1000...

Edit: Managed to get slice's driver to work at 1000. Had to force it in SysPrefs -> Network -> Advanced -> Hardware. Once I did that, I get average ~45MB/sec to/from my Windows server and peak to ~55MB/sec. Maybe can figure out the difference between your version and slice's?

#144
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Managed to get slice's driver to work at 1000. Had to force it in SysPrefs -> Network -> Advanced -> Hardware. Once I did that, I get average ~45MB/sec to/from my Windows server and peak to ~55MB/sec. Maybe can figure out the difference between your version and slice's?


A few weeks ago we had a personal conversation with him about driver development and Slice told me that he had changed something in the PHY initialization. I will check his messages later to see what it is.

Mieze

#145
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats
Hello RehabMan,

here is what Slice mentioned:

"See my procedures RTL8168PowerDownPHY() and RTL8168PowerUpPHY()"


Maybe it will help you to figure out what is different.

By the way I disabled EEE too and it didn't resolve the issue completely. When the Realtek chip is the client, I get stable data rates of ~75MB/sec in both directions, but when the Realtek chip is the server reads are just as fast but writes are still slow.

The funny thing is the speedup, when there is additional traffic, even to the same SMB share. I started a copy operation of a 2GB file to the SMB share and it was slow (estimated time to complete more than 4 minutes). Then I started a second copy operation of another 2GB file and now both copy operations are accelerated dramatically (estimated time to complete less than 1 minute on both).

So I guess it isn't a pure hardware issue. From my point of view it seems to be more like a timing issue of the protocol in combination with the driver.

Mieze

#146
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats
Hello RehabMan,

I ran some small tests with Win7 using the poor Atom copying some large files from and to the Mac server with the Realtek NIC and got a throughput between 30-50MB/sec according to the time it took to complete the transfer. That is roughly what I expected with this hardware.

Also tried to use the Win7 machine as the server with the Mac server as the client. The performance was comparable to the results I got in the other scenario described above.

Mieze

#147
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 688 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

Hello RehabMan,

I ran some small tests with Win7 using the poor Atom copying some large files from and to the Mac server with the Realtek NIC and got a throughput between 30-50MB/sec according to the time it took to complete the transfer. That is roughly what I expected with this hardware.

Also tried to use the Win7 machine as the server with the Mac server as the client. The performance was comparable to the results I got in the other scenario described above.

Mieze


Thanks for trying that. I could be something to do with settings on my server, I suppose... Is your test as you mention above, realtek<->realtek or does your server have a different NIC? I have 5 "desktop" computers here and one laptop (a few tablets too, but...). Unfortunately, all the desktop systems are built on the same platform: Intel DH67xx with Intel 82579 NIC. Probook is my only Realtek.

This is 'by design' having been burned in the past by poor performing Realtek NICs, I avoided it in all my desktop builds...

But I will play around w/ the settings on the 82579 and see if there is something I can tweak there.

Otherwise, I will try to fix slice's driver (two problems I see so far: doesn't auto-negotiate 1000mbit, and doesn't work at all after sleep). Those problems, for me, might be more fixable than trying to fix this issue in yours...

At any rate, I'll let you know if I make any progress...

Thanks!

#148
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Thanks for trying that. I could be something to do with settings on my server, I suppose... Is your test as you mention above, realtek<->realtek or does your server have a different NIC? I have 5 "desktop" computers here and one laptop (a few tablets too, but...). Unfortunately, all the desktop systems are built on the same platform: Intel DH67xx with Intel 82579 NIC. Probook is my only Realtek.


My homeserver uses a MSI B75MA-P45 (i3 3225) with an RTL8111E-VL (chipset 16).
The test machine uses an Foxconn D42s (Atom D425) with an RTL8111D (chipset 9).
The 2011 iMac and Mac mini have a Broadcom 57765.

This is 'by design' having been burned in the past by poor performing Realtek NICs, I avoided it in all my desktop builds...

But I will play around w/ the settings on the 82579 and see if there is something I can tweak there.

Otherwise, I will try to fix slice's driver (two problems I see so far: doesn't auto-negotiate 1000mbit, and doesn't work at all after sleep). Those problems, for me, might be more fixable than trying to fix this issue in yours...


Taking all the facts into account, in particular the reports of similar problems with Apple hardware, I wouldn't call this a hardware issue. I rather think that there is a serious problem in Apple's SMB stack with regard to timing. With scatter-gather-DMA and task offload the drivers timing becomes less predictable and as my driver's architecture is very similar to the network drivers of recent Macs, its no no wonder that there are similar problems. The main difference is that Apple seems to have found a hack to get it working with their hardware.

Mieze

#149
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 688 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

My homeserver uses a MSI B75MA-P45 (i3 3225) with an RTL8111E-VL (chipset 16).
The test machine uses an Foxconn D42s (Atom D425) with an RTL8111D (chipset 9).
The 2011 iMac and Mac mini have a Broadcom 57765.


Thanks for the info...

Taking all the facts into account, in particular the reports of similar problems with Apple hardware, I wouldn't call this a hardware issue. I rather think that there is a serious problem in Apple's SMB stack with regard to timing. With scatter-gather-DMA and task offload the drivers timing becomes less predictable and as my driver's architecture is very similar to the network drivers of recent Macs, its no no wonder that there are similar problems. The main difference is that Apple seems to have found a hack to get it working with their hardware.


And that lnx2mac and slice's driver do not exhibit this problem...

I'll let you know what I find out when I have some time...

#150
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

And that lnx2mac and slice's driver do not exhibit this problem...

Because they copy packets to/from a DMA buffer and let the network stack do most of the work...

Mieze

#151
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 688 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

Because they copy packets to/from a DMA buffer and let the network stack do most of the work...

Mieze


It would not surprise me if Apple's SMB implementation is fundamentally flawed. I'm sure the engineers tasked with implementing it went into it kicking and screaming (NIH syndrome).

If I had a recent Mac here... (I'm actually considering it)... I'd certainly test with it. I need a light, small (13") laptop to travel with but still waiting to see what interesting laptops/convertibles Haswell may bring before I make a decision.

#152
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

It would not surprise me if Apple's SMB implementation is fundamentally flawed. I'm sure the engineers tasked with implementing it went into it kicking and screaming (NIH syndrome).

Remember how much time the SAMBA project needed to develop a SMB implementation that is suitable for serious deployment. It would be a miracle if Apple managed to get the job done within a fraction of the this time.

Mieze

#153
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats
Hello RehabMan,

I've got another idea. The problem might be related to the interrupt mitigation feature. In order to test you'll have to change in file RealtekRTL8111.cpp the line


WriteReg16(IntrMitigate, 0x5f51);

into


WriteReg16(IntrMitigate, 0x0);

Let's see if it works! I had this idea while peeking into the chip's configuration of the Win7 driver and it uses 0.

Mieze

#154
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 688 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

Hello RehabMan,

I've got another idea. The problem might be related to the interrupt mitigation feature. In order to test you'll have to change in file RealtekRTL8111.cpp the line


WriteReg16(IntrMitigate, 0x5f51);

into


WriteReg16(IntrMitigate, 0x0);

Let's see if it works! I had this idea while peeking into the chip's configuration of the Win7 driver and it uses 0.

Mieze


I tried it. If anything, it makes things marginally slower.

BTW, if I force link speed to 100mbit/sec with your driver, I get 7-8MB/sec. Does that give you any ideas?

#155
luke70

luke70

    InsanelyMac Protégé

  • Members
  • Pip
  • 4 posts
@Mieze
Sorry for my bad english. Your kext work fine but i would ask you about my card reader because have the same pci bridge and don't work. (ethernet realtek 8186, card reader). Are they linked?

#156
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

@Mieze
Sorry for my bad english. Your kext work fine but i would ask you about my card reader because have the same pci bridge and don't work. (ethernet realtek 8186, card reader). Are they linked?


There is a version of the chip that includes a card reader but as these are logically separate devices each of them needs a driver of its own.

Mieze

#157
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

I tried it. If anything, it makes things marginally slower.

BTW, if I force link speed to 100mbit/sec with your driver, I get 7-8MB/sec. Does that give you any ideas?


Not really, but it would support the timing hypothesis because Fast Ethernet lacks support for some advanced features like EEE, etc. but it's easy to reconcile with my results that putting additional load on the connection speeds up the transfer. It's a paradox but slowing things down seems to increase throughput as if the driver/NIC was too fast for the protocol stack?

Combining all the information we collected so far, it looks like many factors play a role in this scenario making it very hard to find a solution, in particular because two crucial parts, Apple's SMB stack and the NIC itself, are black boxes. For the time being, I'm completely at a loss.

Last night I also disassembled Realtek's AppleRTL8169Ethernet.kext and found out that there are five possible values for the interrupt mitigation register, 0x0000, 0x5050, 0x5151, 0xaf62 or 0xa462, but I was unable to determine which value is used for a particular chipset. Maybe I'll play with this when I find some time for experiments.

By the way, please send me a complete set of kernel messages as this might give me some hints.

Mieze

#158
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 359 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats
Hello RehabMan,

please try the attached version. As the r8169 reveals some information about the mysterious interrupt mitigate feature, I decided to play with this value a little bit.

/*
* Undocumented corner. Supposedly:
* (TxTimer << 12) | (TxPackets << 8) | (RxTimer << 4) | RxPackets
*/

Because of the high CPU load of smbd I changed interrupt mitigate to 0xaf62, one of the values used by Realtek's own driver and this solved the problem for me. Now I'm getting good performance values with SMB in both directions, read (> 70MB/sec) and write (30-60MB/sec). AFP performance stays unchanged at ~110MB/sec in both directions.

Good luck!

Mieze

Attached Files



#159
wastez

wastez

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 156 posts
  • Gender:Male
What about Wake On Lan?

Did anybody test it too?

#160
beta992

beta992

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 338 posts
  • Gender:Male

Hello RehabMan,

please try the attached version. As the r8169 reveals some information about the mysterious interrupt mitigate feature, I decided to play with this value a little bit.

/*
* Undocumented corner. Supposedly:
* (TxTimer << 12) | (TxPackets << 8) | (RxTimer << 4) | RxPackets
*/

Because of the high CPU load of smbd I changed interrupt mitigate to 0xaf62, one of the values used by Realtek's own driver and this solved the problem for me. Now I'm getting good performance values with SMB in both directions, read (> 70MB/sec) and write (30-60MB/sec). AFP performance stays unchanged at ~110MB/sec in both directions.

Good luck!

Mieze

Hi Mieze,

I'm also using SMB here. (Ubuntu Server > OS X)

Would this driver will get better results with moving files from and to the server?

I would also like to know if there's a tool to check transfer-speeds, using 1Gb/s with a (terrible) Gigabit-switch, on OS X. :)

EDIT: The reason I ask is because I (may) have a different ethernet-controller. (RTL8168E/8111E)

Thanks!





Also tagged with one or more of these keywords: Realtek, RTL8111, driver


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   Web hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy