CoRE4INET What is the function of SendWindowEnd?

[Amr Abughazala]

Hello,

I have a question regarding setting the window limits as I can't relate to what I understood for time sensitive data,

As far as I know that as long as the gate is opened for TT traffic it should be closed for all other traffic and during this window the gate state is opened for TT.
In the code once TT msg is received and handled by TTBuffer it is stored and once TimeActionEvent message is received then the TT msg is sent as per the timing in SendWindowStart.
In this case it is not a window that the gate is opened during, but it is opened as long as SendWindowStart is the current time as if SendWindowEnd has no role in the code. I may understood it wrong and this is why I am sending this question.

I did two tests and was surprised that the simulation is not as expected,

1. I set SendWindowStart before or exactly at the ReceiveWindowEnd but what is happening that it waits 1 complete cycle to send the TT data. (the message might be received before the end of the ReceiveWindowEnd so why the SendWindowStart can't be before the ReceiveWindowEnd so that to avoid wasting time "picture is added for clarification") I don't know if there is a way I can edit in the code or not.

2. I wanted to send a message that its size is greater than the SendWindowSize, the message is normally sent ignoring that the SendWindowEnd is before the end of the packet (gate already closed before completing the message) . I also don't know if I am missing something in my configuration that is leading to this result or it is normal only to look at SendWindowStart and not on SendWindowEnd.

I have a picture included explaining what I mean by the wasting time and the short window case. Please don't hesitate to ask if my explanation is not clear.

[Till]

Hi Amr,

Answers inline:

Am Freitag, 21. Oktober 2016 16:34:04 UTC+2 schrieb Amr Abughazala:

Hello,

I have a question regarding setting the window limits as I can't relate to what I understood for time sensitive data,

As far as I know that as long as the gate is opened for TT traffic it should be closed for all other traffic and during this window the gate state is opened for TT.
In the code once TT msg is received and handled by TTBuffer it is stored and once TimeActionEvent message is received then the TT msg is sent as per the timing in SendWindowStart.
In this case it is not a window that the gate is opened during, but it is opened as long as SendWindowStart is the current time as if SendWindowEnd has no role in the code. I may understood it wrong and this is why I am sending this question.

The sendWindowEnd is currently unused. It is an official TTEthernet parameter, but we don't need it as you pointed out the frames transmission is started at SendWindowStart. SendWindowEnd would be required if the TT-Frame would be allowed to be delayed by other frames (shuffling mode) but that is barely used and not fully implemented jet.

 

I did two tests and was surprised that the simulation is not as expected,

1. I set SendWindowStart before or exactly at the ReceiveWindowEnd but what is happening that it waits 1 complete cycle to send the TT data. (the message might be received before the end of the ReceiveWindowEnd so why the SendWindowStart can't be before the ReceiveWindowEnd so that to avoid wasting time "picture is added for clarification") I don't know if there is a way I can edit in the code or not.

You are missing the permanence point. The permanence point is the time when a frame is transferred from the conformance check (incoming) to the buffer. You cannot transfer the frame at a time before you are sure it has arrived. I think you  want to implement is a cut-through switch. right?

The problem with SendWindowStart and ReceiveWindowEnd at the same time is trivial: You try to send a frame that is still in the incoming module. At the configured time the frame would be scheduled but is not yet available. Thus it is scheduled in the next cycle.

 

2. I wanted to send a message that its size is greater than the SendWindowSize, the message is normally sent ignoring that the SendWindowEnd is before the end of the packet (gate already closed before completing the message) . I also don't know if I am missing something in my configuration that is leading to this result or it is normal only to look at SendWindowStart and not on SendWindowEnd.

 That is possible as the SendWindowEnd is not evaluated (as you pointed out). It would be evaluated to prevent delayed TT-frames from sending (because those frames would be dropped in the next receiver due to the receive window)

The rule for your schedule is: you can only send frames after the receive window and permanence point. What you want to do is cut-through the switch and directly start transmission after reception. This would require a completely different switch design, although I don't think it would violate the standard.

best regards

Till

[Amr Abughazala]

You are missing the permanence point. The permanence point is the time when a frame is transferred from the conformance check (incoming) to the buffer. You cannot transfer the frame at a time before you are sure it has arrived. I think you  want to implement is a cut-through switch. right?

I though I already took into consideration of the time window choices the time needed for the packet to be stored. Also I set the permanence point to be exactly the same as ReceiveWindowEnd so giving no time delay from incoming to Buffer.

The idea is that I was just checking if the delay of TT traffic is the same as BE traffic, which I though it should be because no difference if the switch is store and forward then it is store and forward for both traffic. Sending BE, RC or TT at 0 time should be delivered at destination at same time if no waiting is involved, again I don't know if I am missing something in the basics of TT Standard.

The problem with SendWindowStart and ReceiveWindowEnd at the same time is trivial: You try to send a frame that is still in the incoming module. At the configured time the frame would be scheduled but is not yet available. Thus it is scheduled in the next cycle.

so If I am adjusting no waiting and taking into consideration precision for clock, ticks and everything. Then receiving exactly at the time I should receive it,

ReceiveWindowEnd = ReceiveWindowstart + the packet duration (storing time in the buffer, no?)
then why at the SendWindowStart = ReceiveWindowEnd + Sending gap

The problem is that I don't get the sending gap, it can be less than packet size so how it is related to storing the packet? I found it is around 100nsec for packet size of 64B which needs 5.12usec for storing.

best regads,

Amr

[Till]

Am Samstag, 22. Oktober 2016 11:30:26 UTC+2 schrieb Amr Abughazala:

You are missing the permanence point. The permanence point is the time when a frame is transferred from the conformance check (incoming) to the buffer. You cannot transfer the frame at a time before you are sure it has arrived. I think you  want to implement is a cut-through switch. right?

I though I already took into consideration of the time window choices the time needed for the packet to be stored. Also I set the permanence point to be exactly the same as ReceiveWindowEnd so giving no time delay from incoming to Buffer.

The idea is that I was just checking if the delay of TT traffic is the same as BE traffic, which I though it should be because no difference if the switch is store and forward then it is store and forward for both traffic. Sending BE, RC or TT at 0 time should be delivered at destination at same time if no waiting is involved, again I don't know if I am missing something in the basics of TT Standard.

You won't achieve the same best-case latency with BE and TT traffic. This would only be possible with some sort of an ideal schedule and an ideal time synchronization. But in reality you cannot achieve that.

What you want to achieve is an ideal case where the receive window is as small as possible and the time from permanence pit to send window start is zero.

Per definition there must be a difference between the permanence pit and the send window start. What you can do is, you can set the send window start to the same value as the permanence pit + one tick (e.g. sec_to_tick(100us)+1) then the "delay" is one tick. If you set the tick very small you will have a short delay.

 

The problem with SendWindowStart and ReceiveWindowEnd at the same time is trivial: You try to send a frame that is still in the incoming module. At the configured time the frame would be scheduled but is not yet available. Thus it is scheduled in the next cycle.

so If I am adjusting no waiting and taking into consideration precision for clock, ticks and everything. Then receiving exactly at the time I should receive it,

ReceiveWindowEnd = ReceiveWindowstart + the packet duration (storing time in the buffer, no?)
then why at the SendWindowStart = ReceiveWindowEnd + Sending gap

The problem is that I don't get the sending gap, it can be less than packet size so how it is related to storing the packet? I found it is around 100nsec for packet size of 64B which needs 5.12usec for storing.

You are almost right:

SendWindowStart = PermanencePit + 1tick  (with PermanencePit>= ReceiveWindowEnd)

Best regards

Till

 

[Amr Abughazala]

Just to make sure and avoid taking the longer way, is it possible to have this feature of having a window of sending by editing the code instead creating a new switch?

Do you think it would be an easy edit or it will involve other classes that need to be changed?

[Till]

You would have to change at least the incoming and the buffer module