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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
