Unexpected Guardband respectively a wrong credit evolution

[PhilippComet]

Hi everyone,

I observed in the attached testcase, a wrong guardBandStateChangedSignal respectively a wrong credit behavior. With the debugger mode I figured out that the first updateIsInGuardBand()- call at 0.000364s is invoked by an incoming changeTimer in creditBasedGate.cc when the credit value reaches zero. But immediately the guardband is turned off again by the periodicGate by an incoming changeTimer message that invokes the processChangeTimer() which in turn to closes the gate.

It's is a bit weird, that this only happens one time at the beginning of the simulation, but then never again (tested with 5s simulation duration)

It would be great if you could try to reproduce the error, so we could find a solution :)

Best regards, Philipp

ATTACHMENT: testcase_gb_error.zip

[levy]

Thanks for reporting the issue. Can you be a little bit more detailed about what is expected and what happens instead?

[PhilippComet]

Thanks for your fast response. The correct behaviour should be that the credit reaches zero, the guardband-check should be invoked. When the frame is short enough to be served in the time window before the transmission gate closes, it should be dequeued, if not, the guardband signal should be emitted and keep active until the next transmission gate closing event. (see subsequent guardband signal path from 500us ongoing- this looks correct). The credit curve should not increase to values bigger than zero in this example.

In this case, the guardband is set as active but only for an infinitesimally small time duration. For me it looks like there are two simoultaneous incoming changeTimer events.

[levy]

Thanks for the update! I was able to reproduce the problem.

The https://github.com/inet-framework/inet/tree/topic/creditbasedgate branch contains my first try to fix this issue. The problem was caused by opening/closing the gate from setCurrentCredit method. The gate state change caused other modules to react, the call chain reached back to the CreditBasedGate while it was in the middle of the original operation.

I'm still testing this change. Could you please take a look?

[PhilippComet]

Thankyou very much for your help and providing a solution approach! The original attached testcase looks correct now also for me. I further also tested a more complex scenario that reveals another malfunction as you can see in the following two images: The location of the signals you can see in the graph is Switch 1 Port 4:

I have attached the relevant test case from the images here: testcases.zip

Some additional side facts to the network:

• 12 End Stations (ES) and 4 Switches (SW)
• ES1-ES6 are traffic sending sources - ES7-ES12 are traffic sinks
• 15 ST Flows and 30 AVB Flows in the network. Routes are predefined by custom MAC table per switch the GCL for each egress port of End Station and Switch are precalculated externally to ensure Scheduled Traffic (ST) to meet its deadline
• implicit guardband only active for AVB traffic
• 10ms hyperperiod for GCL
• exclusive gating between ST and AVB Traffic => only one transmission gate is open at a time

[levy]

Thanks for the detailed bug report! I'm surprised that another one popped up, I'm looking into this one.

[levy]

I updated the topic/creditbasedgate branch with a series of small changes that fix the above issue. Could you please check if everything seems right?

[PhilippComet]

Hi Levente, thank you very much for your quick support and the new adjustments!

I did some extended testing with multiple AVB traffic classes shaped by parallel Credit Based Shapers and different network loads. Everything looks correct now also for frozen and nonfrozen credit accumulation during guardband.

Best Regards

[levy]

Thanks for your contribution!