inet-framework / inet

INET Framework for the OMNeT++ discrete event simulator
https://inet.omnetpp.org
Other
438 stars 486 forks source link

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

Open haug-den-lucas opened 4 months ago

haug-den-lucas commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

levy commented 4 months ago

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 commented 4 months ago

Thanks for looking into it that quickly.

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