Quick Answer / Summary: A hub controller introduces each plugged device to the host (enumeration – the device announces itself, gets an address), then relays traffic as scheduled transactions. Single-TT hubs process full-speed (2.0-class) traffic through one translator (a slow device can stall the queue); multi-TT hubs give each port its own translator (peripherals coexist cleanly). Power flows through the same wiring per the tier’s budget. The mechanism explains the behaviours.
The hub looks like a power strip; it works like a tiny switchboard. The mechanism – enumeration, transaction relaying, transaction translators – explains every behaviour the class shows, from plug-and-play to the bandwidth splits. This guide explains the mechanism in plain terms.
Enumeration: The Introduction Protocol
Plug in a device and the hub notices (the port’s status change), tells the host, and the host interrogates the device through the hub: who are you (descriptors), what do you do (class), what address shall you take (enumeration complete). Seconds later the OS mounts it – the whole introduction ran through the hub’s controller. The hub’s firmware quality shows here: clean builds enumerate fast and hot-plug reliably; flaky builds mis-announce or drop devices on re-plug – the enumeration behaviour that the arrival test (pull, re-seat, recognise) exercises directly. The protocol’s elegance: every device, from mouse to drive, runs the same introduction – the hub is the protocol’s concierge.
The Pull-Reseat Test
Unplug and replug: a healthy hub’s host recognises the device within seconds, every time. The test exercises the whole introduction protocol – the arrival ritual’s core leg.
Transaction Relaying and the TT Story
Traffic moves as scheduled transactions: the host polls, the hub relays between upstream and the addressed port. The transaction translator (TT) is the hub’s traffic cop for full/high-speed mixing – when a 480 Mbps host talks to 12 Mbps devices (mice, keyboards), the TT buffers and schedules the speed mismatch. Single-TT hubs: one translator shared by all ports – a chatty slow device can queue-delay its neighbours. Multi-TT hubs: a translator per port – the peripherals coexist cleanly, and the spec line ‘multi-TT’ is the peripheral-hub quality marker. The bandwidth-split behaviour this series describes everywhere is the relay’s shared-upstream reality – the architecture, not a defect.
The Multi-TT Line
The spec-line that separates peripheral-hub builds: multi-TT silicon keeps the mouse smooth while the printer burps. Single-TT builds share one traffic cop – the stutter source the spec line predicts.
Power Through the Same Wires
The hub’s fourth wire-pair set carries power: upstream from the host (bus tier) or the brick (powered tier), distributed downstream per the budget – 100 mA guaranteed per port at enumeration, negotiation upward per the tier’s pool. The mechanism’s honest summary: the hub is a relay for data and a splitter for power, both under one controller’s management – and every behaviour the user experiences (plug-and-play, speed splits, brown-outs) traces to one of the three functions. The architecture understood, the guides’ buying lines read as engineering instead of folklore.
The Three-Function Summary
Introduce (enumeration), relay (transactions), distribute (power) – the hub’s complete job description. Every hub question maps to one of the three.
Hub Mechanism Cheat Sheet
| Function | Mechanism | User-Facing Behaviour |
|---|
| Introduce | Enumeration protocol | Plug-and-play, hot-plug recognition |
| Relay data | Scheduled transactions | Shared bandwidth under parallel load |
| Mix speeds | TT (single vs multi) | Peripheral smoothness; multi-TT preferred |
| Distribute power | Unit loads + tiers | Brown-outs on budget breaches |
Real-World Application Scenarios
A student’s architecture question resolved to the three-function summary – the mechanism readable in one page. A spec-reader’s multi-TT line explained the stutter difference between two peripheral hubs; the second purchase was informed. A tech’s enumeration knowledge turned ‘my device isn’t recognised’ into a pull-reseat diagnosis instead of a driver reinstall.
Recommended Internal Resources
(1) Product cluster – https://zh-zong.com/productlist/ (anchor: multi-TT hubs and spec-stated builds); (2) FAQ – https://zh-zong.com/faq/ (anchor: mechanism and behaviour questions); (3) Contact – https://zh-zong.com/contact/ (anchor: ask the architecture questions directly).
Related Reading in This Series
Frequently Asked Questions (FAQ)
Q: What does a hub controller actually do?
A: Three jobs: introduces devices to the host (enumeration), relays their traffic (transactions), distributes power (per the tier’s budget). Every hub behaviour traces to one of the three.
Q: What is multi-TT and does it matter?
A: Per-port transaction translators – the traffic cops that keep slow devices from queuing each other. For peripheral hubs, the spec line that separates smooth from stuttery.
Q: Why do devices share bandwidth on a hub?
A: One upstream relay – the architecture. Parallel heavy devices split the pipe; peripherals coexist invisibly.
