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

[Oliver Hartkopp <socketcan@hartkopp.net>]

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
>