When none of these conditions are met:
* USB Keyboard connected to any USB 3.0 port
* USB Mouse connected to any USB 3.0 port
* Ethernet port negotiates gigabit speeds
... my NUC7i3DNB, running bios DN0070, has degraded USB performance when testing an R820T2/RTL2832U based dongle (an RTL-SDRblog v3 running in USB 2.0 mode using asynchronous transfers). This was discovered running rtl_test from debian. It reports dropped samples at rates greater than 1.1MSPS (about 1.1MB/s excluding USB overhead).
If I fulfill any of the above conditions involving keyboard, mouse, or gigabit, the dropped sample errors disappear. Even if I connect a mouse while the test is running, the issue clears up immediately.
The molex-style USB 2.0 headers on the board were not tested.
"Max-performance" is checked in the BIOS setup. Adding a dummy HDMI plug to either port has no effect. Having Debian force CPU speed to 2.4GHz has no effect. CPU usage is less than 1%. 100mbps connections do not fix the issue, only gigabit mode.
Is there a setting I may have missed? Could it be a firmware bug? Ideally I am looking for a resolution that doesn't involve keeping a keyboard or mouse plugged in. Can't furnish gigabit at the installation site.
The behavior is as if the lack of keyboard, mouse, or gigabit hints to the BIOS that it is connected to drive a sign, thus is running the I/O in a degraded state to save energy. A sort of "sign mode."
However, I am using it as a headless, keyboardless, SSH-administered embedded system to drive several software-defined radios which use USB dongles where throughput and reliability are important.
UPDATE (I haven't found a way to edit my original post). I created a generic test case transferring from a USB 2.0 flash drive to /dev/null and measuring the throughput.
Without mouse attached:
cat /dev/sdb | pv > /dev/null
7.52GiB 0:04:20 [29.6MiB/s] [ <=> ]
With mouse attached:
cat /dev/sdb | pv > /dev/null
7.52GiB 0:04:06 [31.2MiB/s] [ <=> ]
...as one can see the difference is small but it is consistently reproducible. The transfer with mouse connected is always faster than a transfer without mouse connected. This issue is more serious with an RTL dongle, where samples are dropped and consequent breaks occur in the stream.
Sorry to spam my own thread but there were more developments:
I reset the NUC7i3DNB to default settings, booted it from a Ubuntu 20.04 live USB drive and was still able to reproduce the problem. The BIOS version is DNKBLi30.86A.0070.2020.0924.1031.
However, I then tried the same live USB from a NUC7i3BNB and was not able to reproduce the issue. Its BIOS version is BNKBL357.86A.0083.2020.0714.1344.
Attached are screenshots of the BIOS from each machine:
GOODBIOS.JPG - A photograph of the NUC's BIOS version for the NUC7i3BNB on which the problem is not present. This one wouldn't detect my USB drive to save the screenshot so I used a camera.
BADBIOS.JPG - A screenshot of the NUC's BIOS version for the NUC7i3DNB on which the problem is present.
This strongly smells of a firmware problem. Anyone at Intel want to take this?
Thank you for posting on the Intel* Community.
Unfortunately, Intel* does not test and validate the Intel® NUC on Linux, however, we know that a lot of NUC owners are using it successfully on many different Linux distros.
Intel suggests you check your Linux distro's website and forums at https://www.linux.org/forums/ for assistance with this issue since Intel cannot confirm how the NUC will work on a non tested OS using non-validated drivers.
Intel Customer Support Technician