Start with the shared path
A hub can expose several 5 or 10 Gbps ports while connecting upstream through one finite link. Port count does not multiply that link. Plan realistic simultaneous demand for devices on the same data path, not every device's marketing ceiling.
The Data Path Checker finds the ceiling of one device chain. The Shared Bandwidth Planner adds concurrent demand within one selected pool. The Hub Power Budget Planner checks the separate power budget.
USB 2.0 and SuperSpeed are separate paths
A conventional USB 3.x hub contains USB 2.0 and SuperSpeed hub functions. A USB 2.0 mouse or audio device uses the USB 2.0 side; plugging it in does not by itself turn a SuperSpeed SSD into a USB 2.0 device. Several busy USB 2.0 devices can still compete within their own shared path.
Identify each device's negotiated connection before budgeting. Run the planner separately for each known pool rather than subtracting USB 2.0 demand from a SuperSpeed budget. A USB 2.0-only cable or intervening hub can force a capable SSD onto the slower path. Separate paths do not guarantee isolation from host-controller, system, firmware, or power limits. USB4/Thunderbolt docks can add another shared transport layer; do not treat their headline rate as a dedicated USB-device pool.
Convert workload units before entering demand
The planner takes Gbps, not MB/s. For decimal units, multiply MB/s by 8 and divide by 1,000. A measured or required 400 MB/s workload is 3.2 Gbps of application data; it is not a 400 Gbps input or a guaranteed USB wire rate. MiB/s uses a different byte unit.
| Illustrative workload | Planner entry |
|---|---|
| SSD 1 reading to the host at 400 MB/s | 3.2 Gbps |
| SSD 2 reading to the host at 400 MB/s at the same time | 3.2 Gbps |
| Combined demand on that pool | 6.4 Gbps |
With a selected 10 Gbps pool and an 80% planning share, the displayed budget is 8 Gbps and this example leaves 1.6 Gbps of planning headroom. The share is an explicit assumption, not measured efficiency or a promised file-copy speed. Use a new run for a different pool or workload. This aggregate screen does not model directional scheduling or predict SSD-to-SSD copy performance.
A powered hub does not create data bandwidth
External power can address an inadequate power budget, but cannot increase the declared upstream data rate. If devices disconnect or reset, investigate supply, cable, and direct-path behavior as well as traffic. If performance falls only when a second transfer starts, compare solo and concurrent runs before blaming either SSD.
Why measured throughput varies
Protocol overhead, scheduling, bursts, storage media, filesystem work, firmware, and other clients on the host controller affect throughput. A budget fit is a planning screen, not a benchmark. It cannot prove that every device receives a fixed share or that a mouse will have a particular latency.
A controlled test order
- Test each device directly and record the negotiated path and sustained workload.
- Identify the hub's upstream link and separate USB 2.0/SuperSpeed paths; do not infer independent controllers from adjacent port shapes.
- Convert demands to Gbps and group only devices sharing the selected pool.
- Run one workload through the hub, then add another in the same direction and compare results.
- If a device falls back, disconnects, or resets, isolate the cable and power path before changing the bandwidth assumption.
Sources
- Microsoft Learn: USB bandwidth allocationFinite controller bandwidth and competing clients.
- Microsoft Learn: USB FAQSeparate USB 2.0/SuperSpeed hub functions, negotiated speed, and fallback.