--- title: "How Time-Aware Gates Control an Ethernet Queue" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/ethernet-time-aware-gates-transmission-eligibility" last-updated: "2026-10-20" --- # How Time-Aware Gates Control an Ethernet Queue Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. A time-aware transmission gate changes a traffic class's permission to transmit according to a repeating schedule. An open gate removes that restriction; it does not promise immediate transmission. Clock synchronization relates time across participants, while strict or weighted scheduling selects among otherwise eligible traffic. A buyer needs evidence for each role before treating a networking platform as supporting scheduled end-to-end delivery. ## A gate changes which traffic may seek transmission Think of a traffic-class queue at an outgoing Ethernet port. Traffic can be waiting in that queue while its gate is closed. Opening the gate makes that traffic available for transmission selection, subject to the other conditions that apply. A schedule changes the gate states over time and can allow more than one class, or none, during an interval. Microchip's VelocityDRIVE 2025.06 documentation describes per-class open and closed states in a cyclic gate control list. That is a sequence of permissions, rather than a promise that each opening sends a frame. The official IEEE 802.1Qbv project page places scheduled transmission in an engineered LAN and describes time-aware queue draining using timing derived from IEEE 802.1AS. It records approval on December 5, 2015 and publication on March 18, 2016. This historical scope explains the relationship between scheduling and timing; it is not a product support statement. References: [M1](https://microchip-ung.github.io/velocitydrivesp-documentation/vd-docs/2025.06/doc-cg-tsn-tas.html), [TG1](https://www.ieee802.org/1/pages/802.1bv.html), [TG2](https://raw.githubusercontent.com/iproute2/iproute2/v6.17.0/man/man8/tc-taprio.8) ## Separate the time base, schedule and queue selection The time base answers which clock supplies the schedule's time reference. Synchronization establishes the relationship between clocks at different participants. NIST's IEEE 1588 terminology describes that agreement with a shared epoch and specified uncertainty. Agreement between clocks does not itself assign any transmission window. The schedule answers which classes have gate permission at a given point in the cycle. The fixed iproute2 v6.17.0 TAPRIO manual describes a simplified implementation of the IEEE 802.1Q-2018 scheduling state machine: each state permits a subset of traffic classes for an interval. It defines a starting instant against a clock reference and a cycle formed by the sum of the intervals. This is a named Linux implementation, not a universal hardware model. Queue selection then answers which otherwise eligible traffic receives service. Cumulus Linux 5.14 documents strict preference and weighted deficit scheduling. The iproute2 v6.17.0 DRR manual illustrates selection using byte credit. These service rules supply no repeating gate-opening timetable of their own. Giving a closed class a stronger preference cannot replace its missing gate permission. References: [N1](https://www.nist.gov/el/intelligent-systems-division-73500/meanings-common-terms-used-ieee-1588), [TG2](https://raw.githubusercontent.com/iproute2/iproute2/v6.17.0/man/man8/tc-taprio.8), [C1](https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-514/Layer-1-and-Switch-Ports/Quality-of-Service/), [D1](https://raw.githubusercontent.com/iproute2/iproute2/v6.17.0/man/man8/tc-drr.8) ## At 25 microseconds, a high-priority class still waits Consider a wholly hypothetical output with two classes, A and B, and a repeating 100-microsecond cycle. All times here are relative to the start of one invented cycle. A's gate is open from 0 up to, but not including, 20 microseconds. B's gate is open from 20 up to, but not including, 100 microseconds. Each gate is closed during the other class's interval. At 100 microseconds the next cycle begins and A opens again. A and B are arbitrary labels here, unrelated to standardized traffic-class names. At 25 microseconds, stipulate that an A frame is waiting and that A has the highest service priority. A's gate is closed. Its next opening is at 100 microseconds, so 100 minus 25 equals 75 microseconds until gate permission returns. Priority has not moved that opening earlier. The example makes a narrower claim than a 75-microsecond frame delay. At the next opening, traffic ahead of the frame and other transmission conditions can still matter. Nor would an A frame arriving at 5 microseconds necessarily transmit immediately just because A's gate is open. These intervals isolate permission for explanation. They specify no line rate, frame size, guard interval, preemption behavior or multi-hop coordination, and are not a proposed schedule for equipment. ## Twenty percent describes permission time In the invented cycle, A is open for 20 out of 100 microseconds: 20 percent of the cycle. That fraction tells us when A has gate permission. It does not establish that application payload receives 20 percent of the port's nominal bit rate. The example supplies no packet population or framing overhead from which to calculate payload throughput. It also supplies no rule establishing that every permitted instant is usable for another complete frame. A queue can be empty during its opening, or have more waiting work than the opening can serve. The same distinction defeats a deadline inference. The 75-microsecond calculation concerns one frame's next gate opening at one output. It contains no completion time for that frame, no downstream windows and no application processing interval. ## Real transmission must fit the engineered path A real timing claim must account for frame size and serialization: putting a frame onto the link takes time. An already transmitting frame can also affect access to that output. Microchip's 2025.06 TAS documentation explicitly connects frame-size limits to guard-band time before an interval ends. Such reserved time can limit usable transmission opportunities within the nominal schedule. Preemption is another distinct capability. IEEE's 802.1Qbu scope describes suspending a non-time-critical frame, transmitting time-critical traffic and then resuming the interrupted frame. It also requires capability at both link partners before preemption is enabled. An open gate alone does not establish that interruption behavior. Across participants, actual synchronized-clock uncertainty affects how their windows relate. Across a route, each relevant output and the time traffic reaches it affect whether local permission supports the intended delivery. Identical cycle lengths alone do not establish those relationships. The responsible network and application owners need a supported timing analysis for the full path and workload before making a deterministic delivery claim. References: [M1](https://microchip-ung.github.io/velocitydrivesp-documentation/vd-docs/2025.06/doc-cg-tsn-tas.html), [Q1](https://www.ieee802.org/1/pages/802.1bu.html), [N1](https://www.nist.gov/el/intelligent-systems-division-73500/meanings-common-terms-used-ieee-1588), [TG1](https://www.ieee802.org/1/pages/802.1bv.html) ## Buy the supported delivery behavior For an industrial or edge-AI control task, distinguish three supplier claims: a platform can maintain a clock relationship; it can execute the required gate schedule; and it can substantiate the required delivery behavior over the intended path. Evidence for the first leaves the other two unresolved. Ordinary QoS support likewise leaves the timed-permission mechanism unresolved. Software execution and hardware offload also need their own applicability evidence. TAPRIO v6.17.0 describes full offload as cyclic execution of the gate list by the NIC, using the NIC's hardware clock, which is not necessarily synchronized with the host's CLOCK_TAI time base. The offered adapter, driver and software combination must substantiate its actual support. A PTP-capable adapter cannot be assumed to support gate-schedule offload. Ask the supplier or appointed network owner to connect the proposed application's delivery requirement to the supported scheduling mechanism, relevant clocks, competing traffic and complete path. Evidence about one port cannot alone establish the application outcome. A platform with excellent clock agreement but no supported gate execution leaves a scheduling requirement unanswered; a gate-capable port without the required clock relationship leaves coordinated timing unanswered. The related timestamp article explains event capture and clock identity. The separate switch-latency article explains forwarding and measurement boundaries. Those help interpret evidence without replacing this article's decision about transmission permission. References: [TG2](https://raw.githubusercontent.com/iproute2/iproute2/v6.17.0/man/man8/tc-taprio.8) ## Turn a physical connection question into an inquiry If the platform review identifies a separate physical connection or identification question, Leviathan's Physical-Layer Testing & Installation Verification service is a starting point for discussing agreed physical checks and defect documentation. Use the related service and project-inquiry links with a nonconfidential outline of the connections, available records and physical question to resolve. Gate scheduling, clock configuration and deterministic application qualification belong with the appointed network and application specialists. Instrument work requires confirmed equipment, personnel, method and criteria. This article supports a buying decision; it supplies no field procedure or approval to change a live system. ## Primary sources - [TG1 — IEEE 802.1Qbv: Enhancements for Scheduled Traffic](https://www.ieee802.org/1/pages/802.1bv.html). Checked 2026-10-20. Historical project scope and 2015/2016 status: scheduled queue draining, IEEE 802.1AS timing and engineered-LAN applicability. - [TG2 — iproute2 v6.17.0: TAPRIO manual](https://raw.githubusercontent.com/iproute2/iproute2/v6.17.0/man/man8/tc-taprio.8). Checked 2026-10-20. Fixed Linux documentation for the simplified gate-state model, cycle, time reference and full-offload clock distinction. - [M1 — Microchip VelocityDRIVE 2025.06: Time Aware Shaper](https://microchip-ung.github.io/velocitydrivesp-documentation/vd-docs/2025.06/doc-cg-tsn-tas.html). Checked 2026-10-20. Versioned introduction and Maximum SDU size explanation connect gate intervals and guard time; product-specific configuration is not adopted. - [N1 — NIST: Meanings of common terms used in IEEE 1588](https://www.nist.gov/el/intelligent-systems-division-73500/meanings-common-terms-used-ieee-1588). Checked 2026-10-20. Introductory synchronization terminology: shared epoch and specified uncertainty, rather than a platform accuracy specification. - [C1 — NVIDIA Cumulus Linux 5.14: Quality of Service, Egress Scheduler](https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-514/Layer-1-and-Switch-Ports/Quality-of-Service/). Checked 2026-10-20. Release-specific strict and weighted deficit service modes illustrate selection, without attributing time-aware gate support to this platform. - [D1 — iproute2 v6.17.0: DRR manual, Algorithm](https://raw.githubusercontent.com/iproute2/iproute2/v6.17.0/man/man8/tc-drr.8). Checked 2026-10-20. Fixed software example of byte-credit service selection; separate from a time-indexed transmission gate. - [Q1 — IEEE 802.1Qbu: Frame Preemption](https://www.ieee802.org/1/pages/802.1bu.html). Checked 2026-10-20. Historical public scope explains interruption/resumption and link-partner capability, without asserting current product support. ## Related Leviathan resources - [Physical-Layer Testing & Installation Verification](/services/network-testing) - [Project inquiry: define the physical connection question](/contact?service=network-testing&from=%2Farticles%2Fethernet-time-aware-gates-transmission-eligibility) - [Hardware timestamps and clock synchronization](/articles/network-hardware-timestamp-versus-clock-synchronization) - [Switch forwarding latency and timing boundaries](/articles/gpu-switch-cut-through-versus-store-and-forward-latency) - [Service labels, virtual lanes and arbitration](/articles/infiniband-service-level-virtual-lane-mapping) ## Discuss the physical connection question Share the affected connections, available physical records and the checks or documentation needed. Our team will follow up to discuss scope, requirements and availability. [Discuss the scope](/contact?service=network-testing&from=/articles/ethernet-time-aware-gates-transmission-eligibility)