Development to the customer: Now is finally Windows 8, Windows 8.1 (still) slightly unstable

This is the second product for USB3.0 SuperSpeed ​​to GBit LAN Ethernet that I ordered and tested and I was again very disappointed. What I describe here the example of the anchor Uspeed adapter meets 1: 1 on the Digitus DN-3023 adapter to which was more available and was therefore ordered and tested by me first with exactly the same negative result. After two identical devices reichts me and I feel obliged more buyers from these products to warn.

Here, first the details of which should include here on Amazon in their own interest (prevention of returns) in her, with all due respect, inadequate descriptions the various retailers so you BEFORE you buy know which scrap as coming straight to the house: The two products apparently based on the reference implementation of ASIX and use the new ASIX 88179 controller chip (see Google search under keyword "ASIX ax88179"). On the hardware side, there are real and genuine USB3.0 unchecked 1000 Mbit / s Ethernet with no additional power supply. The controllers support jumbo frames (only) up to 4088 bytes, which just about ok but by no means spectacular or contemporary in terms of performance possible utilization of the theoretical bandwidth. The MAC vendor identifier (front 3 groups of the MAC address) of the anchor point to Asustek Uspeed know otherwise. Apparently for good reason shy away here to give this controller chip under a well-known brand in the market. Similar adapters based on the predecessor chips Asix 88178 are included with the notebook without LAN, this adapter work perfectly, but they are USB2.0 and 100Mbit / s.

Drivers are both Digitus and the anchor Uspeed on an accompanying CD-ROM and can be under Win7 / 8 install problems. In Windows 8, the anchor Uspeed (not the Digitus EDIT: Both use the same driver, so the driver at anchor test was already available) automatically detected and installed as ASIX-based device. Digitus offers on its side on all drivers to download. Anchor it tries offered RAR file can not unzip without error because apparently a CRC error is detected. In addition, clear scolding at this point to anchor, unnecessarily use a proprietary compression format, all other manufacturers use zip, 7zip or gzip. If you googled under the above keyword, you will also find there the original drivers for ASIX controller chip.

FAULT / PROBLEM: It comes in practice to interruptions in accessing Windows shares, when copying files or simple Internet browsing. For me, it failed even repeatedly been in the construction of network connections. The device registers without any problem on the DHCP server (router) and correctly identified the possible network speed. Finding another computer is already critical access when trying to mount shares directly fails in 99% of cases and if not, to listen at the latest when attempting directory contents.

Test environment:

Asus Zenbook UX32VD (Win8) with USB3.0 SuperSpeed ​​interface, and the here criticized adapter anchor Uspeed (or same results via Digitus DN-3023)
Cat6 cable, length 7.5 meters to the Switch
HP ProCurve Switch 1810 Managed
Cat6 cable, length 2 meters up to standard PC Tower
Standard PC Tower (Win7) with Intel Pro / 1000 Gigabit Ethernet controller on PCI Express 1x

The network environment existed previously and there were between various LAN controllers from Realtek, Intel, Broadcom, Atheros, etc. on various devices over the years never had problems, even running Jumbo frames up to an MTU of 7K and ran here always impeccable.

MEASUREMENT:

To get the strange behavior of the product on the track and release exclude legal problems, I have the free benchmark "NETIO" used to check the sending and receiving packets over a TCP connection. Actually, the program is intended for measuring the speed depending on various package sizes. Following anytime reproducible readings show where the shoe pinches:

Standard PC (Intel LAN) as the server, Zenbook (anchor Uspeed) as a client (measurement documented the client):

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1K bytes: 106407 Kbytes / s Tx, 40933 KByte / s Rx.
Packet size 2k bytes: 109461 Kbytes / s Tx, 41662 KByte / s Rx.
Packet size 4k bytes: 109975 Kbytes / s Tx, 43528 KByte / s Rx.
Packet size 8k bytes: 110122 Kbytes / s Tx, 43406 KByte / s Rx.
Packet size 16k bytes: 110345 Kbytes / s Tx, 43289 KByte / s Rx.
Packet size 32k bytes: 111189 Kbytes / s Tx, 27579 KByte / s Rx.
Done.

-> No jumbo packets

C: \ Program Files (x86) \ NETIO \ bin> Win32 i386.exe -t 192.168.2.39

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1K bytes: 112066 Kbytes / s Tx, 45414 KByte / s Rx.
Packet size 2k bytes: 113094 Kbytes / s Tx, 46468 KByte / s Rx.
Packet size 4k bytes: 113435 Kbytes / s Tx, 47115 KByte / s Rx.
Packet size 8k bytes: 114129 Kbytes / s Tx, 47335 KByte / s Rx.
Packet size 16k bytes: 114871 Kbytes / s Tx, 47607 KByte / s Rx.
Packet size 32k bytes: 115777 Kbytes / s Tx,

-> Jumbo packets 4088 bytes on both LAN adapters

Countermeasure
Zenbook (anchor Uspeed) as a server, standard PC (Intel LAN) as a client (measurement documented the client):

C: \ Program Files (x86) \ NETIO \ bin> Win32 i386.exe -t 192.168.2.35

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1K bytes: 403 KByte / s Tx, 89759 KByte / s Rx.
Packet size 2k bytes: 580 KByte / s Tx, 89894 KByte / s Rx.
Packet size 4k bytes: 1710 KByte / s Tx, recv (): error code 10060
216 bytes / s Rx.
Packet size 8k bytes: send (): error code 10054
send (): error code 10054
Done.

-> No jumbo packets (probably accidentally particularly bad result)

C: \ Program Files (x86) \ NETIO \ bin> Win32 i386.exe -t 192.168.2.35

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1K bytes: 45193 KB / s Tx, 111981 Kbytes / s Rx.
Packet size 2k bytes: 46575 KB / s Tx, 113528 Kbytes / s Rx.
Packet size 4k bytes: 46817 KB / s Tx, 113102 Kbytes / s Rx.
Packet size 8k bytes: 46967 KB / s Tx, 113 897 KByte / s Rx.
Packet size 16k bytes: 47707 KB / s Tx, 114642 Kbytes / s Rx.
Packet size 32k bytes: 6283 KByte / s Tx, recv (): error code 10060
1730 bytes / s Rx.
send (): error code 10054
Done.

-> Jumbo packets 4088 bytes on both LAN adapters

EVALUATION:

- There will be a glaring discrepancy between sent and received from the Anchor Uspeed packages. Sending is more than twice as fast as the receiving or vice versa at the other measurement, there are obviously problems with buffering and processing of incoming data at anchor Uspeed.
- It is independent of the use of jumbo frames at high load on the anchor-USB adapter to errors in the packet reception.
- Is measured by the Intel card (Intel as a client), transmission errors are documented and there is a crash. Conversely seems the ASIX controller / driver no error checking to offer and the connection is nirvana, data come in two variants from a packet size of 32K on only disturbed massively or not at all. This is the cause that can be transferred to all ASIX 88179-based products obviously.
- Declaration on the error codes provides Microsoft here: msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx

CONCLUSION:

The entire product is obviously in short supply. If you have similar problems, send this controller necessarily back! If other buyers indicate this product or even the identical product from Digitus be error-free, this was in all probability used only in the 100 Mbit / s mode, because a component in the call chain this required (eg Cat5 cables, routers with slow switch etc.) or at least in the background a WLAN still ensured a flawless connection. Judging by the other customer opinions when Digitus, do not occur at reduced pace this error, but with increasing load. For 100 Mbit / s the Ultrabooks USB2 adapter are however at based on previous chips ASIX 88178. In my case, with a plastic cap from ASUS and this slow adapter also works exactly as it should. If that is enough, but does not have to invest here!

Please click on "useful review" if you have the same problem, thank you!

EPILOGUE:

Anchor applying a particularly good customer, I have not taken advantage of because of the experience with the Digitus adapter and the same problem scenario. Ultimately you will be here may also healing spells no defective series. It is also explicitly advertised aim is to publish reviews about the young brand anchor on Amazon, I have hereby done hopefully satisfactorily (evidence-based) fashion.

################################################## ############################
########################### Changed on 19.01.2013 ################## #########
################################################## ############################

As the story continued ...

2 days following this detailed review, I was contacted by the customer the manufacturer, who also commented here (laptop Mate). One finds it difficult to understand my experiences and regrets that too all very much and gave me the free delivery of another identical Digitus DN-3023-adapter. I agree today is the adapter in the mail and I test also in this same manner.
EDIT: Have swapped the support - Laptop Mate is part of the anchor product, the Digitus adapter was replaced by the seller Olano GmbH.

TESTS & CONSTRUCTION:

1st attempt: Results still, connection problems after successful DHCP exchange. Cable used to be a very neuwertiges Cat7 cable with 7.5 m length (Cat6 connector standard + cable suitability to 1200MHz - for Gigabit already reaches 250 MHz). The cable is impeccable and works in combination with any other devices without any performance penalty or interference.

2. attempt same cable quality, newly out of the package, 2 meters long. Success! The following measurements are possible:

# Jumbo packet disabled

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1K bytes: 102508 Kbytes / s Tx, 40783 KByte / s Rx.
Packet size 2k bytes: 92883 KB / s Tx, 42062 KByte / s Rx.
Packet size 4k bytes: 104618 Kbytes / s Tx, 43313 KByte / s Rx.
Packet size 8k bytes: 104849 Kbytes / s Tx, 43273 KByte / s Rx.
Packet size 16k bytes: 104004 Kbytes / s Tx, 43094 KByte / s Rx.
Packet size 32k bytes: 104606 Kbytes / s Tx, 42962 KByte / s Rx.
Done.

# Jumbo package enabled @ 4088 bytes

C: \ Program Files (x86) \ NETIO \ bin> Win32 i386.exe -t 192.168.2.39

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1K bytes: 106729 Kbytes / s Tx, 45665 KByte / s Rx.
Packet size 2k bytes: 105983 Kbytes / s Tx, 46579 KByte / s Rx.
Packet size 4k bytes: 107882 Kbytes / s Tx, 46935 KByte / s Rx.
Packet size 8k bytes: 107584 Kbytes / s Tx, 47058 KByte / s Rx.
Packet size 16k bytes: 108830 Kbytes / s Tx, 47331 KByte / s Rx.
Packet size 32k bytes: 109628 Kbytes / s Tx, 47097 KByte / s Rx.
Done.

OK, but please do not rejoice too soon, rather go to the bottom of whether it is also wirklch!

3. experimental / cross-checking: used another cable, a relatively abgenudeltes Cat5e cable, 5 meters long, measured values ​​are approximately 1 MB under the 2nd experiment, otherwise faultlessly And störfrei.
Side note: If the locking lever on the cable is already terminated, this slips from the Digitus adapter, because obviously the socket is too short or the spring is too strong. For other network jacks that is not so, as long as you just does not pull the cord.

4. experimental / cross-check: I had the alternative cable (that is, since test 2) without the special importance be attached to another port connected to the switch, strictly speaking port 7. It turns out that it is the port on the switch and the cable is not relevant. Even the first cable is working with me on the 7th Port, while the switch for all ports is configured exactly the same. All cable work only in this combination! For more free ports on the switch repeatedly show the same result, except for one on the controller manually to 100 Mbit / s down, which may not be relevant and the point of it.

(AUS) SCORING:

The Digitus DN-3023 continues to work on very peculiar way. It is unacceptable that a network adapter is so sensitive. I can explain the "magic" 7. Port just that here may happen to be a particularly good contact is made and the highly sensitive network adapter therefore permitting. I'll keep the adapter Digitus now, but I am afraid that this will be fully accrued me next relocation to another network already.
Striking remains that the controller shows excellent performance when sending data and here easily to the transmission limit of theoretical 125 MB / s reaches as while receiving data with only about 43% capacity takes place (in relation to the sending). Here's maybe a data buffer for cost reasons too small ASIX fall? Or is simply the input sensitivity is too low and the controller is only "murky soup" to?
Jumbo Frames influence both values ​​only slightly positive, which should be largely attributed to the potent main processors of the two test computers that do not buckle also in many small packages especially - that can at a connection between Digitus and a small embedded server / NAS fail already clearly negative without the Jumbos. The measured values ​​from the benchmark I could also by copying large files on Windows Test 1: 1 verification (both computers use an SSD, so the hard drive is not limiting criterion is here).

The manufacturer identification of the MAC address is the way, unlike the anchor Uspeed to recognize this Board Partner: [...]
CONCLUSION:

It is (in some individual cases, with some devices of the series) possible to fabricate gigabit operation. However, this is about as reckless as fuel-saving cars, which only achieve their advertised record consumption of this product, if you at the flatland, constant at balanced 20 ° C temperature with disconnected board electronics (air conditioning, radio, light) with a tailwind in the highest gear 70 km / h cruise control regulated straight drives. With a usage within the meaning of (legitimate) expectation of customers Theoretikum has absolutely nothing to do. The Digitus DN-3023 based on the ASIX 88179 remains a cheap product at the lower limit of feasibility, and I think the title "Development of the customers!" is right, even if I have now found a way for me.

PS: If there may be someone who lack sufficient USB3 interfaces, interested. Under mentioned optimum conditions under which the adapter Digitus is läuffähig, the interposition of a Logilink USB3 4-stroke did not affect the performance, the measurement deviations are in the area of ​​measurement inaccuracy ...

# Jumbo package enabled @ 4088 bytes of USB 3.0 Hub

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1K bytes: 106 158 KByte / s Tx, 45648 KByte / s Rx.
Packet size 2k bytes: 106115 Kbytes / s Tx, 46398 KByte / s Rx.
Packet size 4k bytes: 106187 Kbytes / s Tx, 46818 KByte / s Rx.
Packet size 8k bytes: 107356 Kbytes / s Tx, 47232 KByte / s Rx.
Packet size 16k bytes: 108167 Kbytes / s Tx, 46605 KByte / s Rx.
Packet size 32k bytes: 110548 Kbytes / s Tx, 47173 KByte / s Rx.
Done.

################################################## ############################
########################### Changed on 21/01/2013 ################## #########
################################################## ############################

Another addition: Today the replacement of anchor Uspeed adapter has arrived. The adapter is exactly the same behavior as the second delivery when Digitus. I could recruit another test calculator to still to eroieren possible error sources that have nothing to do with the reviewed here USB Ethernet adapters.

New in the test round is a USB3-enabled standard PC (hereinafter referred to as standard PC2) with Asus motherboard and Intel Gbit LAN and USB3 AMD chipset-based, both onboard.

The following measured values ​​arise between standard PC2 @ onboard Intel LAN and Zenbook @ Digitus DN-3023:

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1K bytes: 109 276 KByte / s Tx, 112101 Kbytes / s Rx.
Packet size 2k bytes: 108328 Kbytes / s Tx, 112 364 KByte / s Rx.
Packet size 4k bytes: 107856 Kbytes / s Tx, 112478 Kbytes / s Rx.
Packet size 8k bytes: 107640 Kbytes / s Tx, 113343 Kbytes / s Rx.
Packet size 16k bytes: 110220 Kbytes / s Tx, 114 249 KByte / s Rx.
Packet size 32k bytes: 105208 Kbytes / s Tx, 102769 Kbytes / s Rx.
Done.

And now crazy - following measurements between standard PC2 @ anchor Uspeed and Zenbook @ Digitus DN-3023:

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1K bytes: 109474 Kbytes / s Tx, 112128 Kbytes / s Rx.
Packet size 2k bytes: 109498 Kbytes / s Tx, 112329 Kbytes / s Rx.
Packet size 4k bytes: 107946 Kbytes / s Tx, 112493 Kbytes / s Rx.
Packet size 8k bytes: 107785 Kbytes / s Tx, 113258 Kbytes / s Rx.
Packet size 16k bytes: 110 996 KByte / s Tx, 114254 Kbytes / s Rx.
Packet size 32k bytes: 106414 Kbytes / s Tx, 103136 Kbytes / s Rx.
Done.

CONCLUSION # 1: The used bisherig Intel Pro card in standard PC1 was the limiting factor in the discrepancy between sending and receiving what is vermeindlich at the intersection of LAN card to the motherboard, so for standard PC1 is computer memory conditionally. Anchor and Digitus are therefore both able to send about 900 Mbit / s and receive. So the pace is great, with two adapters!

CONCLUSION # 2: Unfortunately, I could continue in any combination (except the lucky number 7 sports in the HP ProCurve 1810G-24) neither the Digitus yet the delivered today Uspeed anchor for displaying approvals or copying files through the network or completely simple persuade displaying websites in a browser. Registration on the router (DHCP) works reliably, auto-negotiation also, Gigabit-speed, it is immediately set. The computer can ping each other (also using the computer name) and TCP per NETIO can transmit and measure data. Transmission errors are here, however, most likely not be reported by the ASIX drivers that I had already stated in the first review. As far as I can test it with my private options here, the picture remains that data is probably not transmitted error-free (although now also data can be received in error with more speed: -D) and that is the cause of the transfer windows problems. Thus also the anchor for the customer with a high probability remains unusable. It is also so that the throttled operation with 100 Mbit / s full duplex both adapters 100% working properly.

Finally, again a small matrix display (excluding the switch port number-7-phenomenon), which combinations file sharing and transfers or Web Sites / download enable Windows 7/8:

Anchor 1Gbit @ Zenbook -> Intel @ LAN standard PC1 = fail
Anchor 100 MBit @ Zenbook -> Intel @ LAN standard PC1 = success
Anchor 1Gbit @ Zenbook -> Fritz box / Internet = fail
Anchor 100 MBit @ Zenbook -> Fritz box / Internet = success

Digitus 1Gbit @ Zenbook -> Intel @ LAN standard PC1 = fail
Digitus 100 MBit @ Zenbook -> Intel @ LAN standard PC1 = success
Digitus 1Gbit @ Zenbook -> Fritz box / Internet = fail
Digitus 100 MBit @ Zenbook -> Fritz box / Internet = success

Anchor 1Gbit @ standard PC2 -> Intel @ LAN standard PC1 = fail
Anchor @ 100 MBit standard PC2 -> Intel @ LAN standard PC1 = success
Anchor 1Gbit @ standard PC2 -> Fritz box / Internet = fail
Anchor @ 100 MBit standard PC2 -> Fritz box / Internet = success

Anchor 1Gbit @ standard PC2 -> Digitus 1Gbit @ Zenbook = fail
Anchor @ 100 MBit standard PC2 -> Digitus 100 MBit @ Zenbook = success

Cross-checking (Cabling to / switch as a factor rule):
Intel LAN 1Gbit @ standard PC2 -> Intel LAN 1Gbit @ Standard PC1 = success
Intel LAN 1Gbit @ standard PC2 -> Fritz box / Internet = success
Intel LAN 1Gbit @ Standard PC1 -> Fritz box / Internet = success
Asus ASIX 88178 Adapter 100 MBit @ Zenbook -> Intel @ LAN standard PC1 = success
Asus ASIX 88178 Adapter 100 MBit @ Zenbook -> Fritz box / Internet = success

Final thought:

What I could not test, because all test systems use 64-bit operating system versions, is the extent to which the 32-bit drivers for ASIX chip may work perfectly in gigabit mode. For other Customer Testimonials result shows the problem sometimes, but only sometimes under MacOS.

MY HOPE:

A (professional) controller chip from Marvell, Intel, Broadcom and Realtek. ASIX is obviously big crap. The anchor dates back a shaky controller is enough for me, until the market finally has something solid to offer.

################################################## ############################
########################### Changed on 11.04.2013 ################## #########
################################################## ############################

I have taken a new router into operation and found that the Digitus adapter with the ZyXEL ZyWALL works easily at first, just in gigabit mode. Thus, the problem narrows down. It is possible that the combination of HP ProCurve 1810G-24 (Firmware P2.2) and the ASIX 88179 controller to incompatibilities. Here perhaps find people briefly lose a comment extent Digitus / anchor with Cisco or Zyxel switches or directly to Fritz boxes work with integrated Gigabit switch.

Incidentally works PORT7 the HP switches still impeccable, although the entire cable route has meanwhile changed in between and has also become much longer.

################################################## ############################
########################### Changed on 24/07/2013 ################## #########
################################################## ############################

Today I have 8 installed a driver update for Windows on my (unchanged) Zenbook that is distributed as an optional update via Microsoft Updater in the Control Panel. This is a generic driver for products that are based on the 88179 Controller ASIX. After successful driver installation and rebooting I have again tested a different port on the switch (based on sampling port and 8 port 10) and the Digitus now works perfectly with unchanged settings. It is automatically negotiated Gigabit and I, unlike ever before, easily surf the net without any packets get lost and the browser hangs. Since I left a adapter of goodwill free anchor, I have the Gigabit Adapter again brought out of the closet and plugged - result: Again, this works now seem at first error-free!

The ASIX controller seems so for Windows to work LAST 8, in conjunction with HP switches. Thanks to all users who have hochgerankt here on Amazon this review as helpful, obviously it was selling retardant enough that a driver update was found to be economical. I have raised the rating to 3 stars and get rid of this raise further if I can make no negative points more in the near future and I again measured the performace of the adapter. Thanks also for other comments here on Amazon in this thing!

I now use folgene driver version on the Zenbook:

Manufacturer: ASIX
Driver Date: 23/05/2013
Driver Version: 1.16.7.0
Microsoft certification available

################################################## ############################
########################### Changed on 09/07/2013 ################## #########
################################################## ############################

Driver update by Windows Update for Windows 8, the latest version 1.16.9.0 and runs with me stable since last Edit. Evaluation therefore raised to 5 star.

################################################## ############################
########################### Changed on 11/12/2013 ################## #########
################################################## ############################

Again 1 star deduction: Upgrade to Windows 8.1 allows the card in an otherwise unchanged Setup slightly slower run (transfer rate of 108 MByte / s instead of the previous 114 MB / s). To devaluation leads however even more the fact that blocked since the upgrade communication now and then. Applications such as browsers or Windows File Manager freeze for network access for up to half a minute, then catch up eventually but (with sufficient patience). The driver runs so again less stable under Windows 8.1, some packages seem lost again to go, which are then sent to a new default timeout and eventually can be successfully transferred. Waiting for the timeout is the noticeable hanger. So I'm waiting for another driver update via Windows Update, until then only a 4 star product. Too bad that the manufacturer after the first setback with respect. The driver has not been proactive here and has taken the Windows beta phases.