Skip to content

gatescheduling: fix: do not compute the guard band of an interface without a datarate - #1435

Open
tabgab wants to merge 1 commit into
inet-framework:masterfrom
tabgab:fix/gatescheduling-zero-datarate
Open

tabgab wants to merge 1 commit into
inet-framework:masterfrom
tabgab:fix/gatescheduling-zero-datarate

Conversation

@tabgab

@tabgab tabgab commented Nov 7, 2026

Copy link
Copy Markdown

Fixes #1433. On master 7ec0d4d, one commit.

The guard band of a port is the MTU divided by the datarate of the interface. An interface that reports datarate 0 gave an infinite value, and its conversion to simtime_t stopped the simulation in GateScheduleConfiguratorBase::addPorts. Such a port now keeps the default guard band of -1, the "not set" value of the field; nothing reads the field. The port stays in the input, because the ports of its neighbours refer to it as their other port.

-                port->guardBand = (port->maxPacketLength / port->datarate).get<s>();
+                // an interface without a bitrate (e.g. cellular or tunnel) has no guard band: it stays -1
+                if (port->datarate > bps(0))
+                    port->guardBand = (port->maxPacketLength / port->datarate).get<s>();

Why not drop the port or stop with an error

Dropping it leaves the neighbour's otherPort lookup (std::find_if a few lines below) without a match. An error would reject every network with a radio or tunnel interface, which is the common case (a 5G segment represented by other means, no stream crossing it).

What this does not change

A stream whose path crosses a port without a datarate still cannot be scheduled. The configurators divide by that datarate along the path (EagerGateScheduleConfigurator.cc 129-130 and 200-201, Z3GateScheduleConfigurator.cc 77 and 120, TSNschedGateScheduleConfigurator.cc 206) and give the same inf. Z3 also divides by the datarate of every port for its interframe gap (Z3GateScheduleConfigurator.cc 161), so Z3 still stops on such a network; TSNsched writes portSpeed 0 into its input file. A clear error for such a flow is a separate change.

Evidence

  • New test tests/module/GateScheduleConfigurator_1.test: the network of the issue with Eager; expects Simulation time limit reached. It fails on master with the error of the issue and passes with the fix.
  • With the companion PR (null destination interface), both patches apply with git am without conflict, and the three new GateScheduleConfigurator_* tests pass together.
  • showcases/tsn/gatescheduling/eager, config Eager, runs to its time limit with the fix.
  • Release build, macOS arm64, OMNeT++ 6.5.0.

Not run: debug build; the full tests/module and fingerprint suites; Z3 and TSNsched (not built here); Linux and Windows.

…thout a datarate

The guard band of a port is the MTU divided by the datarate of the
interface. An interface that reports datarate 0 (a cellular or a tunnel
interface, or a link whose channel has no datarate) gave an infinite
value, and its conversion to simtime_t stopped the simulation in
GateScheduleConfiguratorBase::addPorts. Such a port keeps the default
guard band of -1. The port stays in the input, because the ports of the
neighbors refer to it as their other port.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

gatescheduling: GateScheduleConfiguratorBase stops with "Cannot represent inf" for an interface with datarate 0

1 participant