crashmaster4999 Posted August 16, 2015 Share Posted August 16, 2015 Quick question - has anyone had issues copying large (200 gig+) files using AFP since the 10.10.5 update? I've been trying to copy files to my server but after only 400-600 megs the ethernet link gets dropped and then reconnects after 4-5 seconds. After watching this happen a few times, I unmounted the server & reconnected using smb. 188.84 gigs into the transfer and no bad effects yet. Thanks for any input! crash Edit: 214.75GB file just completed using smb - and not a single error... Link to comment Share on other sites More sharing options...
Mieze Posted August 16, 2015 Author Share Posted August 16, 2015 @chrashmaster4999: Please send me your complete kernel logs showing this issue. By the way, the fact that SMB works while AFP fails doesn't suggest a driver problem. Mieze Link to comment Share on other sites More sharing options...
crashmaster4999 Posted August 16, 2015 Share Posted August 16, 2015 No problem - do you have an email address I can send it to? Link to comment Share on other sites More sharing options...
AdamiPL Posted August 23, 2015 Share Posted August 23, 2015 Why not supported 82567LM-2 ? dev id: 0x10cc Link to comment Share on other sites More sharing options...
Andycore Posted August 23, 2015 Share Posted August 23, 2015 Hey Mieze, excellent work on this! Glad to see an extension with improved performance over the sometimes shaky E1000e kext/s in existence. Unfortunately haven't had much luck getting it to work -- booting gets to the point where the GUI should appear, and then my system reboots without error or warning. My board has both I211AT and I217V based controllers on board, so the first boot with your kext didn't seem to initialise any hardware at all (there is a boot log of the first boot here, if you would like to see it). I have since disabled the 211 controller (it isn't used anyway), along with network boot options and WoL options from within my UEFI settings... Now I can see that the 217 is being detected correctly, however the issue remains. Just as soon as the boot process should be presenting the GUI, my system reboots. The most recent boot log is posted for you here, though to my inexperienced eye it doesn't seem like there is any issue with the driver loading or anything that would seem to show a problem resulting in a reboot. Your knowledge is greater than mine, so I thought it best to post to ask. I'm running 10.10.5, and while I use Clover as a boot loader I have your kext in S/L/E manually (as this is just easier for me). I also don't have a DSDT. It's entirely possible that this is a local conflict with some other kext or application, and I do plan on doing a complete rebuild of my workstation when El Capitan launches and is stable enough for hackintoshing... It would just be great to get some improved networking happening in the mean time. FWIW, the I217V on my mainboard does work with an E1000e kext with the version number 3.2.4. Thanks a lot for your hard work! Link to comment Share on other sites More sharing options...
Mieze Posted August 23, 2015 Author Share Posted August 23, 2015 @Andycore: Which board are you using? Why not supported 82567LM-2 ? dev id: 0x10cc I haven't removed the code supporting these old chips, only the device ID in the driver's Info.plist is missing. You might want to add your device ID and try if it works. Mieze Link to comment Share on other sites More sharing options...
Andycore Posted August 24, 2015 Share Posted August 24, 2015 @Andycore: Which board are you using? Sorry! Forgot to mention. It's an ASRock Z87 Fatal1ty Professional. Link to comment Share on other sites More sharing options...
Mieze Posted August 24, 2015 Author Share Posted August 24, 2015 @Anycore: Provided your BIOS settings are correct and you don't have ncpi=0x2000 or npci=0x3000 among your kernel flags, there shouldn't be any problem because the driver is known to work stable in this configuration. If the issue persists, please search somewhere else. Mieze Link to comment Share on other sites More sharing options...
Mieze Posted August 24, 2015 Author Share Posted August 24, 2015 I analyzed the issue RehabMan and others reported and was able to reproduce it on my test machine with an I218. According to my findings and the log data chrashmaster4999 sent me, the problem can be narrowed down to an interference of the way AFP organizes network buffers since 10.10.4 and a peculiarity of the chip's DMA engine. After 25 hours of hard work it looks like I found a workaround which is working on my machine. I have successfully transferred 120GB of data over AFP without experiencing a single deadlock so that I'm quite confident that it will work on other machines too. Attached you'll find a prebuilt binary of the test version I've been using. Please test it thoroughly and report back if it works as expected. Good luck! Mieze IntelMausiEthernet-2.0.2d3.zip 2 Link to comment Share on other sites More sharing options...
RehabMan Posted August 24, 2015 Share Posted August 24, 2015 I analyzed the issue RehabMan and others reported and was able to reproduce it on my test machine with an I218. According to my findings and the log data chrashmaster4999 sent me, the problem can be narrowed down to an interference of the way AFP organizes network buffers since 10.10.4 and a peculiarity of the chip's DMA engine. After 25 hours of hard work it looks like I found a workaround which is working on my machine. I have successfully transferred 120GB of data over AFP without experiencing a single deadlock so that I'm quite confident that it will work on other machines too. Attached you'll find a prebuilt binary of the test version I've been using. Please test it thoroughly and report back if it works as expected. Good luck! Mieze Sorry I haven't had time to test lately (was away from my network for a while, now need to catch up). Just a note though... my issue was with SMB, not AFP. Same fix you think? Link to comment Share on other sites More sharing options...
Mieze Posted August 24, 2015 Author Share Posted August 24, 2015 Sorry I haven't had time to test lately (was away from my network for a while, now need to catch up). Just a note though... my issue was with SMB, not AFP. Same fix you think? Probably yes as both, AFP and SMB, are based on TCP. The problem is that network buffers aren't physically contiguous and that the DMA engine seems to hang sometimes when a packet consists of multiple small data segments, in particular when it is a TSO operation. The first segment always contains the L2 - L4 headers which results in a size of 66 bytes. In the next segment there used to be the AFP/SMB header followed by the payload, but starting with 10.10.4 they seem to have separated the AFP/SMB header from the payload so that the second segment is small too (usually less than 100 bytes) resulting in two consecutive small segments. I found out that there is a correlation between the selected descriptor handling policy and the probability of a deadlock and tried to find the most stable configuration empirically. Mieze Link to comment Share on other sites More sharing options...
crashmaster4999 Posted August 24, 2015 Share Posted August 24, 2015 Mieze: I'll give it a try tonight and let you know how it goes. Thanks for all you do for the community! crash 1 Link to comment Share on other sites More sharing options...
Andycore Posted August 25, 2015 Share Posted August 25, 2015 @Anycore: Provided your BIOS settings are correct and you don't have ncpi=0x2000 or npci=0x3000 among your kernel flags, there shouldn't be any problem because the driver is known to work stable in this configuration. If the issue persists, please search somewhere else. Mieze I'll have to continue troubleshooting on my end, though things don't look good. It is quite probably something I did initially setting up the machine, there have been several hardware changes since I initially installed OS X. Thank you for taking the time to check out the logs and offer your advice. I'll try again when I do a fresh install. Link to comment Share on other sites More sharing options...
BusError Posted August 26, 2015 Share Posted August 26, 2015 First, thanks for this driver, picked a cheap 82579V on ebay and both ports are recognized. I do have a problem tho; I use one port as a 'jumbonet' -- I use a cat6 to a port in my linux machine, with jumbo frames, and traditionally use NFS over that. The problem I'm having is that the link is not detected, most of the time... No amount of plugging/replugging works, you need to cold-reboot for the link to work (sometime). I've validated that it's not the other port of course, it definitely looks like it's this particular port combo. When the link it there, it otherwise works beautifully.. I use v2.0.0d2 Link to comment Share on other sites More sharing options...
Mieze Posted August 26, 2015 Author Share Posted August 26, 2015 First, thanks for this driver, picked a cheap 82579V on ebay and both ports are recognized. I do have a problem tho; I use one port as a 'jumbonet' -- I use a cat6 to a port in my linux machine, with jumbo frames, and traditionally use NFS over that. The problem I'm having is that the link is not detected, most of the time... No amount of plugging/replugging works, you need to cold-reboot for the link to work (sometime). I've validated that it's not the other port of course, it definitely looks like it's this particular port combo. When the link it there, it otherwise works beautifully.. I use v2.0.0d2 There is something wrong with your problem description. First, the 82579V is a gigabit ethernet PHY which was designed to be combined with the 6 and 7 series chipset's integrated MAC as an onboard LAN solution. It is unsuitable for add-on cards. I don't know which chip you are using on your card, but it's definitely not a 82579V. Second, the driver doesn't support jumbo frames because there is almost no performance advantage in real world scenarios and I see no good reason to implement it. Mieze Link to comment Share on other sites More sharing options...
spaham Posted August 27, 2015 Share Posted August 27, 2015 Hi ! First of all thanks for your great extension !! I've installed the latest V2.0 in order to correct a problem I have with AppleIntelE1000e which is that my bandwidth isn't fully available. Unfortunately I see the exact same shortcommings. I have a GA-X79-UD7 with i7-3960X running at 4.5Ghz (OC'd with 1.25 strap). Running 10.10.5 with a full Clover install (latest version). I tried removing the npci=0x2000 or npci=0x3000 flags, but my hack won't boot... I theorically have a gigabit internet connexion, which I have tested and which normally gives me > 100 MBytes/s downloads. What happens here is that when I do test downloads, I only get around ~10MB/s. what made me suspect it could be a driver issue is that I tried every version of AppleIntelE1000e.kext I could find, and simply doing a kextunload/load of a different version gives me different download speeds. I managed to get up to 80MB/s with version 2.4.14 but it hangs after a few seconds/minutes (I then need to do an ifconfig down/up to get it back). here is a sample I just did with my hackintosh and with an old macbook on the same LAN : me: curl -o /dev/null http://test-debit.free.fr/image.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 647M 100 647M 0 0 9361k 0 0:01:10 0:01:10 --:--:-- 9616k macbook: curl -o /dev/null http://test-debit.free.fr/image.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 647M 100 647M 0 0 101M 0 0:00:06 0:00:06 --:--:-- 111M can you feel the pain ? The thing is, though, that I can get up to ~50-60 MB/s with aggregated sockets, ie when I download from usenet with many connexions. But I get about half what I used to get, ie 50 instead of 100MB/s. I installed your extension as you suggested (removed the E1000e, cache, reboot, new cache, config etc). My system config (net.inet.xxx) shouldn't be the culprit, since I get very different bandwidth usage just by loading a different kext. I'm at loss, and I don't know what to do. thanks for any suggestions you could offer ! Link to comment Share on other sites More sharing options...
spaham Posted August 27, 2015 Share Posted August 27, 2015 here is the log extract, tell me if you need anything else. I'm a developer so I can try things, compile tests etc. dmesg | grep Maus Ethernet [IntelMausi]: TCP/IPv4 segmentation offload enabled. Ethernet [IntelMausi]: TCP/IPv6 segmentation offload enabled. Ethernet [IntelMausi]: TCP/IPv6 checksum offload enabled. Ethernet [IntelMausi]: Version 2.0.0 using max interrupt rate 7000. Ethernet [IntelMausi]: intrThrValue=557 Ethernet [IntelMausi]: PCI power management capabilities: 0xc822. Ethernet [IntelMausi]: PME# from D3 (cold/hot) supported. Ethernet [IntelMausi]: 82579V (Rev. 5) at 0xffffff81e99f5000, 50:e5:49:e0:eb:c1 Ethernet [IntelMausi]: MSI interrupt index: 0 Ethernet [IntelMausi]: kIOEthernetWakeOnMagicPacket added to filters. Ethernet [IntelMausi]: Already in power state 1. Ethernet [IntelMausi]: No medium selected. Falling back to autonegotiation. Ethernet [IntelMausi]: checkLinkStatus() returned 1. Ethernet [IntelMausi]: EEE mode = 0x0000, adv=0x0006, lpa=0x0000 Ethernet [IntelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control Ethernet [IntelMausi]: CTRL=0x58100240 Ethernet [IntelMausi]: CTRL_EXT=0x195a1000 Ethernet [IntelMausi]: STATUS=0x40080083 Ethernet [IntelMausi]: GCR=0x00000000 Ethernet [IntelMausi]: GCR2=0x00000000 Ethernet [IntelMausi]: RCTL=0x04008002 Ethernet [IntelMausi]: PSRCTL=0x00040402 Ethernet [IntelMausi]: FCRTL=0x80005048 Ethernet [IntelMausi]: FCRTH=0x00005c20 Ethernet [IntelMausi]: RDLEN(0)=0x00002000 Ethernet [IntelMausi]: RDTR=0x00000000 Ethernet [IntelMausi]: RADV=0x00000000 Ethernet [IntelMausi]: RXCSUM=0x00002300 Ethernet [IntelMausi]: RFCTL=0x000380c0 Ethernet [IntelMausi]: RXDCTL(0)=0x00010000 Ethernet [IntelMausi]: RAL(0)=0xe049e550 Ethernet [IntelMausi]: RAH(0)=0x8000c1eb Ethernet [IntelMausi]: MRQC=0x00370001 Ethernet [IntelMausi]: TARC(0)=0x0d800403 Ethernet [IntelMausi]: TCTL=0x3103f0fa Ethernet [IntelMausi]: TXDCTL(0)=0x0141001f Ethernet [IntelMausi]: TADV=0x0000001c Ethernet [IntelMausi]: TIDV=0x0000001c Ethernet [IntelMausi]: MANC=0x00000000 Ethernet [IntelMausi]: MANC2H=0x00000000 clover boot log : 7:226 0:000 LAN 0, Vendor=8086, MMIO=FB600000 23:068 0:000 LAN Controller [8086:1503] :: PcieRoot(0x0)\Pci(0x19,0x0) ioreg : | | +-o GBE@19 <class IOPCIDevice, id 0x10000022c, registered, matched, active, busy 0 (653 ms), retain 11> | | | +-o IntelMausi <class IntelMausi, id 0x100000509, !registered, !matched, active, busy 0 (0 ms), retain 7> | | | +-o en0 <class IOEthernetInterface, id 0x100000512, registered, matched, active, busy 0 (0 ms), retain 11> | | | +-o IONetworkStack <class IONetworkStack, id 0x100000305, registered, matched, active, busy 0 (0 ms), retain 8> | | | +-o IONetworkStackUserClient <class IONetworkStackUserClient, id 0x100000454, !registered, !matched, active, busy 0, retain 5> -------------- tail -F /var/log/system.log |grep Mausi # little after launching a curl speed test : Aug 27 18:08:36 macpro kernel[0]: Ethernet [IntelMausi]: replaceOrCopyPacket() failed. # nntp download with 40 connexions : Aug 27 18:10:28 macpro kernel[0]: Ethernet [IntelMausi]: replaceOrCopyPacket() failed. edit after doing some copy tests from and smb share : Aug 27 18:30:44 macpro kernel[0]: Ethernet [IntelMausi]: checkLinkStatus() returned 0. Aug 27 18:30:44 macpro kernel[0]: Ethernet [IntelMausi]: Link down on en0 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: checkLinkStatus() returned 1. Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: EEE mode = 0x0000, adv=0x0006, lpa=0x0000 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: CTRL=0x58100240 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: CTRL_EXT=0x195a1000 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: STATUS=0x40080083 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: GCR=0x00000000 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: GCR2=0x00000000 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RCTL=0x04008002 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: PSRCTL=0x00040402 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: FCRTL=0x80005048 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: FCRTH=0x00005c20 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RDLEN(0)=0x00002000 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RDTR=0x00000000 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RADV=0x00000000 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RXCSUM=0x00002300 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RFCTL=0x000380c0 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RXDCTL(0)=0x00010000 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RAL(0)=0xe049e550 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RAH(0)=0x8000c1eb Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: MRQC=0x00370001 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TARC(0)=0x0d800403 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TCTL=0x3103f0fa Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TXDCTL(0)=0x0141001f Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TADV=0x0000001c Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TIDV=0x0000001c Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: MANC=0x00000000 Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: MANC2H=0x00000000 I attached my ioreg from IORegistryExplorer. Mac mini.ioreg.zip Link to comment Share on other sites More sharing options...
Mieze Posted August 27, 2015 Author Share Posted August 27, 2015 @spaham: You are on the wrong track. The drivers are working fine. As you are a developer you should take a closer look at the internals of TCP and the parameters the kernel offers in order to optimize it. Mieze Link to comment Share on other sites More sharing options...
spaham Posted August 27, 2015 Share Posted August 27, 2015 @spaham: You are on the wrong track. The drivers are working fine. As you are a developer you should take a closer look at the internals of TCP and the parameters the kernel offers in order to optimize it. Mieze but if it's not the driver, can you tell me why doing the following has this effect : - *without restarting* - do a download test (even many times) - average = 10M - kextunload /.../E1000e.kext vx - kextload /.../E1000e.kext vy - download test - average 80M (but hangs very quickly) - (...) - average 10M - (...) I have tried many kernel parameters, and I'm quite savvy with them (I wrote BitsOnWheels, if you've heard of it, a native cocoa bittorrent client...) and they do not have any real impact on the limitation... Link to comment Share on other sites More sharing options...
Mieze Posted August 27, 2015 Author Share Posted August 27, 2015 but if it's not the driver, can you tell me why doing the following has this effect : - *without restarting* - do a download test (even many times) - average = 10M - kextunload /.../E1000e.kext vx - kextload /.../E1000e.kext vy - download test - average 80M (but hangs very quickly) - (...) - average 10M - (...) I have tried many kernel parameters, and I'm quite savvy with them (I wrote BitsOnWheels, if you've heard of it, a native cocoa bittorrent client...) and they do not have any real impact on the limitation... Counterquestion: why and how do you relate this behavior to the driver? Why do you assume that it's behaving completely different each time you load it as this assumption makes no sense? When you are talking about your internet connection the influence of the driver on the timing is insignificant. In the other hand parameters as the buffer size, delayed ack, etc. have a great influence on throughput. Besides that you shouldn't forget the congestion avoidance mechanism. Mieze Link to comment Share on other sites More sharing options...
spaham Posted August 27, 2015 Share Posted August 27, 2015 Counterquestion: why and how do you relate this behavior to the driver? Why do you assume that it's behaving completely different each time you load it as this assumption makes no sense? When you are talking about your internet connection the influence of the driver on the timing is insignificant. sh-3.2# date;curl -o /dev/null http://test-debit.free.fr/image.iso Jeu 27 aoû 2015 23:34:18 CEST % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 10 647M 10 66.5M 0 0 9892k 0 0:01:06 0:00:06 0:01:00 9611k^C sh-3.2# kextunload /System/Library/Extensions/IntelMausiEthernet.kext/ sh-3.2# kextload /extras/nico\ kext/AppleIntelE1000e-v2.4.14/AppleIntelE1000e.kext sh-3.2# date;curl -o /dev/null http://test-debit.free.fr/image.iso Jeu 27 aoû 2015 23:35:58 CEST % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 647M 100 647M 0 0 96.1M 0 0:00:06 0:00:06 --:--:-- 96.4M sh-3.2# kextunload /extras/nico\ kext/AppleIntelE1000e-v2.4.14/AppleIntelE1000e.kext sh-3.2# kextload /System/Library/Extensions/IntelMausiEthernet.kext/ sh-3.2# date;curl -o /dev/null http://test-debit.free.fr/image.iso Jeu 27 aoû 2015 23:36:48 CEST % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 18 647M 18 122M 0 0 8824k 0 0:01:15 0:00:14 0:01:01 9053k^C sh-3.2# edit : copy/paste problems Link to comment Share on other sites More sharing options...
Mieze Posted August 27, 2015 Author Share Posted August 27, 2015 So far, so good, so what? Still no indication for a driver problem. Your test doesn't prove anything because there are too many parameters you don't have under control, in particular the packet roundtrip time and the influence of the packet scheduler. Looks more like the result of the congestion avoidance mechanism which reacts very sensitive on the roundtrip time and it's variation or QFQ which is one of the reasons why IntelMausiEthernet is stable. Mieze Link to comment Share on other sites More sharing options...
spaham Posted August 27, 2015 Share Posted August 27, 2015 So far, so good, so what? Still no indication for a driver problem. Your test doesn't prove anything because there are too many parameters you don't have under control, in particular the packet roundtrip time and the influence of the packet scheduler. Looks more like the result of the congestion avoidance mechanism which reacts very sensitive on the roundtrip time and it's variation or QFQ which is one of the reasons why IntelMausiEthernet is stable. Mieze Hummm ok, let's say you're right, what kind of kernel parameters would you play with then ? I'd rather fix my problem than be right (thanks for your time btw !! I hope I don't sound too cranky) Link to comment Share on other sites More sharing options...
Mieze Posted August 27, 2015 Author Share Posted August 27, 2015 Hummm ok, let's say you're right, what kind of kernel parameters would you play with then ? I'd rather fix my problem than be right (thanks for your time btw !! I hope I don't sound too cranky) Frankly I'm not sure as there are things you can't control. The packet roundtrip time and it's variation are the factors which are used in order to detect congestion and it might easily produce false positives as both values are much higher for a remote connection which results in a dramatic slowdown. Basically it's a similar situation as with WIFI according to the IEEE802.11ac standard where the high roundtrip time is also a limiting factor and you might use the strategies used to optimize performance in these scenarios as a starting point. The packet scheduler QFQ, which is a part of Apple's new driver interface, is something that is harder to influence but it is necessary in order to maintain stability under overload because it throttles the output rate when packets start to become bottled up in the output queue and prevents the network stack from dying due to the exhaustion of packet buffer memory. Comparison between versions 2.x.x of my drivers, which use QFQ, and versions 1.x.x, which use the traditional driver interface without packet scheduler, show that it might produce a significant performance hit in certain situations but it's necessary for a stable operation in some configurations, for example with virtualization software like VMware. Mieze 1 Link to comment Share on other sites More sharing options...
spaham Posted August 28, 2015 Share Posted August 28, 2015 Frankly I'm not sure as there are things you can't control. Thanks for you help ! I found a "killer" solution : I bought a TP-LINK TG-3468 that worked Out Of the Box. (Well almost, since I had the AppleRTL8169Ethernet.kext already installed.) I disabled my internal ethernet to make it easy for my link to be on en0 systematically. And now I'm back with my >100MB/s data rates ! \o/ thanks for your time anyways (just for refs, I have a gigabyte GA-X79-UD7 rev1 running Yosemite 10.10.5). Link to comment Share on other sites More sharing options...
Recommended Posts