Bitrate of PeriodicGate in SimpleIeee8021qFilter changes when seemingly unrelated paramater is changed

[haug-den-lucas]

Hello,

I'm experiencing quite a weird bug which I cannot seem to figure out why it happens. I'm working with the streamfiltering/tokenbucket showcase

https://github.com/inet-framework/inet/blob/3af5f7e1f1aeb8e17094d2e59d25c6aa8dfc0339/showcases/tsn/streamfiltering/tokenbucket/omnetpp.ini#L47-L59

What works:

When starting the simulation and exploring the value of switch.bridging.streamFilter.ingress.gate[0].bitrate it is nan bps (expected behavior)

When I only add the following LOC to the omnetpp.ini file:

*.switch.bridging.streamFilter.ingress.gate[*].typename = "PeriodicGate"

The value is still nan bps (expected behavior)

When I only add this line (without the line above):

*.client.hasEgressTrafficShaping = true

The value is still nan bps (expected behavior)

What doesn't work:

However, when I add both lines from above to the omnetpp.ini file:

*.switch.bridging.streamFilter.ingress.gate[*].typename = "PeriodicGate"
*.client.hasEgressTrafficShaping = true

the value of switch.bridging.streamFilter.ingress.gate[0].bitrate now equals: 1e+08bps (not expected)

I cannot make any sense on:

1. Why this effect happens on the PeriodicGate but not the InteractiveGate
2. The bitrate parameter is only set for when I enable egress traffic shaping on the client node, which should be completely unrelated to whatever happens on the switch.

What else I've figures out

The bitrate which is set for the filter gate equals the bitrate specified in the TsnLinearNetwork. Changing this value changes the bitrate for the filter gate https://github.com/inet-framework/inet/blob/3af5f7e1f1aeb8e17094d2e59d25c6aa8dfc0339/src/inet/networks/tsn/TsnLinearNetwork.ned#L12-L15

Setting *.switch.hasEgressTrafficShaping = true or *.server.hasEgressTrafficShaping = true does not have any effect. This only happens when the *client.hasEgressTrafficShaping=true

Sadly I don't have a lot of ideas on how to analyze this in more detail as I can't make any sense out of the behavior described above, so help here would be appreciated.

Side note: I can circumvent the problem by simply setting gate[*].enableImplicitGuardBand = false. However I still think the behavior above is a bug which should be analyzed as it maybe occurs in other unwanted scenarios as well

[levy]

This is where the bitrate is passed down in the time-aware shaper to the gate.

module Ieee8021qTimeAwareShaper extends CompoundPacketQueueBase
{
        ...
        *.bitrate = default(this.bitrate);

There's a similar line that pass down the bitrate from the interface to the queue.

[haug-den-lucas]

This is where the bitrate is passed down in the time-aware shaper to the gate.

module Ieee8021qTimeAwareShaper extends CompoundPacketQueueBase
{
        ...
        *.bitrate = default(this.bitrate);

There's a similar line that pass down the bitrate from the interface to the queue.

Hello,

thanks for the response, however this is not about the bitrate in the shaper but in the filter which is not a submodule of the TAS. Also the change happens in a completely different module (switch) when the TAS is enabled on another module (client)

[levy]

Ah, I misunderstood then. That is indeed very strange.

[levy]

This turned out to be a bug in omnetpp. Do you need a patch or can you workaround the problem for now? The next omnetpp version will contain a fix. Thank you for your effort!

[haug-den-lucas]

Thanks for looking into it that quickly.

gate[*].enableImplicitGuardBand = false works fine as a workout for me at the moment.

[levy]

This issue has been fixed in omnetpp and the fix is part of the 6.1 release.

[haug-den-lucas]

This issue has been fixed in omnetpp and the fix is part of the 6.1 release.

Thanks a lot! Just out of curiosity, can you link me to the issue or pull request that fixed this problem?

[levy]

You can see the patch committed by rhornig in the omnetpp-dev repository on Jun 30. I think there's no PR and issue for this.