Jump to content

New Driver for Realtek RTL8111

Realtek RTL8111 driver

  • Please log in to reply
767 replies to this topic

#221
imacX86

imacX86

    InsanelyMac Protégé

  • Members
  • Pip
  • 7 posts
  • Gender:Male

Hey, no worries!

 

If I run across people who experience the problem, I'll point them to my fork.

 

The only reason I went down this path is because the only use I have for ethernet on my laptop is when I need to transfer large files (usually video), because generally ethernet is much much faster than WiFi.  With the performance of your driver without my patches, that was not the case, so I needed to come up with a solution.

 

Thanks for the feedback and great starting point.  Good luck with your iOS projects.

I was able to pull from your fork. Thanks for merging it with latest master branch! 



#222
Mieze

Mieze

    Giant Cat

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

Hey RehabMan,

 

please try this! While doing some research on the interrupt rate, I had an idea how to improve performance without causing much additional CPU load.

 

Mieze

Attached Files



#223
imacX86

imacX86

    InsanelyMac Protégé

  • Members
  • Pip
  • 7 posts
  • Gender:Male

Hey RehabMan,

 

please try this! While doing some research on the interrupt rate, I had an idea how to improve performance without causing much additional CPU load.

 

Mieze

I have tried this on my ProBook 4440s. Not very good results: barely ~5MBs with drops to 200KBs. With latest RahabMan driver ~60MBs. with drops to 39MBs.

 

To get a prospective on my network raw performance: NFS - 117MBs sustained on RehabMan driver.



#224
Mieze

Mieze

    Giant Cat

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

I have tried this on my ProBook 4440s. Not very good results: barely ~5MBs with drops to 200KBs. With latest RahabMan driver ~60MBs. with drops to 39MBs.

 

To get a prospective on my network raw performance: NFS - 117MBs sustained on RehabMan driver.

 

As the remote machine is causing this issue, please describe it's configuration, CPU, NIC and OS.

 

Mieze



#225
imacX86

imacX86

    InsanelyMac Protégé

  • Members
  • Pip
  • 7 posts
  • Gender:Male

As the remote machine is causing this issue, please describe it's configuration, CPU, NIC and OS.

 

Mieze

The remote is Open Solaris variant (Nexenta NAS) 3-core AMD CPU with Intel NIC (Intel Gigabit CT PCI-E Network Adapter EXPI9301CTBLK). It is running full-duplex from Windows (120MBs both ways) and real Macs. I have (RahabMan) comparable speed readings with iMacs/MBP/mini/Hacks with Marvell Yukon Gigabit Adapter 88E8053. So no there is no any issues with remote machine it has been rock solid performer for years.

 

SMB is not exactly best performing on Lion, it is even worse on ML, but not that slow (5MBs). On AFP I am getting ~124MBs Mac-to-Mac, Mac-to-Hack, Hack-to-Hack (on Marvell NICs).  I did not try AFP with Realtek NIC though. When on WiFi (5GHz) - I am getting 15MBs (ProBooks 4540s). Wired 1Gbs should be faster then any WiFi for sure.

 

Just to be clear, I use MBs as Mega Bytes per Seconds.



#226
Mieze

Mieze

    Giant Cat

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

It is Open Solaris variant (NEXENTA) with Intel NIC. It is running full-duplex from Windows (120MBs both ways) and real Macs. I have (RahabMan) comparable speed readings with iMacs/MBP/mini (Marvell Yukon Gigabit Adapter 88E8053).

 

Yeah, the Intel NICs seem to be problematic with SMB in some configurations. I guess it's some kind of NAS? Why do you use SMB instead of AFP as Netatalk is available for this platform and virtual any good NAS comes with it?

 

Mieze



#227
imacX86

imacX86

    InsanelyMac Protégé

  • Members
  • Pip
  • 7 posts
  • Gender:Male

Yeah, the Intel NICs seem to be problematic with SMB in some configurations. I guess it's some kind of NAS? Why do you use SMB instead of AFP as Netatalk is available for this platform and virtual any good NAS comes with it?

 

Mieze

I use NFS on Macs and SMB on Windows. I tested driver you provided to see if it makes any difference in SMB performance with your latest research. Intel NICs are reference type in my view. Although on Macs it may be different story.



#228
Mieze

Mieze

    Giant Cat

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

I use NFS on Macs and SMB on Windows. I tested driver you provided to see if it makes any difference in SMB performance with your latest research. Intel NICs are reference type in my view. Although on Macs it may be different story.

 

Intel NICs have a very rigid interrupt mitigation logic which does not get along with Apple's SMB implementation.

 

Mieze



#229
RehabMan

RehabMan

    InsanelyMac Legend

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

Hey RehabMan,

 

please try this! While doing some research on the interrupt rate, I had an idea how to improve performance without causing much additional CPU load.

 

Mieze

I'll try to look at this later this week and provide some feedback.

 

Interesting though (I looked at the diff)... processing rxInterrupt even though related rx status bits in IntrStatus are not set?!



#230
Mieze

Mieze

    Giant Cat

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

I'll try to look at this later this week and provide some feedback.

 

Interesting though (I looked at the diff)... processing rxInterrupt even though related rx status bits in IntrStatus are not set?!

 

Basically it boils down to reverting the effect of interrupt mitigation while operating with moderate load as there are much more transmitter than receiver interrupts. If the rx interrupt bit isn't set this doesn't necessarily mean that no packets have been received yet and checking the receiver ring once is cheap as we are already in the interrupt routine. Instead of periodically calculating the average interrupt rate I'm now working with a modified algorithm measuring the time interval between interrupts with kFastIntrTreshhold set to 200µs.

void RTL8111::interruptOccurred(OSObject *client, IOInterruptEventSource *src, int count)
{
    UInt64 time, abstime;
	UInt16 status;
    UInt16 rxMask;
    
	WriteReg16(IntrMask, 0x0000);
    status = ReadReg16(IntrStatus);
    
    /* hotplug/major error/no more work/shared irq */
    if ((status == 0xFFFF) || !status)
        goto done;
    
    /* Calculate time since last interrupt. */
    clock_get_uptime(&abstime);
    absolutetime_to_nanoseconds(abstime, &time);
    rxMask = ((time - lastIntrTime) < kFastIntrTreshhold) ? (RxOK | RxDescUnavail | RxFIFOOver) : (RxOK | RxDescUnavail | RxFIFOOver | TxOK);
    lastIntrTime = time;
    
    if (status & SYSErr)
        pciErrorInterrupt();
    
    /* Rx interrupt */
    if (status & rxMask)
        rxInterrupt();

    /* Tx interrupt */
    if (status & (TxOK | TxErr | TxDescUnavail))
        txInterrupt();
    
    if (status & LinkChg)
        checkLinkStatus();
    
    /* Check if a statistics dump has been completed. */
    if (needsUpdate && !(ReadReg32(CounterAddrLow) & CounterDump))
        updateStatitics();
    
done:
    WriteReg16(IntrStatus, status);
	WriteReg16(IntrMask, intrMask);
}

Maybe this will open up a new perspective with adaptive receiver interrupt mitigation, with low values like 0x51 for moderate load and 0x58 for heavy load. I don't know if this is possible but it might be worth a try. I was able to get good performance with this version while communicating with the 2006 MacBook Pro (Marvell Yukon) running Win XP without changing it's maximum interrupt rate from 5000 to 10000 as I had to do with version 1.1.1 for a reasonable performance.

 

By the way the inspiration for the change comes from the documentation of the Broadcom BCM57785 which has a quite sophisticated interrupt mitigation logic.

 

Mieze



#231
RehabMan

RehabMan

    InsanelyMac Legend

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

Basically it boils down to reverting the effect of interrupt mitigation while operating with moderate load as there are much more transmitter than receiver interrupts. If the rx interrupt bit isn't set this doesn't necessarily mean that no packets have been received yet and checking the receiver ring once is cheap as we are already in the interrupt routine. Instead of periodically calculating the average interrupt rate I'm now working with a modified algorithm measuring the time interval between interrupts with kFastIntrTreshhold set to 200µs.

void RTL8111::interruptOccurred(OSObject *client, IOInterruptEventSource *src, int count)
{
    UInt64 time, abstime;
	UInt16 status;
    UInt16 rxMask;
    
	WriteReg16(IntrMask, 0x0000);
    status = ReadReg16(IntrStatus);
    
    /* hotplug/major error/no more work/shared irq */
    if ((status == 0xFFFF) || !status)
        goto done;
    
    /* Calculate time since last interrupt. */
    clock_get_uptime(&abstime);
    absolutetime_to_nanoseconds(abstime, &time);
    rxMask = ((time - lastIntrTime) < kFastIntrTreshhold) ? (RxOK | RxDescUnavail | RxFIFOOver) : (RxOK | RxDescUnavail | RxFIFOOver | TxOK);
    lastIntrTime = time;
    
    if (status & SYSErr)
        pciErrorInterrupt();
    
    /* Rx interrupt */
    if (status & rxMask)
        rxInterrupt();

    /* Tx interrupt */
    if (status & (TxOK | TxErr | TxDescUnavail))
        txInterrupt();
    
    if (status & LinkChg)
        checkLinkStatus();
    
    /* Check if a statistics dump has been completed. */
    if (needsUpdate && !(ReadReg32(CounterAddrLow) & CounterDump))
        updateStatitics();
    
done:
    WriteReg16(IntrStatus, status);
	WriteReg16(IntrMask, intrMask);
}

Maybe this will open up a new perspective with adaptive receiver interrupt mitigation, with low values like 0x51 for moderate load and 0x58 for heavy load. I don't know if this is possible but it might be worth a try. I was able to get good performance with this version while communicating with the 2006 MacBook Pro (Marvell Yukon) running Win XP without changing it's maximum interrupt rate from 5000 to 10000 as I had to do with version 1.1.1 for a reasonable performance.

 

By the way the inspiration for the change comes from the documentation of the Broadcom BCM57785 which has a quite sophisticated interrupt mitigation logic.

 

Mieze

>> If the rx interrupt bit isn't set this doesn't necessarily mean that no packets have been received yet and checking the receiver ring once is cheap as we are already in the interrupt routine.

 

Yes, I was thinking why not just check for rx packets for every interrupt...  It might be cheaper than trying to "calculate whether it should be checked"

 

I'll play with when I get a free afternoon...



#232
Mieze

Mieze

    Giant Cat

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

>> If the rx interrupt bit isn't set this doesn't necessarily mean that no packets have been received yet and checking the receiver ring once is cheap as we are already in the interrupt routine.

 

Yes, I was thinking why not just check for rx packets for every interrupt...  It might be cheaper than trying to "calculate whether it should be checked"

 

As long as there are only a few thousand packets per seconds this is no problem, it even makes the the system more responsive, but under heavy load you'll might get more then 80000 packets per second. Feeding them into the network stack in small groups of 2 or 3 has a devastating impact on CPU load. You have to handle them in a batch in order to keep CPU usage under control.

 

My results indicate that the units of the interrupt mitigate value are not the number of packets but the number of descriptors processed. While receive buffers are contiguous, which means that there is exactly one descriptor per packet, transmit buffers are fragmented so that each packet usually requires 2 or more descriptors with up to more than 30 for large TSO operations. On my machine this results in more than 15000 transmitter interrupts when it is sending at full speed even with maximun interrupt mitigation value of 0xff. On the other hand the receiver interrupt rate never exceeds 10000 which is an acceptable value. Despite the context switch the transmitter interrupts have a surprisingly low influence on the CPU load.

 

Unfortunately receiver interrupt handling is not that cheap in case there are actually packets to handle because they might trigger a series of processes. While you have to handle 1000 or 2000 packets per second there is no significant increase in CPU usage, when you handle them individually instead of doing batch processing but it will even make the system react faster. A good example for this scenario is listing a large share with ls -lR in Terminal. Compared to a scenario where you transfer a large file with a throughput of 110MB/s the situation is completely different. Doing batch receives the CPU usage stays down at 20-30% instead of more than 50% without receiver interrupt mitigation.

 

Mieze



#233
Mieze

Mieze

    Giant Cat

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

Hello RehabMan,

 

here are my latest sources. I ran some SMB tests this afternoon with the 2006 MacBook Pro (WinXP SP3, Marvell Yukon) and was able to copy a 2GB file to/from the OS X server with the Realtek NIC in less than 45 seconds (throughput ~45MB/sec). Although this might not seem impressive it's exactly want was to expect taking the fact into account that the Bootcamp partition, which is located at the end of the harddisk, is not able to deliver a higher data rate. Therefore it might be as well possible that the disk and not the Network is the limiting factor.

 

Comparing these results with the initial test results I got when I did the first SMB benchmarks with this configuration 6 weeks ago, SMB performance has improved dramatically. It went up from ~5MB/s to 45MB/s stable. I'm not sure if these results are reproducible with an Intel NIC on the Windows side but I'm quite confident that we are on the right track.

 

Besides the small modification of the interrupt service routine I changed the interrupt mitigate value to 0xff68 which reduced the interrupt rate under heavy load by 25% and, as a bonus, results in a few percent less CPU usage.

 

Mieze

Attached Files



#234
beta992

beta992

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 338 posts
  • Gender:Male

Hello RehabMan,

 

here are my latest sources. I ran some SMB tests this afternoon with the 2006 MacBook Pro (WinXP SP3, Marvell Yukon) and was able to copy a 2GB file to/from the OS X server with the Realtek NIC in less than 45 seconds (throughput ~45MB/sec). Although this might not seem impressive it's exactly want was to expect taking the fact into account that the Bootcamp partition, which is located at the end of the harddisk, is not able to deliver a higher data rate. Therefore it might be as well possible that the disk and not the Network is the limiting factor.

 

Comparing these results with the initial test results I got when I did the first SMB benchmarks with this configuration 6 weeks ago, SMB performance has improved dramatically. It went up from ~5MB/s to 45MB/s stable. I'm not sure if these results are reproducible with an Intel NIC on the Windows side but I'm quite confident that we are on the right track.

 

Besides the small modification of the interrupt service routine I changed the interrupt mitigate value to 0xff68 which reduced the interrupt rate under heavy load by 25% and, as a bonus, results in a few percent less CPU usage.

 

Mieze

Hi Mieze,

 

After some testing, I found out that Finder is the real problem. It's very slow when browsing through shares.

I'm now using Path Finder (as trial) and see a lot of improvements. Browsing though folders/files is really 10x times faster.

 

Just search on "Finder slow smb" and you will see a lot of others suffering from the same issue, especially on ML.

 

Last question: what version should I use? The last one you posted above or the one from the download center? :)



#235
Mieze

Mieze

    Giant Cat

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

Hi Mieze,

 

After some testing, I found out that Finder is the real problem. It's very slow when browsing through shares.

I'm now using Path Finder (as trial) and see a lot of improvements. Browsing though folders/files is really 10x times faster.

 

Just search on "Finder slow smb" and you will see a lot of others suffering from the same issue, especially on ML.

 

Last question: what version should I use? The last one you posted above or the one from the download center? :)

 

Hello beta992,

 

please use the attached version which has been optimized not only to speed up SMB in certain configurations but also to deliver a better browsing speed. I tested it recursively listing large shares and browsing directories with dozens of pictures.

 

The trick is a small change in the interrupt service routine with regard to the strategy of handling received packets. When more than 200µs have been passed since the routine was called the last time, it assumes that there is not much load and handles the packet with less delay (but also less efficiently) which turned out to be better in this situation. I also changed the interrupt mitigate value to 0xcf68.

 

As I will make the attached code the official version 1.1.2, provided that nobody finds any serious bugs in it, everybody is encouraged to test it.

 

Mieze

Attached Files



#236
Henry2010

Henry2010

    InsanelyMac Protégé

  • Members
  • Pip
  • 16 posts
i have been refreshing this thread for almost a week for 1.1.2 binary .... Can't wait ^^

#237
Mieze

Mieze

    Giant Cat

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

i have been refreshing this thread for almost a week for 1.1.2 binary .... Can't wait ^^

 

Before pushing a new version to github and updating the binary, the code usually has to pass a 24/7 real world test on my home server for at least 1-2 weeks. As of now I haven't received any bug reports nor did I experience any problems so that I will officially release version 1.1.2 next week.

 

Mieze



#238
RehabMan

RehabMan

    InsanelyMac Legend

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

Hello beta992,

 

please use the attached version which has been optimized not only to speed up SMB in certain configurations but also to deliver a better browsing speed. I tested it recursively listing large shares and browsing directories with dozens of pictures.

 

The trick is a small change in the interrupt service routine with regard to the strategy of handling received packets. When more than 200µs have been passed since the routine was called the last time, it assumes that there is not much load and handles the packet with less delay (but also less efficiently) which turned out to be better in this situation. I also changed the interrupt mitigate value to 0xcf68.

 

As I will make the attached code the official version 1.1.2, provided that nobody finds any serious bugs in it, everybody is encouraged to test it.

 

Mieze

I finally had a chance to test this version.  I'm afraid the original performance problems on my ProBook are still present.

 

With your version (1.1.2):

Reads: getting 7-10MB/sec for large file copy from server to laptop.

Writes: getting 1-7MB/sec for large file copy from laptop to server.

 

With my version:

Reads: getting 60MB/sec for large file copy from server to laptop.

Writes: getting 25-40MB/sec for large file copy from laptop to server.

 

Nice try with the idea, however...



#239
Mieze

Mieze

    Giant Cat

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

With your version (1.1.2):

Reads: getting 7-10MB/sec for large file copy from server to laptop.

Writes: getting 1-7MB/sec for large file copy from laptop to server.

 

With my version:

Reads: getting 60MB/sec for large file copy from server to laptop.

Writes: getting 25-40MB/sec for large file copy from laptop to server.

 

 

Nevertheless thanks for the test run.

 

Mieze



#240
Henry2010

Henry2010

    InsanelyMac Protégé

  • Members
  • Pip
  • 16 posts
oh yeah. thanks for the binary. finally :P





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


2 user(s) are reading this topic

1 members, 1 guests, 0 anonymous users


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