Repository navigation
Conversation
…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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_tstopped the simulation inGateScheduleConfiguratorBase::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.Why not drop the port or stop with an error
Dropping it leaves the neighbour's
otherPortlookup (std::find_ifa 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.cc129-130 and 200-201,Z3GateScheduleConfigurator.cc77 and 120,TSNschedGateScheduleConfigurator.cc206) and give the same inf. Z3 also divides by the datarate of every port for its interframe gap (Z3GateScheduleConfigurator.cc161), 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
tests/module/GateScheduleConfigurator_1.test: the network of the issue with Eager; expectsSimulation time limit reached. It fails on master with the error of the issue and passes with the fix.git amwithout conflict, and the three newGateScheduleConfigurator_*tests pass together.showcases/tsn/gatescheduling/eager, config Eager, runs to its time limit with the fix.Not run: debug build; the full
tests/moduleand fingerprint suites; Z3 and TSNsched (not built here); Linux and Windows.