Qualcomm Killer E2205 Drivers For Mac
This project is dedicated to the memory of Carlos Gato Vaca. I spent the last 2 weeks writing a driver for my Killer E2200 NIC because there is no stable working driver for recent Atheros chips under OS X.
Most of the hardware specific code is based on Johannes Berg's alx driver for Linux and the OS X driver framework was taken from my Realtek driver. Key Features of the Driver. Supports Qualcomm Atheros AR816x, AR817x, Killer E220x, Killer E2400 and Killer E2500.
Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). Support for TCP/IPv6 and UDP/IPv6 checksum offload. Makes use of the chip's TCP Segmentation Offload (TSO) feature with IPv4 and IPv6 in order to reduce CPU load while sending large amounts of data.
Fully optimized for Mountain Lion, Mavericks and Yosemite (64bit architecture) but should work with Lion too, provided you build from source with the 10.7 SDK. Wake on LAN support.
VLAN support is implemented but untested as I have no need for it. Supports Energy Efficient Ethernet (EEE). The driver is published under GPLv2. Known Issues.
None. FAQ. Could you add support for AR813x and AR815x? Sorry, no, because I used a different linux driver as the code base than Shailua which doesn't support these chips so that it would be too much work to add support for them. WoL from S5 doesn't work with this driver but under Windows it's working. Is this a driver bug? No it isn't, the driver is working as it should because OS X doesn't support WoL from S5.
You may also install the driver to to /Library/Extensions or use Clover to inject it. In case you are experiencing repeated connection drops with EEE enabled, please select a medium without EEE manually in order to resolve the problem. Installation. Goto /S/L/E and delete ALXEthernet.kext. Recreate the kernel cache. Open System Preferences and delete the corresponding network interface, e. Install the new driver and recreate the kernel cache. I recommend to use Kext Wizard or a similar utility for the installation.
Reboot. Open System Preferences again, select Network and check if the new network interface has been created automatically or create it manually now. Configure the interface.
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 retrieved with 'grep kernel /var/log/system.log' in Terminal. Starting with Sierra use ' log show - predicate 'processID 0' - debug' in order to retrieve kernel logs. Include the log data when asking for support or giving feedback.
I'm an engineer, not a clairvoyant. Don't copy and paste large amounts of log data to your post. Create an archive with the log data and attach it to your post. In case you don't want to make your log data publicly accessible, contact me via PM and I will provide you a mail address to send it directly to me.
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 ALXEthernet.kext from your system because it 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. Changelog. Version 2.2.2 (2017-09-25). Fixes a problem which may cause trouble when trying to change the MAC address. Version 2.1.0d1 (2015-11-29). Supports Energy Efficient Ethernet (EEE). Added support for Killer E2400.
Improved flow control support. Version 1.0.0 (2014-10-05). Official release which is identical to 1.0.0d7. Version 1.0.0d7 (2014-08-18). Fixed Wake on LAN. Version 1.0.0d6 (2014-08-16).
Detects situations when the BIOS left the NIC disabled and outputs an error messages. Small optimizations and improved error handling. Version 1.0.0d5 (2014-08-13).
Removed the mbufpullup call in outputPacket as the NIC seems to accept packets with noncontiguous headers. Version 1.0.0d4 (2014-08-12). Fixed TSO with IPv4 and IPv6. Version 1.0.0d3 (2014-08-10).
Added support for TCP and UDP checksum offload over IPv6. Cleaned up the code and improved error handling. Getting the driver. The source code can be found on GitHub:. There is also a prebuilt binary for 10.8 and above in the download section:. The latest development version can be found here: Mieze Edited September 25, 2017 by Mieze.
Thank you for your support in testing the driver. I can confirm that there is still a problem with TSOv4 which caused KaBuu's performance problem with AFP.
It might sound strange, but it worked when I ran my performance test (I double-checked that TSOv4 was enabled during the test.). After that I shut down the machine, went away and when I booted it some hours later TSO refused to work and I failed to get it working again although I was using the same driver. That's why I disabled it in 1.0.0d2 in order to make the driver work again. I will have to dig deeper into the code in order find a solution for TSO support before it can be reenabled. Besides that I reworked interrupt moderation in the new release and added an option in Info.plist to set the maximum interrupt rate per second. Any value between 2500, which was the previous setting that seemed to limit performance, and 10000 is allowed. Now the default value is 5000 which improved performance significantly while keeping the CPU usage under heavy load down.
Originally Posted by Zer0CoolX Killer is Qualcomm AFAIK Got KIller on my MSI Z87-G45 and its flawless Otherwise Intel is always a safe bet You're right. A little searching shows that Killer is using Qualcomm. Intel is better. Intel is basically the best NICs you can get. They use larger chips which allow for more on-board buffer size etc. This means they don't need massive drivers to do all the heavy lifting (which is extra work on your cpu). Intel just works.
You don't need to mess around all day with drivers and weird issues. Intel as a result of the build design has higher throughput. Realtek is one of the worst mainstream nics because it requires massive drivers to make up for the fact that the chips are small and bare minimum, which allows them to drop manufacturing and production costs.
Qualcomm Killer is likely better than realtek in that aspect, but it doesn't touch intel. The Killer still requires all of this extra software and drivers to do everything.
Another result of this is that OS like Linux/FreeBSD work better with intel because they don't have all the driver issues to deal with like a realtek. Intel has higher throughput and less cpu usage. Intel is typically always the winner when compared to non-intel nics. They don't need all the garbage drivers and utilities. There is a reason servers only use high-end intel nics. Originally Posted by CrazyDiamond You're right. A little searching shows that Killer is using Qualcomm.
Intel is better. Intel is basically the best NICs you can get. They use larger chips which allow for more on-board buffer size etc.
This means they don't need massive drivers to do all the heavy lifting (which is extra work on your cpu). Intel just works. You don't need to mess around all day with drivers and weird issues. Intel as a result of the build design has higher throughput. Realtek is one of the worst mainstream nics because it requires massive drivers to make up for the fact that the chips are small and bare minimum, which allows them to drop manufacturing and production costs. Qualcomm Killer is likely better than realtek in that aspect, but it doesn't touch intel.
The Killer still requires all of this extra software and drivers to do everything. Another result of this is that OS like Linux/FreeBSD work better with intel because they don't have all the driver issues to deal with like a realtek. Intel has higher throughput and less cpu usage.
Intel is typically always the winner when compared to non-intel nics. They don't need all the garbage drivers and utilities. There is a reason servers only use high-end intel nics. I partially agree, specifically you are right that Intel has wider compatibility and is very stable. I also agree that realtek is bottom of the barrel when it comes to LAN. Qualcomm however has extensive knowledge when it comes to various networking and transmission technologies.
The generic Qualcomm/Killer driver only install is 25.9MB The generic Win 10 driver only install for the I219V is 25.6MB for 32bit and 39.27MB for x64 found here. Same for Win 7 Keep in mind that the Qualcomm driver download is for both x32 and x64. It also has all windows versions included (7/8/10). Qualcomm has some additional software to compliment the drivers and I cant comment on them as I dont use them, and bear in mind they are not required. While not the same Killer model the OP mentions, seems pretty unbiased and shows that both Intel and Killer have ups and downs vs each other. Basically the gist is that Intel had better CPU usage while Killer had better latency. I have the Intel I217V on my server and the Killer e2205 on my Desktop.
Qualcomm Killer Wireless
Honestly both just work and neither ever has an issue. They work like a NIC should.out of sight out of mind. @OP, can you list the 2 motherboards you are trying to pick between, its very possible that there are much more important factors that would help decide between them other than which LAN chipset. Originally Posted by Zer0CoolX I partially agree, specifically you are right that Intel has wider compatibility and is very stable. I also agree that realtek is bottom of the barrel when it comes to LAN. Qualcomm however has extensive knowledge when it comes to various networking and transmission technologies. The generic Qualcomm/Killer driver only install is 25.9MB The generic Win 10 driver only install for the I219V is 25.6MB for 32bit and 39.27MB for x64 found here.
Same for Win 7 Keep in mind that the Qualcomm driver download is for both x32 and x64. It also has all windows versions included (7/8/10). Qualcomm has some additional software to compliment the drivers and I cant comment on them as I dont use them, and bear in mind they are not required. While not the same Killer model the OP mentions, seems pretty unbiased and shows that both Intel and Killer have ups and downs vs each other. Basically the gist is that Intel had better CPU usage while Killer had better latency.
I have the Intel I217V on my server and the Killer e2205 on my Desktop. Honestly both just work and neither ever has an issue.
They work like a NIC should.out of sight out of mind. @OP, can you list the 2 motherboards you are trying to pick between, its very possible that there are much more important factors that would help decide between them other than which LAN chipset.
Qualcomm Killer Wireless Driver
Size of driver doesn't directly equal CPU load. Intel based nic WILL load your CPU less than a qualcomm killer. Or any Qualcomm really. Intel can also have additional software to compliment it, just like the Qualcomm killer does. In fact, the main selling point that the Killer keeps chasing is this QoS packet management software they bundle it with, but in reality Intel nics can do the same. Perfect example is GameFirst IV that is provided with ASUS boards for their onboard Intel nics. As you said though, both should be fine for what I'm assuming is a gaming system.
If really the only last question between two boards is the Nic, I would take the Intel in a heart beat. But I too would also guess there are more important decisions to question between the two. Originally Posted by CrazyDiamond Size of driver doesn't directly equal CPU load. Intel based nic WILL load your CPU less than a qualcomm killer. Or any Qualcomm really. Intel can also have additional software to compliment it, just like the Qualcomm killer does.
In fact, the main selling point that the Killer keeps chasing is this QoS packet management software they bundle it with, but in reality Intel nics can do the same. Perfect example is GameFirst IV that is provided with ASUS boards for their onboard Intel nics. As you said though, both should be fine for what I'm assuming is a gaming system. If really the only last question between two boards is the Nic, I would take the Intel in a heart beat. But I too would also guess there are more important decisions to question between the two.
Qualcomm Killer Network
I only mentioned the size of the zips because you mentioned the size of the drivers: 'This means they don't need massive drivers to do all the heavy lifting (which is extra work on your cpu).' Intel doesn't have lower load because of the driver size (evidenced by Qualcomms drivers being smaller). While the Qualcomm driver has a heavier load on the CPU the result is lower latencies. Maybe on a budget Celeron/Atom CPU the CPU load is a concern, but on most modern CPU's this has be be negligible.
The load issue could be counter acted by getting a better CPU (not that I feel its drastic enough to justify) but there is no change outside of the LAN chip that will make latency better. I do however agree with you that in a business setting the higher end Intel dedicated NIC's are in a league of their own. I think at the consumer level Intel and Qualcomm are pretty even.
Personally for me many other things between 2 boards would matter more than the NIC that are also not major things but to me matter more like brand, warranty, capacitors, inputs/outputs, arrangement of the board, return policy, even appearance. In any case our differing views will hopefully give the OP food for thought.