Combination of Time Aware Shaper with Frame Preemption

[PhilippComet]

Hello everybody,

my goal is to combine Time Aware Shaping with Frame Preemption. Scheduled Traffic here has higher priority than AVB Traffic. The expected behaviour should look like it is shown in figure b of this graph:

As you can see in the following picture, the queues are growing, but transmission selection does not dequeue frames.

Do you have an idea what could be the reason and what has to be modified, to get this combination running?
I'm looking forward to your responses

Philipp

[levy]

The queue module and the classifier modules are both passive modules, they do not initiate activity. There are queue submodules in the expressMacLayer and preemptableMacLayer submodules by default, I don't know if they are still there. If they are still there the then server submodules in the inner MAC layers cannot pull packets from the outer queue because of the innert queue.

BTW, this scenario has never been tried and most likely doesn't work out of the box.

[PhilippComet]

Hi Levente,
thank for your fast response. The queue submodules in the expressMacLayer and preemptableMacLayer are still there.

Ok, so do I understand it right, that in this case the preempingServer pulls packets from the queue in the expressMacLayer and preemptableMacLayer?
Am I right, that for pulling packets from the outer queue the server needs to be modified/extended or another server module has to be added?

Parallely I'm working on getting more into depth into the code to understand the mechanisms

[levy]

The servers pull packets from the directly connected modules on their input.

Perhaps you could try putting a server module right after the outer queue. This would allow the TAS to send packets to the outbound classifier according to the gate schedule.

[PhilippComet]

Hello Levente,

Thanks for the hint using the server module. Using an InstantServer module directly behind the queue module worked. But in the meantime I figuered out, that one step further to the solution should be to use the queue submodules in the sub-MAC layers in connection with a periodic gate.

Very similar to the TimeAwareShaper module the outboundClassifier can be exchanged by a "PcpTrafficClassClassifier" to realize a PCP priority dependant classification instead of using different VLAN IDs (as in the preemption showcase). So it remains only to add PeriodicGates at the queue submodules in the sub-MAC layers.

I have already tried this modification - but now I have the problem that no packets from the queue submodule of the preemptableMacLayer are dequeued. If I leave the PeriodicGate constantly open, frame preemption works.

My guess is, that the preempting server schedules a timer event at point in time when the transmission of an express packet is expected to be ended to trigger the resumption of the preempted packet. But the PeriodicGate does allow a transmission only at a later point in time - and so the incoming timer event has no effect.

Do you have any idea what could be the cause of the problem?
Please let me know when I can provide you more information.

[levy]

Without having the example I cannot tell what is the cause of this behavior. Let's add a frame preemption combined with time-aware shaper showcase to the repository. Could you please send what you have right now? I'd like to create a new branch for this example and see if we can make it work.

[PhilippComet]

Thank you for your offered help!
here you can find the files that I modified to get to the point I showed above:

tasandfp_modifications.zip (updated 6:28pm GMT+2)

simpleTestNetwork/omnet.ini : To cause frame preemption I configured two apps sending packets with a temporal distribution as shown in app_sending_intervals.jpg

TSNDevice.ned and GatedQueue.ned : I introduced a new module called "GatedQueue" that simply combines a PacketQueue with a PeriodicGate. Changes in TsnDevice still have to be made to consider all existing configurations.

EthernetPreemptingMacLayer.ned : removal of the queue sub module to use queue submodules in sub-MAC layers and exchanging outboundClassifier to classify according to PCP

edit: I'm still working on comprehension of all the mechanisms, but my first guess is that the preemptableServer does not start streaming from the preemptableMacLayer, because it has no knowledge about when gates open/close. I could also imagine that using packet based PeriodicGates in connection with the streaming based preemptingServer could be disfunctional.

[levy]

Thanks for the source files. I noticed that you have changed TsnDevice and EthernetPreemptingMacLayer. I think we can make this work with minor changes and move the rest to the INI file. I will create a new branch in the INET repository called topic/fpandtas that will contain an example in showcases/tsn/combiningfeatures/fpandtas. I replaced the network in the INI file to use the default TsnLinearNetwork that contains a client/server and switch. I assume you only want to have FP and TAS work together in the switch, right?

[PhilippComet]

Thank you for the update. In the long term I would like to also insert the CBS in the queue submodule of the preemtableMacLayer. (Maybe you saw the uncommented part in the .ini file).

In the meantime I had a successful test run with the above shown mods, but only with no guard bands active. I think we have to additionally modify the guardband mechanism. Because now with frame preemption the guardband duration reduces to a new minimum (what can also be seen in the image in the initial post).

Btw, the reason why the AVB packets weren't dequeued in the post above was, that I had a typo in the .ini file. I missspelled the path for the parameter for the implicit guardband and so the default value "true" was set and the guardband has blocked the forwarding. I added some code in PeriodicGate.cc to constantly assume 1500Bytes as guardband before gate closing. So my 100us AVB open cycles were to short to allow transmission.

[levy]

This sequence chart shows almost what you wanted. The implicit guard band is disabled, so the gate state of the express mac layer periodic gate is somewhat misleading, especially in the switch. Nevertheless, the frame preemption happens in the client right at the moment the gate opens.

[PhilippComet]

Yes, unfortunately the drawback with executing the frame preemption when the express mac layer gate opens is, that the express packets will be delayed by a small amount of time. This introduces jitter to the TT-Traffic. I would like to isolate this traffic from lower priority traffic by using the guardband. In the picture the TT-0 frame should start with this modification at 100us with a period of 400us.

My solution approach to get to the point shown in the figure of the initial post would be to end streaming the preemptable traffic a little bit earlier so that the TT (Time Triggered) - Traffic can start reliable at predefined times configured by the GCL (or .transmissionGate.durations parameter)

edit: I'm not sure yet where a trigger signal for earlier stream ending could be implemented, but would perhaps the periodicGate be the right place for it? Because there we have knowledge about the gate switching?

[levy]

The preemption happens exactly at 100us when the TT frame becomes available. The 960ns interval from # 19 to # 21 is there because the preemption happens at the MAC layer and the AVB frame has to be completed with an FCS. Compared to the MAC layer, the packet on the wire contains an extra 8B PHY header, with the 4B FCS it is 96b altogether. This could be reduced to 32b if the PHY overhead would be taken into account in the PreemtableStreamer module. The other 960ns interval from # 21 to # 23 is an IFG, and this cannot be removed. So the total 1920ns could be reduced by 64ns if the implementation would be more sophisticated.

Another option would be to preempt the AVB frame such that it ends at the moment the TT gate opens. Implementing this behavior is more complicated, because there's no direct communication between the gates and the preemption mechanism.

I updated the topic/fpandtas branch and only very little changes were required for the basic approach to work.

[PhilippComet]

Thank you for the detailed explanation about the internal mechanism with the added Bytes to the preempted frame and updating the branch.

As a conclusion, I would suggest that we need to execute the preemption of the AVB frame 1920ns earlier. What do you think about the idea to activate the guardband in periodicGate.cc constantly by this amount of time before the AVB gate closing? We could subscribe the "guardBandStateChangedSignal" in the preemptingServer and call endStreaming() and cancelClockEvent() depending on it.

I already extended the periodicGate.cc code to activate the guardband by constant amount of duration before gate closing.
periodicGate_files.zip (only a draft - I have to still clean up everything)

(for your information: I updated initiallyOpen = true for TT gate and initiallyOpen = false for AVB gate and changed the productionOffset of both sending apps accordingly in the graph. That is different in the .ini file that I sent to you)

[levy]

The guard band of PeriodicGate is active if and only if the gate is open and the next packet cannot flow through the gate before it closes. This is called the implicit guard band, because there are no parameters to control the size of the guard band, other than it's possible to disable it completely. The credit-based shaper uses the guard band signal to update the credit gain rate based on whether the implicit guard band is active or not.

I'm not sure if it's a good idea to change this mechanism to achieve the preemption of a packet flowing through a periodic gate somewhat earlier than the gate is actually closing. I'm still thinking about this a bit more.