Re: Hilfe - Wohin Anfragen bezügl. SocketCAN/FlexCAN

Re: Hilfe - Wohin Anfragen bezügl. SocketCAN/FlexCAN

[Marc Kleine-Budde]

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

On 04/15/2015 02:13 PM, Markus Uhle wrote:
> wir benutzen in einem Medizingerät SocketCAN in Verbindung mit FlexCAN 
> (i.MX53 Prozessor).
> Ich habe im Broadcastmode (SocketCAN, BCM-Manager) einige Probleme, die 
> ich gerne schildern würde.
> 
> Gibt es noch eine aktive Mailing-List für SocketCAN und FlexCAN ?
> An wen könnte ich mich hier wenden?

Ja und zwar die englischsprachigen Liste linux-can@vger.kernel.org

> Mein Problem:
> - Ich registriere im Broadcastmanager z.B. 20 RTR-Requests, die alle 
> 100ms zyklisch gesendet werden sollen (in einer Funktion, also in Etwa 
> zur gleichen Zeit)
> - Am CAN-Bus hängt nur noch die Busterminierung und ein CAN-Sniffer 
> (PeakCAN), der die Messages ack'ed.
> - Wenn ich mehr als 12 Messages im BCM registiere, werden alle Messages 
> ab der 13. Message nur noch selten (ca. alle 1-10 Sekunden) gesendet

Ich habe noch nie mit dem Broadcastmanager gearbeitet....

> Ich habe die Linux-Sourcen vom BCM und vom FlexCAN schon angeschaut und 
> finde keine offensichtlichen Fehler.
> 
> Meine Vermutung ist, dass wenn ich sehr schnell hintereinander im BCM 
> (SocketCAN) Nachrichten registiere, die zyklisch alle
> 100ms gesendet werden sollen, dann liegen diese so dicht zusammen, dass 
> die nächste Nachricht eventuell schon gesendet
> wird (vom BCM zum FlexCAN), bevor die alte Nachricht über den Bus raus 
> ist. In dem Fall wird die alte Nachricht eventuell
> abgebrochen. Ich habe im FlexCAN-Treiber keinen Rückgabewert wie "cannot 
> be sent, because I am busy" gefunden.

Das ist richtig, diesen Rückgabewert gibt es nicht, da der Treiber seine
TX-Queue anhält, falls er keine Pakete mehr aufnehmen kann. Zur Zeit ist
im Flexcan Treiber nur eine Queue mit der Tiefe von einem Paket
implementiert. Die Länge der Queue ist per default 10 Pakete. Das könnte
Ihre Beobachtung erklären. Vielleicht ist der BCM nicht darauf
ausgelegt, dass nicht alle Pakete in der Queue laden.

Ich schlage vor, dass Sie Ihre Problembeschreibung auf die Liste posten
und wir dort weiter diskutieren.

Grüße,
Marc Kleine-Budde

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


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

Re: Hilfe - Wohin Anfragen bezügl. SocketCAN/FlexCAN

[Marc Kleine-Budde]

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

On 04/15/2015 02:23 PM, Marc Kleine-Budde wrote:
> Das ist richtig, diesen Rückgabewert gibt es nicht, da der Treiber seine
> TX-Queue anhält, falls er keine Pakete mehr aufnehmen kann. Zur Zeit ist
> im Flexcan Treiber nur eine Queue mit der Tiefe von einem Paket
> implementiert. Die Länge der Queue ist per default 10 Pakete. Das könnte
> Ihre Beobachtung erklären. Vielleicht ist der BCM nicht darauf
> ausgelegt, dass nicht alle Pakete in der Queue laden.
> 
> Ich schlage vor, dass Sie Ihre Problembeschreibung auf die Liste posten
> und wir dort weiter diskutieren.

Doh! Since I put the mailinglist by accident on Cc I'll recap the
problem for the audience.

Markus is using the flexcan on a imx53. He encounters a problem with the
broadcast manager. When registering more than 12 messages (to be send
every 100ms) at the BCM, the 13th message delayed and only send every 1
to 10 seconds.

I suspect the problem may be related with the default queue length of 10
CAN frames per interface. The BCM might not handle -ENOBUFS correctly.

Markus, try to increase the TX queue length by:

    ifconfig can0 txqueuelen 100

or 1000.

Marc

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


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

Re: Hilfe - Wohin Anfragen bezügl. SocketCAN/FlexCAN

[Oliver Hartkopp]

On 15.04.2015 14:30, Marc Kleine-Budde wrote:
> On 04/15/2015 02:23 PM, Marc Kleine-Budde wrote:
>> Das ist richtig, diesen Rückgabewert gibt es nicht, da der Treiber seine
>> TX-Queue anhält, falls er keine Pakete mehr aufnehmen kann. Zur Zeit ist
>> im Flexcan Treiber nur eine Queue mit der Tiefe von einem Paket
>> implementiert. Die Länge der Queue ist per default 10 Pakete. Das könnte
>> Ihre Beobachtung erklären. Vielleicht ist der BCM nicht darauf
>> ausgelegt, dass nicht alle Pakete in der Queue laden.
>>
>> Ich schlage vor, dass Sie Ihre Problembeschreibung auf die Liste posten
>> und wir dort weiter diskutieren.
>
> Doh! Since I put the mailinglist by accident on Cc I'll recap the
> problem for the audience.

:-)

>
> Markus is using the flexcan on a imx53. He encounters a problem with the
> broadcast manager. When registering more than 12 messages (to be send
> every 100ms) at the BCM, the 13th message delayed and only send every 1
> to 10 seconds.
>
> I suspect the problem may be related with the default queue length of 10
> CAN frames per interface. The BCM might not handle -ENOBUFS correctly.
>
> Markus, try to increase the TX queue length by:
>
>      ifconfig can0 txqueuelen 100
>
> or 1000.

This would be my suggestion too.

The BCM tries to fulfill the TX cycle as precise as possible.
When Markus adds 12/13 TX jobs at a time these jobs are very close to each 
other from CAN frame duration perspective. So the jobs trigger nearly at the 
same time, generate a pile-up in the tx queue and the tx frames get dropped.

So you can try to stretch the BCM setup in the way that you don't get pileups:

- at creation time (wait between syscalls)
- by using the two timer values and switch after one frame to the wanted cycle

Or increase the txqueuelen - but you would still have a pile-up of frames 
which is probably not wanted at the receiver too (processing time issues).

Regards,
Oliver

>
> Marc
>

Re: Hilfe - Wohin Anfragen bezügl. SocketCAN/FlexCAN

[Markus Uhle]

Thanks for your suggestions.
I will try to increase txqeuelen first and write the result in the 
mailing list.

Am 15.04.2015 um 14:45 schrieb Oliver Hartkopp:
> On 15.04.2015 14:30, Marc Kleine-Budde wrote:
>> On 04/15/2015 02:23 PM, Marc Kleine-Budde wrote:
>>> Das ist richtig, diesen Rückgabewert gibt es nicht, da der Treiber 
>>> seine
>>> TX-Queue anhält, falls er keine Pakete mehr aufnehmen kann. Zur Zeit 
>>> ist
>>> im Flexcan Treiber nur eine Queue mit der Tiefe von einem Paket
>>> implementiert. Die Länge der Queue ist per default 10 Pakete. Das 
>>> könnte
>>> Ihre Beobachtung erklären. Vielleicht ist der BCM nicht darauf
>>> ausgelegt, dass nicht alle Pakete in der Queue laden.
>>>
>>> Ich schlage vor, dass Sie Ihre Problembeschreibung auf die Liste posten
>>> und wir dort weiter diskutieren.
>>
>> Doh! Since I put the mailinglist by accident on Cc I'll recap the
>> problem for the audience.
>
> :-)
>
>>
>> Markus is using the flexcan on a imx53. He encounters a problem with the
>> broadcast manager. When registering more than 12 messages (to be send
>> every 100ms) at the BCM, the 13th message delayed and only send every 1
>> to 10 seconds.
>>
>> I suspect the problem may be related with the default queue length of 10
>> CAN frames per interface. The BCM might not handle -ENOBUFS correctly.
>>
>> Markus, try to increase the TX queue length by:
>>
>>      ifconfig can0 txqueuelen 100
>>
>> or 1000.
>
> This would be my suggestion too.
>
> The BCM tries to fulfill the TX cycle as precise as possible.
> When Markus adds 12/13 TX jobs at a time these jobs are very close to 
> each other from CAN frame duration perspective. So the jobs trigger 
> nearly at the same time, generate a pile-up in the tx queue and the tx 
> frames get dropped.
>
> So you can try to stretch the BCM setup in the way that you don't get 
> pileups:
>
> - at creation time (wait between syscalls)
> - by using the two timer values and switch after one frame to the 
> wanted cycle
>
> Or increase the txqueuelen - but you would still have a pile-up of 
> frames which is probably not wanted at the receiver too (processing 
> time issues).
>
> Regards,
> Oliver
>
>>
>> Marc
>>
>