So I have been recently investigating various sources of power consumption around my house and optimizing them. One of those things that have come up is the USB connection from Velbus to my Intel server. Apparently whenever there’s any 12Mbps USB device connected to an intel-based device its idle power consumption goes through the roof. This problem is actively discussed on Intel forums such as here or here.
While this problem is arguably squarely on Intel’s side, Velbus can contribute positively by using a USB interface that supports USB 2.0 and 480Mbps speeds. This is especially relevant for current velbus configuration modules as they no longer have any RS232 output(s) like VMBRSUSB had.
I haven’t a hub to try this with (I do have hubs, but the port shapes do not work out.) However as far as I know hub does not actually hide speeds of the connected devices and based on a post in one of the referenced threads, adding a hub does not help – at least not an USB hub. It may be possible by adding a PCIe card, but that’s not something I’m in a position to do, nor it makes any economic sense.
EDIT: so looking around for RS232 cables/adapters, those that would negotiate USB High-Speed (480Mbps) are almost impossible to find, with the only one I’ve seen so far being the FT4232H based DIGITUS DA-70159 at a pretty large premium.
The best idea I have right now is to build a RS232 → USB converter myself, using CH347, but the issues around RS232 referenced in this forum aren’t super encouraging…
What is your server setup?
What sort of power consumption difference are you seeing?
What difference do you see with Low-speed (keyboard, mouse) vs Hi-speed vs Full-speed devices?
I don’t see that behaviour here. I just looked at the power consumption of my Homelab server (an Intel N100 with 512GB SSD and 16GB RAM, running Debian). Measuring with a leakage-current clamp-meter on the live supply to the AC PSU.
With monitor, mouse, keyboard connected it consumes about 9.4W
Unplugging everything (including low-speed keyboard+mouse, monitor, but leaving ethernet connected) sees it settle at about 9.2w
Plugging a VMBRSUSB into the front panel USB3 port seems to add a fairly steady 0.6ma (0.14 Watts at 230V).
I have checked dmesg to confirm that the VMBRSUSB enumerated and connected OK. Generating lots of velbus traffic makes no difference either.
I also tried a full-speed device (an FT232R USB dongle) and saw no significant increase in power consumption.
I get brief blips of 75-80ma when I plug or unplug any usb device but that settles back to 40ma almost immediately.
FT232 dongles (and CH340 too) are widely available and very cheap.
What are the “issues around RS232 referenced in this forum” ?
UPDATE: I just tried swapping the USB connection to my test rig for a serial connection using a USB-serial cable. Once I found a serial cable that could fit next to the USB port (front space of VMBRSUSB is a bit snug) it was easy to swap in different serial adapters.
I have now tried five different FTDI USB-serial cables (including some of FTDI’s own adapter products, with full CTS/RTS/DTR support) and they all show the same problem… velbuslink connects just fine but when I “scan” some of my velbus modules are not found. It is not consistent either, the missing modules seem different every time. I tried different USB ports and I tried short stub adapters with 1m fully-connected rs232 cable and get exactly the same result.
Very strange. I had always regarded FTDI adapters as fairly bomb-proof. Never had any trouble with them before.
I have not tried WCH or SiLabs (CH340 or CP2102/2108) adapters because the only ones I have here are TTL level so it would be a bit more “faff”.
I’ve an N100-based server too, though mine has an SFP+ add-in card. Without external USB devices connected I’m seeing the CPU enter Package C8 state and the overall consumption for the CPU is about 0.5W at idle & approx 10W at the wall (5-6W without the SFP+). Plugging in the Velbus USB prevents the CPU from entering the C8 state at all, and the residence in the next achievable package C6 state is comparatively low (~50%), making the CPU draw self-reported 2 watts.
Plugging in a generic CH340G-based (still 12Mbps full-speed) TTL converter instead of the Velbus module apparently allows the CPU to achieve C8 again and reduces the self-reported CPU power consumption back to 0.5W at idle. Thank you for making me test this.
So I guess it is less of a problem with full-speed and more so has something to do with whatever the Velbus module is doing specifically and the interaction of that with the more modern Intel chips
I never really concerned myself with this before… I was just pleased with the N100 low-power consumption and left it at that.
What are you using to monitor cstates and display the (self-reported) power?
I do have PowerTOP installed and I can see some C8 but it’s only a few % and showing 98+% in C10 (whatever that is?).
Is there a better tool for looking at this?
turbostat is my tool of choice as it shows everything (C-states, power, frequencies, temperature) at the same time. C10 is similar to C8 in how little power they consume, they both are really good.
I do have PowerTOP installed and I can see some C8 but it’s only a few % and showing 98+% in C10 (whatever that is?).
Do I understand you correctly that you see some residence in C10 and C8 even with Velbus connected over USB?
Side question: are you using velbustcp or something else? Turns out for me specifically its not just the plain fact that there’s USB connected, but if it is actually being held “open” (by e.g. velbustcp, even if there’s no communication.) If I minicom --device $MYCH340G C-states get locked to C6 too.
So I have found a very similar USB serial device in my “ongoing projects” bucket that does not cause the C-state issue I see with Velbus, even while it is open. Here is the diff between the two devices:
-Bus 003 Device 008: ID 10cf:0b1b Velleman Components, Inc. VMB1USB Velbus USB interface
+Bus 003 Device 009: ID 1546:01a7 U-Blox AG [u-blox 7]
Device Descriptor:
bLength 18
bDescriptorType 1
- bcdUSB 2.00
+ bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
- bMaxPacketSize0 8
- idVendor 0x10cf Velleman Components, Inc.
- idProduct 0x0b1b VMB1USB Velbus USB interface
- bcdDevice 0.02
- iManufacturer 1 Velleman Projects
- iProduct 2 VMB1USB Velbus USB interface
+ bMaxPacketSize0 64
+ idVendor 0x1546 U-Blox AG
+ idProduct 0x01a7 [u-blox 7]
+ bcdDevice 1.00
+ iManufacturer 1 u-blox AG - www.u-blox.com
+ iProduct 2 u-blox 7 - GPS/GNSS Receiver
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
- wTotalLength 0x0043
+ wTotalLength 0x003e
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
- CDC Union:
- bMasterInterface 0
- bSlaveInterface 1
CDC Call Management:
- bmCapabilities 0x00
+ bmCapabilities 0x03
+ call management
+ use DataInterface
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
- bEndpointAddress 0x81 EP 1 IN
+ bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
- wMaxPacketSize 0x000a 1x 10 bytes
- bInterval 1
+ wMaxPacketSize 0x0040 1x 64 bytes
+ bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 [unknown]
- bInterfaceProtocol 0
+ bInterfaceProtocol 255 Vendor specific
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
- bEndpointAddress 0x02 EP 2 OUT
+ bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0001
Self Powered
where the bInterval is well described here. From the looks of it VMBRSUSB is asking the hardware to poll it once every 1ms and keeping hardware busy is the most prominent reason why CPUs don’t get to sleep deeper. Now to see if this can be reasonably adjusted in any way… Any chance the buffer could be increased/poll rate decreased on VMBRSUSB via a firmware update?
If I understand PowerTOP correctly, then yes, I think so.
Normally at idle it sits there with 98+% in C10 and a little in C8.
With a “sudo apt upgrade” going on I see C10 fall to about 50% most of the time and C8 at 20%. Near the end of the upgrade the C10 falls to less than 20%. Then after it finishes back up to 98+% C10. That was with Velbus connected to USB… but NO… nothing is using that connection.
I do use velbustcp but not on this PC. I run it on a Pi3B in the loft to provide a network connection for VelbusLink. I don’t really care if the Pi3B is staying a bit busy.
It’s not bInterval. That is only relevant for Isochronous and Interrupt transfers. A simple CDC like the VMBRSUSB or a FTDI serial port ignores that. Update: Yes, BULK endpoints ignore it too.
It sounds like the problem is just velbustcp… if it is polling the USB driver constantly at a high rate to keep latency low and everything responsive then it seems reasonable that it keeps the CPU out of idle. I think that behaviour would seem fine for the main/original use-case for that interface… to configure the attached velbus network. But, yeah, I can see it’s not great for a permanently attached low-power server.
Can’t easily modify the serial-port hardware to avoid this… not if it is still to look like a standard USB-CDC. A real serial port (ie. a UART) would not have this problem but a USB device has no (standard) way to notify the host it has data waiting. There is a non-standard way but not good for a CDC and anyway can lead to other odd problems.
Velbustcp might be modified to drop the polling frequency when nothing is going on and ramp it up immediately any transfers happen. That might increase the average latency on the first packet but there is plenty of buffering so nothing would be lost. I can even single-step and use breakpoints in my Velbus interface code with my simple test-rig (only 4 velbus nodes)… the OS buffers enough serial that I don’t usually miss anything.
I don’t know if that would help much with a busy velbus attached though. I’ve got a hundred and something nodes on my main velbus including several PIRs… I don’t know what the average/steady CAN packets/second is (I try not to mess with the actual install… experiments happen on my test-rig).
Velbustcp is written in python isn’t it? Source on github?
I use it (as the snap package) on Pi but I’ve never tried to tweak it.
Are you able to use velserv instead? It is a smaller+simpler setup and is written in C. It might be easier to tweak (and the author is here on this forum).
First of all, thank you very much for engaging with me on this. Having somebody to talk through things helps immensely.
Huh, this is not how I understand USB to operate at all. To the best of my knowledge the host machine (the computer in this instance) must poll the device to give it an opportunity to respond with data. So unless the USB host polls VMBRSUSB, VMBRSUSB is not allowed to send any data to the host. My understanding is that it is entirely host’s discretion as to when & at what frequency to poll (esp. for bulk transfers), but bInterval is exactly the field for the device to inform the host of a good choice for the polling interval, so the host doesn’t need to guess. Are you sure device polling from host is not involved with this in any way (especially when the device is being actively used)?
Fair enough, though whatever my GPS module does, it is a standard USB-CDC, very very similar to VMBRSUSB, just without the power problems. I am kinda hoping that the descriptor sent for the VMBRSUSB as well as the buffer sizes are coded somewhere inside its firmware somewhere (after all the descriptor contains Velleman-specific vendor/product IDs, even though I’m pretty sure Velleman doesn’t manufacture its own USB-serial interfaces/chips.
I was able to minimize the reproducer down to this trivial “program” (that I run after velbustcp is shut down):
$ python
Python 3.12.7 (main, Oct 1 2024, 02:05:46) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("/dev/serial/by-id/usb-Velleman_Projects_VMB1USB_Velbus_USB_interface-if00", "rb")
This open function translates pretty directly to the open syscall. There are no threads running in the user-space that would allow for polling or reading data on that serial device in this minimal reproduction. After I call f.close() the C8 residency comes back straight away.
This reproducer strongly suggests to me that whatever is happening is somewhere in the kernel-space or the USB controller(s). The kernel doesn’t appear to be waking up or handling a different number of interrupts with or without velbustcp (powertop event overview), so it has to relate to the built-in USB controller somehow.
I barely see a packet every 30 seconds (but when they come, there’s a bunch of them in short succession.) And this is with couple dozen of modules. This should be an ideal case for the CPU to sleep. VelbusLink “Log” is a good place to get an estimate of the amount of traffic on the bus (and if there’s a lot, that might lead to latency problems sometime down the line.)
So it is the bInterval = 1 on the CDC Communications interface (which is Interrupt-based!), I’m pretty confident.
I applied this kernel patch to 6.12, booted it up with usbcore.interrupt_interval_override=10cf:0b1b:8 (thus overriding the bInterval for the VMBRSUSB interrupt interfaces) and after that the CPU, being well into pkg%pc8, again self-reports 0.8W or so. Question is, of course, how well does this work. I don’t mind a latency of 8ms for Velbus-nodered link , but I’m not super clear on what the size of the buffers on the VMBRSUSB side might be… I scanned my modules 3 times with this and it worked without a hiccup – all modules perfectly detected. Remains to be seen if the bInterval can be raised higher without problems.
I don’t particularly love the idea of maintaining this patch in perpetuity though, and it would be great if Velleman could chime in with whether increased bInterval is likely to work, so that I wouldn’t need to try to validate all of this myself…
One last thing to try some day is to disable xHCI entirely.
Log of achieved depths/power consumption (that I’ll extend as I experiment further):
That’s not really what bInterval is.
bInterval is to tell the USB host controller to reserve space in future USB frames for that device. It is a guaranteed reservation of future bandwidth, in every frame if necessary, for devices that have critical latency and bandwidth requirements. This field only applies to to Isochronous and Interrupt endpoints; and despite the name, even Interrupt endpoints have no way to notify the host… the host still has to poll.
The UHCI will reserve the space itself (so it is not available to other devices). It does not involve the host doing anything except providing or reading the data. I believe it was originally intended for things like streaming audio and video. I have never used it personally, not even for critical bandwidth, as since the arrive of USB2 and USB3 there is usually more than enough async bandwidth available even using ordinary bulk transfers.
I am quite sure that host polling IS involved. But it would not normally happen in the OS or driver. It would usually be at application level. That said there is nothing to stop anyone doing automatic polling in a driver; and since Linux is so open it is possible.
I have developed a few small USB 2-HS and 3-SS devices and have written custom USB drivers for Windows but I have never written drivers for Linux. One issue to consider is that the timing Quantum for Linux is usually 1ms, driven directly from a 1KHz hardware timer. But on windows that quantum is a whopping 10-15ms. And other apps (eg. a web browser that streams video) can change that quantum (usually to 1ms) temporarily but doing-so has knock on effects all over the place. if you rely on Windows threading and events to drive such polling then the timing will be all over the place (eg. have seen USB transfers going quicker when streaming video in a browser! LOL).
My goto ref for this stuff is USB Complete by Jan Axelson. This clip from the 4th ed…
So, just checking I understand, the patch sets USB polling interval for the velbus interface to 8ms?
But the comment in the patch says
“The new interval measured in milliseconds that shall be given to all endpoints of type interrupt on said device”
So it would not make any difference unless the serial-port/CDC uses an Interrupt endpoint?
OK… today I learned something. I did not know that!
So the OS drivers for CDC devices must also be polling independently of the host app?
OK. good to know… thanks for that.
I wonder just when it sets this up. We have seen that just plugging-in and enumerating the device does not do it. Something needs to “use” the device. But surely that would mean that serial data arriving before the host-app connection is only buffered by the USB device, and not by the host. That does seem a bit “odd” to me. The Windows CDC/serial port buffer defaults to 4096 bytes.
I don’t know the on-device buffer size for the VMBRSUSB either although ISTR that some docs somewhere say it has enough buffer for 6 commands.
I now that cheap USB-serial adapters like FTDI, CP2102, CHG430 usually use 64 or 128 bytes of buffer. probably because of the packet size on their endpoints although bulk USB2-FS can use bigger packets.
Update: Today I Learned that I do not know as much about USB as I thought I did.
So… from the descriptors you dumped above, the VMBRSUSB has one endpoint and it IS an Interrupt endpoint (ie. my big mistake above). So, you were right about bInterval… and if you could increase that then the OS/driver polling interval would be longer and you would get your c8 state back?
We can’t change the VMBRSUSB firmware though. And presumably would have the same problem with a USB-Serial interface like FTDI232 or CHG340 where we cannot change the descriptors.
That does not leave many options except maybe to do a completely custom USB CDC device on a suitable micro.
Correct on both counts. My perusal of the Linux CDC-ACM driver over yesterday taught me that the standard way to implement the CDC interface is to have an interrupt-based endpoint for signalling out-of-band information (most often whether something “connects” or “disconnects” which I guess are inferred from the tty device being opened/closed, but also flow control and configuration for serial devices) and the bulk interface for data transfer.
The code has provisions for CDC devices that use the same interface for data transfers and control, but the amount of debug statements suggests this is not the usual way CDC devices should present themselves.
On the first count, you’re right. I remembered updating firmware for other Velbus devices & I absolutely forgot that VMBRSUSB is transparent to the bus and doesn’t appear in velbuslink T_T
On the 2nd count, some serial interface chip implementations appear to have some EEPROM and at least for FTDI there seems to exist a tool to modify the descriptor stored in said EEPROM: FT_PROG. If I can manage to get an FTDI chip with an EEPROM that could be an option to explore…
Ha… I have quite a collection of FT232, CP2102, and CH340## devices
Funnily enough I had just finished plugging them all in to read their descriptors in usbview (on Windows but there is a Linux version too). I now see everything (including VMBRSUSB) has a BULK-IN and BULK-OUT endpoint besides the interrupt endpoint.
I also had picked up the FT-Prog to try out. It’s no-go as far as I can tell, at least for FT232 anyway… it only lets you mess with VID, PID, and string descriptors… plus some custom stuff for different chips in the line-up. The endpoint descriptors just are not there.
Also, as mentioned way up this thread, I did not have much luck getting a FT232R lead (DB-9 with RS232 levels) to work with the VMBRSUSB serial… some nodes failed to appear on scan… like it might be losing or corrupting data somewhere.
I suppose I could check these other interfaces I have but I would need to dig out a TTL<->RS232 level converter first.
The red one is the VMBRSUSB, green is my GPS module as indicated in the diff header:
-Bus 003 Device 008: ID 10cf:0b1b Velleman Components, Inc. VMB1USB Velbus USB interface
+Bus 003 Device 009: ID 1546:01a7 U-Blox AG [u-blox 7]
I’m not sure why it self-identifies as VMB1USB, though. I think I do have another VMB1USB around somewhere. I can see if using it changes anything too.
(and how do you get a monospaced font on here?)
triple ``` above and below the text. Or you can click on the </> icon in the header bar. You can also append the file type for highlighting after the top, kinda like
```diff
-Bus 003 Device 008: ID 10cf:0b1b Velleman Components, Inc. VMB1USB Velbus USB interface
+Bus 003 Device 009: ID 1546:01a7 U-Blox AG [u-blox 7]
```
So, indeed my VMB1USB module is definitely bInterval = 2! Here’s a diff between the two (red is VMB1USB, green is VMBRSUSB):
--- vmb1usb
+++ vmbrsusb
@@ -1,90 +1,89 @@
-Bus 003 Device 003: ID 10cf:0b1b Velleman Components, Inc. VMB1USB Velbus USB interface
+Bus 003 Device 005: ID 10cf:0b1b Velleman Components, Inc. VMB1USB Velbus USB interface
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x10cf Velleman Components, Inc.
idProduct 0x0b1b VMB1USB Velbus USB interface
- bcdDevice 0.01
+ bcdDevice 0.02
iManufacturer 1 Velleman Projects
iProduct 2 VMB1USB Velbus USB interface
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0043
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
- bEndpointAddress 0x82 EP 2 IN
+ bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
- wMaxPacketSize 0x0008 1x 8 bytes
- bInterval 2
+ wMaxPacketSize 0x000a 1x 10 bytes
+ bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
- bEndpointAddress 0x03 EP 3 OUT
+ bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
- bEndpointAddress 0x83 EP 3 IN
+ bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0001
Self Powered
With it I still see pkg%pc8 being achieved, although ever-so-slightly worse levels than with higher bInterval overrides I had during the tests yesterday. I wonder if this might be an outcome of a BOM change in the production of the VMBRSUSB… So I guess just using the VMB1USB is probably the most reasonable solution for me for the time being.
I have my VMBRSUSB plugged into a front panel USB3 port.
I run minicom -H (ie. HEX display mode) to ttyACM0 at 38400N81
I confirm that have a working connection by pressing a button on a VMB8PBU in my test rig… I see the packets come up in minicom.
So… port open and remaining connected.
I am seeing 99.9%, 99.7%, 99.6%, 96.6% in C10 for each core.
Unless there is something odd about your setup I am led back to the idea that the problem you see is caused by velbustcp polling and that minicom manages to poll without that problem.
Is there something else about your setup I might be missing? My debian install is directly on the N100. Are you running linux on top of a VM like Proxmoxx?
I have not tried to install velbus-tcp on this N100 yet though.
Ah, I see where we might have a point of miscommunication. My core C-states look great as well whether I have VMB*USB plugged in and actively read or not. It is the package C-state that is important here, not the CPU or Core ones – and there is only one of those packages in a single-CPU system. The integrated USB hub (among other things like the memory controller and the PCIe stuff) in Intel CPUs are part of the integrated chipset and the whole point of doing it that way is to not power up the cores unnecessarily for the busy work of, say, refreshing the DRAM, clocking a PCIe device, or in my case – polling the connected USB device.
If you’re looking at this in the powertop utility readings for package C-states are on the left-most side, under the Pkg(HW) header. You can also use the following turbostat command: sudo turbostat -s Pkg%pc2,Pkg%pc3,Pkg%pc6,Pkg%pc8,Pk%pc10,PkgWatt,CorWatt which shows power consumption at the same time.
I’m running plain linux.
That said, there is one thing that’s important to note here: the CPU is not going to be bothered by USB devices handled by other chip(s) in the system and at the same time the CPU can’t measure/estimate consumption increase experienced by those other chips. A typical desktop motherboard will usually have a separate chipset chip (typically mounted around the bottom right corner of the motherboard.) This chip will in most implementations be handling a number of PCIe lanes, USB slots, etc. Whether your front panel USB ports are connected directly to the CPU or if they go through the chipset will require reading the manual for the motherboard to know.
For N100-based devices as well as in many laptops, such an external chip usually does not exist at all as the CPU provides sufficient I/O out of the box for those use-cases.
I have also dig up an intel based laptop, figured it would be a good idea to cross-check. Its a i5-10210U-based device and indeed I can still see the appreciably poorer residency and consumption as soon as I connect to the VMBRSUSB. It goes from 0.2W all the way up to 0.8W as soon as I start minicom.
