Definitely the USB-C on a NUC7 (maybe the model matters maybe not)
I have tried to reset the port in the NUC setup (Video default to HDMI) but no go. I have a USB 3 version that DOES work....
I also tried this same adapter (USB-C ) in a NUC 8 and it DOES work.
Hi,
Congratulations for adding this feature in the first place. This will surely ease building more complex labs.
One feature request though, can you add as well support for the older but mostly used Realtek RTL8152 chipset as well?
Thanks a lot,
Mihai
Hi Songtao,
I had some time now to test the throughput of the ASIX and Realtek adapters. Whilst the performance of the ASIX adapter is generally good (TX is still lower than RX), with the Realtek adapters the performance is abysmal. Depending on the load, particularly when receiving packets, the Realtek adapter will seize up completely and more often than not have to be unplugged and replugged.
Then, I realised that the link speed was coming up at 100 Mbps only. I have now tried with multiple Realtek based adapters (Anker, CableCreation and Rankie), and also on multiple switches (Ubiquiti US-16, Cisco SG300 and Cisco SG200); the result is always the same: 100 Mbps. Trying to set the switch port speed to manual kills the link immediately…
Now, the ASIX disparity between TX and RX was already present on the Linux based driver William and yourself worked on. To resolve that, both tx-checksumming and scatter-gather must be set to "on" (that's what I did on my own driver).
The issue with the Realtek driver is hard to say, but perhaps it is because you are only relying on the if_cdce and the usb-ethernet drivers. I suspect that using the r8153/r8152 specific FreeBSD driver (if_ure) would yield better results. The if_ure driver, like the if_axge driver you are using for the ASIX adapters, implements specific firmware functions of the adapter.
Note 1: I have seen your reply on one of the existing comments saying that your own tests puts the performance of both ASIX and Realtek adapters on a par. Nobody else is mentioning anything about link speed… Am I the only one seeing the issue?
Note 2: The ports on my test rig are definitely USB3 and I have confirmed multiple times that Gigabit speeds are achieved when using my Linux based drivers.
Jose,
Thanks much for the feedback.
Regarding RTL8153, I have 3 different vendors' adaptors and all of them working fine on my side. Let's see if any other folks have such issue also for the feedback.
I agree with you that adding if_ure should support them better, meanwhile, cdce is simple and no much needs to configure the hardware or the hardware do not comply the cdce spec well. We will add that in the following update as additional benefit is we can support more devices.
While, at currently stage, one thing I can imagine to have a try but can not guarantee is, Would you mind plug the devices on a Win* host first on a USB3 port and then plug it back on the platform back to see if it works for you or not? If it's not, I am afraid we may need wait a while for next release. Sorry for the convenience as we have never see such issue before.
Regarding ASIX, we are working on that now.
Thanks,
Songtao
Hello Songtao
I have a similar issue with Realtek USB 101001G2.5G LAN 0bda:8156 and a TP Link TL-SG108-M2 8 port unmanaged switch.
After ESXi reboot the nic connects with 100mbps speed and not 2.5G. If I disconnect/reconnect the lan cable (CAT6 15 cm) I get 2.5G speed. But not every time I reboot. Sometime both nic gets 100mbps and other time only vusb0 get 100mbps and vusb1 gets 2.5G.
NUC7i3BNK, VMware ESXi, 7.0.3, 18644231 with ESXi703-VMKUSB-NIC-FLING-51233328-component-18902399.zip installed and local.sh modified to with for link.
/Peter
Hi Songtao,
I have been able to trace the issue with the Realtek driver when using the Ubquiti US-16 switch to being a problem with the switch itself. The advertised speed was just being discarded… I have now been able to validate the both adapters work.With the Cisco router, it seems I just got the cabling wrong when moving from one switch to another.
However, attempts to run iperf against the ASIX adapter, as a server, will result on the following messages on vmkernel.log:
2019-02-16T09:29:11.043Z cpu2:2097548)usbd_setup_ctrl_transfer:1538: Wrong framelength 0 != 8
This seems to be related to the TCP window size used — anything other than 64k will crash the adapter and generate those messages until a reboot.
Overall, the performance is adequate, but I am still getting better results when using my own Linux based drivers.
Looking forward to the next iteration of the fling, though.
Jose
Hi Songtao,
Thank you for you response, but unfortunately I don't have anything other than VMs running Windows.
Anyway, I know the adapters I have tested advertise and link at 1000 Mbps, plugged on the same USB ports and to the same switch ports. I use my own porting of the Realtek Linux driver and it works just fine on ESXi.
I will just wait for the next version of the fling and test again. Although I can simply carry on using my own drivers, it would be a nice option to have once the Linux subsystem is completely removed from ESXi.
By the way, thanks for the great work and the prompt response.
Jose
Hey guys, thanks for this! I have a little problem where when I use the esxcfg-vswitch command to add the usb device as an uplink it seems to perform correctly but doesn't show in the gui as the uplink is in the vswitch. yet if i put a vm in the port group the network is functional. any reason why the gui doesn't reflect this? FYI - I created the vswitch and portgroup in the gui originally to note that the config doesn't stick on a reboot. Am i doing something wrong?
-m
I'm found that you may need to reload the management daemons to get it to show properly (and logout/login), so at the end of the script add:
/etc/init.d/hostd restart
/etc/init.d/vpxa restart
That did it! Thanks @aviegas.
Probably should update the instructions for those homelab folks that may not be using vsphere on a ESXI host.
Also, in the script it seems to have an elaborate waiting period to wait for the link status to be up before assigning it to a vswitch. But is that necessary? If you just want it to stay assigned to a vSwitch and not to have to wait for assignment just because of no link status? Just curious.
In my view there are 2 problems were.
The first, the reason for the script to wait for a link up, is to ensure that the kernel has recognized the USB NICs. They are not identified as early in the boot process (that is the reason for the script). The more complex part is that the USB device recognition is non-deterministic, that's why with multiple NICS the device naming may change from boot to boot.
The second problem is that, in the current driver implementation, the devices is flagged *Always* as UP! Even without a cable connected. That is why as soon as the USB stack identifies the device and creates the vusbx interface, the loop will exit.
If the device driver once change the to allow link up/down detection, then the script can be adapted not to look for an UP condition, but rather to detect the existence of the vusbx device.
Thanks for the feedback!
For the first case, would you please try to re-login the GUI to see if the configration updated? The hostd may not update the info when you check GUI. For the 2nd, please check the instruction scripts to build the configuraton, before a final solution.
For iSCSI there must be additionally rescan of iSCSI adapter and before this some delay/sleep (I tried with 15s):
sleep 15
esxcli storage core adapter rescan --adapter <iSCSI adapter name>
Also, the -M switch command is in some aspect strange ( esxcfg-vswitch -M ${if0} -p "<portgroup name>" vSwitch0 ). It works also without it, but not when using iSCSI. Without it iSCSI vmkernel adapter becomes uncompliant. Its strange, I have no idea why it works in this way, but it works.
I have a ESXi6.7 install on a Intel NUC7i5BEH, the adapter is StarTech US1GC301AU2R USB-C to Dual Gigabit Ethernet Adapter with USB (Type-A) Port. I did a esxcli hardware pci list | more and see the device but doe not show up in esxcli network nic list and not showing in vcenter GUI. Is this adapter not supported? Any hints?
0000:00:14.0
Address: 0000:00:14.0
Segment: 0x0000
Bus: 0x00
Slot: 0x14
Function: 0x0
VMkernel Name:
Vendor Name: Intel Corporation
Device Name: Sunrise Point-LP USB 3.0 xHCI Controller
Configured Owner: VMkernel
Current Owner: VMkernel
Vendor ID: 0x8086
Device ID: 0x9d2f
SubVendor ID: 0x8086
SubDevice ID: 0x2068
Device Class: 0x0c03
Device Class Name: USB controller
Programming Interface: 0x30
Revision ID: 0x21
Interrupt Line: 0x0b
IRQ: 255
Interrupt Vector: 0x31
PCI Pin: 0x00
Spawned Bus: 0x00
Flags: 0x3201
Module ID: 17
Module Name: vmkusb_nic_fling
Chassis: 0
Physical Slot: 4294967295
Slot Description: Onboard - Other
Passthru Capable: false
Parent Device:
Dependent Device:
Reset Method: None
FPT Sharable: false