can-isotp: TX stmin violations

can-isotp: TX stmin violations

[Maik Allgöwer]

Hello everyone,

I'm currently trying to get a device to do isotp.
Sending and receiving seems to be working perfectly fine.

I'm having the issue that when sending a packet, I can see sporadic
violations of the receivers requested min tx separation time.

The pattern always seems to be the following:


Imagine the receiver requests a min tx separation time of 2 ms in a
control frame.

I then sometimes get consecutive frames with the following scheme
of timestamps on an externally connected logger

..

0.0 ms : CF#1
2.5 ms : CF#2
4.0 ms : CF#3

..


In this example CF#2 is delayed by .5 ms on the wire while CF#3 is sent .5 ms too early
when I look at the delta between CF#2 and CF#3 .

To me it seems that, while the messages are put into some tx-queue at the
correct time, they are not actually put on the wire at that exact time leading to CF#3
being put on the wire too early.


I'm probably completely in the wrong here, but I would greatly appreciate any input.


Regards,
Maik

Re: can-isotp: TX stmin violations

[Oliver Hartkopp]

Hello Maik,

On 03.01.22 16:52, Maik Allgöwer wrote:

> Imagine the receiver requests a min tx separation time of 2 ms in a
> control frame.
> 
> I then sometimes get consecutive frames with the following scheme
> of timestamps on an externally connected logger
> 
> ..
> 
> 0.0 ms : CF#1
> 2.5 ms : CF#2
> 4.0 ms : CF#3
> 
> ..
> 
> 
> In this example CF#2 is delayed by .5 ms on the wire while CF#3 is sent .5 ms too early
> when I look at the delta between CF#2 and CF#3 .
> 
> To me it seems that, while the messages are put into some tx-queue at the
> correct time, they are not actually put on the wire at that exact time leading to CF#3
> being put on the wire too early.

Yes. The CAN frames are sent with a 'minimum' gap which is defined with 
STmin, see isotp_tx_timer_handler().

Generally the handling and the sending of the frame is processed - and 
*then* the offset gap of the current time is added. In your case it 
should always be *slightly more* than 2ms, which is fine from the STmin 
specification intention.

The 0.5ms delay of CF#2 is likely introduced on CAN driver level or CAN 
bus level (arbitration?!).

With a virtual CAN it looks like this:

In terminal 1 (STmin = 2ms)

$ isotprecv vcan0 -s 123 -d 321 -m 2

In terminal 2

$ isotpsend vcan0 -d 123 -s 321 -D 30

In terminal 3

$ candump vcan0 -td
  (000.000000)  vcan0  321   [8]  10 1E 01 02 03 04 05 06
  (000.000030)  vcan0  123   [3]  30 00 02
  (000.002116)  vcan0  321   [8]  21 07 08 09 0A 0B 0C 0D
  (000.002238)  vcan0  321   [8]  22 0E 0F 10 11 12 13 14
  (000.002232)  vcan0  321   [8]  23 15 16 17 18 19 1A 1B
  (000.002080)  vcan0  321   [4]  24 1C 1D 1E

Which fits exactly the expectations.

Best regards,
Oliver

Re: can-isotp: TX stmin violations

[Patrick Menschel]

[-- Attachment #1.1: Type: text/plain, Size: 1048 bytes --]

Am 03.01.22 um 18:40 schrieb Oliver Hartkopp:
>> In this example CF#2 is delayed by .5 ms on the wire while CF#3 is
>> sent .5 ms too early
>> when I look at the delta between CF#2 and CF#3 .
>>
>> To me it seems that, while the messages are put into some tx-queue at the
>> correct time, they are not actually put on the wire at that exact time
>> leading to CF#3
>> being put on the wire too early.
> 
> Yes. The CAN frames are sent with a 'minimum' gap which is defined with
> STmin, see isotp_tx_timer_handler().
> 
> Generally the handling and the sending of the frame is processed - and
> *then* the offset gap of the current time is added. In your case it
> should always be *slightly more* than 2ms, which is fine from the STmin
> specification intention.

Hi,

actually spec says *average* gap time should not fall below STMIN.

That .5 is actually not bad at all.
I have seen some autosar manufacturers stretching the spec up to the
point where you request stmin=5 and get st=10 by design.

Regards,
Patrick


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: can-isotp: TX stmin violations

[Oliver Hartkopp]

Hi Patrick,

On 04.01.22 13:06, Patrick Menschel wrote:
> Am 03.01.22 um 18:40 schrieb Oliver Hartkopp:
>>> In this example CF#2 is delayed by .5 ms on the wire while CF#3 is
>>> sent .5 ms too early
>>> when I look at the delta between CF#2 and CF#3 .
>>>
>>> To me it seems that, while the messages are put into some tx-queue at the
>>> correct time, they are not actually put on the wire at that exact time
>>> leading to CF#3
>>> being put on the wire too early.
>>
>> Yes. The CAN frames are sent with a 'minimum' gap which is defined with
>> STmin, see isotp_tx_timer_handler().
>>
>> Generally the handling and the sending of the frame is processed - and
>> *then* the offset gap of the current time is added. In your case it
>> should always be *slightly more* than 2ms, which is fine from the STmin
>> specification intention.
> 
> Hi,
> 
> actually spec says *average* gap time should not fall below STMIN.

I did not see this average gap recommendation so far.

Only:

9.6.5.4
SeparationTime minimum (STmin) parameter definition

The ST min parameter shall be encoded in byte #3 of the FC N_PCI.

This time is specified by the receiving entity. The STmin parameter 
value specifies the minimum time
gap allowed between the transmissions of two ConsecutiveFrame network 
protocol data units (CFs).

The term "average" can not be found in the entire ISO15765-2-2016 
specification ...

> 
> That .5 is actually not bad at all.
> I have seen some autosar manufacturers stretching the spec up to the
> point where you request stmin=5 and get st=10 by design.
> 

Best regards,
Oliver

Re: can-isotp: TX stmin violations

[Patrick Menschel]

[-- Attachment #1.1: Type: text/plain, Size: 830 bytes --]

Am 04.01.22 um 13:37 schrieb Oliver Hartkopp:
>> actually spec says *average* gap time should not fall below STMIN.
> 
> I did not see this average gap recommendation so far.
> 
> Only:
> 
> 9.6.5.4
> SeparationTime minimum (STmin) parameter definition
> 
> The ST min parameter shall be encoded in byte #3 of the FC N_PCI.
> 
> This time is specified by the receiving entity. The STmin parameter
> value specifies the minimum time
> gap allowed between the transmissions of two ConsecutiveFrame network
> protocol data units (CFs).

Hi,

the *average* info is from a german translation.

There is a note at the end of the section where it states that due to
jitter in networking, *average* st's comply to STmin.

I confirm that this note is not in the English ISO15765-2-2016.

Regards,
Patrick




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: can-isotp: TX stmin violations

[Oliver Hartkopp]

On 04.01.22 22:18, Patrick Menschel wrote:
> Am 04.01.22 um 13:37 schrieb Oliver Hartkopp:
>>> actually spec says *average* gap time should not fall below STMIN.
>>
>> I did not see this average gap recommendation so far.
>>

> 
> the *average* info is from a german translation.
> 
> There is a note at the end of the section where it states that due to
> jitter in networking, *average* st's comply to STmin.

Aah!

In fact the discussion hits a valid point. On the one side you might 
think about a time slotted receive task that might only be able to 
process a frame inside this slot. At least in the 'very early' days of 
CAN transport protocols I've heard about such weird implementations.

On the other side (as we can see from the jitter in Maiks's original 
question) we face different requirements in todays implementations. Here 
an *average* result makes sense. But this is no implementation 
requirement but a testing requirement to relax the STmin timing checks then.

Thanks for the recap!

Best regards,
Oliver

Re: can-isotp: TX stmin violations

[Maik Allgöwer]

On 22-01-05 08:36, Oliver Hartkopp wrote:
> 
> In fact the discussion hits a valid point. On the one side you might think
> about a time slotted receive task that might only be able to process a frame
> inside this slot. At least in the 'very early' days of CAN transport
> protocols I've heard about such weird implementations.
> 
> On the other side (as we can see from the jitter in Maiks's original
> question) we face different requirements in todays implementations. Here an
> *average* result makes sense. But this is no implementation requirement but
> a testing requirement to relax the STmin timing checks then.

I did some more testing and the issue seems not to be related to the isotp driver.

The system we are using is an i.MX-based one and we have three CANs.
Two of those are flexcan, the third is a mcp2518fd (mcp251xfd).

I can not reproduce the timing issue on the flexcans, only on the MCP.


Nonetheless, the point regarding the average st is really interesting, thanks Patrick!


Regards,
Maik 

Re: can-isotp: TX stmin violations

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On 14.01.2022 14:19:29, Maik Allgöwer wrote:
> On 22-01-05 08:36, Oliver Hartkopp wrote:
> > 
> > In fact the discussion hits a valid point. On the one side you might think
> > about a time slotted receive task that might only be able to process a frame
> > inside this slot. At least in the 'very early' days of CAN transport
> > protocols I've heard about such weird implementations.
> > 
> > On the other side (as we can see from the jitter in Maiks's original
> > question) we face different requirements in todays implementations. Here an
> > *average* result makes sense. But this is no implementation requirement but
> > a testing requirement to relax the STmin timing checks then.
> 
> I did some more testing and the issue seems not to be related to the isotp driver.
> 
> The system we are using is an i.MX-based one and we have three CANs.
> Two of those are flexcan, the third is a mcp2518fd (mcp251xfd).
> 
> I can not reproduce the timing issue on the flexcans, only on the MCP.

The flexcan uses a single TX buffer, while the mcp251xfd uses 8 for
classical CAN and 4 for CAN-FD.

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: can-isotp: TX stmin violations

[Maik Allgöwer]

Hi everyone,

so I hoped I would not have to bother anyone with this issue again,
but our customer wants this fixed.

I am wondering whether someone could point me into the right direction?

Regards,
Maik

Re: can-isotp: TX stmin violations

[Oliver Hartkopp]

Hi Maik,

On 20.04.22 11:34, Maik Allgöwer wrote:

> so I hoped I would not have to bother anyone with this issue again,
> but our customer wants this fixed.
> 
> I am wondering whether someone could point me into the right direction?

In the upcoming Linux 5.18 I reworked the consecutive frame transmission 
flow in a way that the next CF is only started after the last frame has 
been sent successfully:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4b7fe92c06901f4563af0e36d25223a5ab343782

This new concept will not be back ported to the out-of-tree 
implementation on GitHub.

Are you able to build you own kernel for $CUSTOMER to probably use this 
latest implementation?

I had to go back in the mail thread to check your issue and this 
improvement could probably fix it.

Best,
Oliver