Wolfgang Grandegger wrote:
> Hello,
> 
> on the Xenomai mailing list the topic "bus error flooding" popped up
> again. Various users reported trouble due to high bus error rates and
> bad impact on latencies. Some discussion is going on on how to avoid
> such flooding. I have already implemented "on-demand" bus error
> interrupts. Bus error interrupts are then only enabled when at least one
> socket is listening on bus errors. But flooding can still occur and we
> are thinking about a better way of downscaling or temporarily disabling
> them. Socket-CAN currently restarts the controller after 200 bus errors.
> My preferred solution for RT-Socket-CAN currently is to stop the CAN
> controller after a kernel configurable amount of successive bus errors.
> More clever ideas and comments are welcome?
> 
> To have some input, I have measured the bus error rate with the PEAK
> PCAN PCI card on my Icecube MPC5200 eval-board doing rtcansend without
> cable connected. Here are the results for the various baud-rates:
> 
>    125 KB/s  1926 BEI/s
>    250 KB/s  3925 BEI/s
>    500 KB/s  7856 BEI/s
>   1000 KB/s 15700 BEI/s

So bus errors come in at a rate comparable to shortest possible frames
at maximum speed, right? That's an IRQ load you can live with - if you
plan to load your CAN bus at 100% anyway. But if you don't...

> 
> The latency measured with "latency" from the testsuite reported an
> increase of the latency with load from 67 to 95us almost independently
> of the baud-rate. Sending messages with 8 byte payload from MSCAN to
> SJA1000 on the same node as fast as possible increased the latency up to
> 103us. This measurement did not include delivery of messages to sockets
> (actually no socket was listening).
> 

Some dump of /proc/xenomai/stat would be interesting (system load in
both cases).

Jan