Re: [BULK]Re: [PATCH] can: fix loss of frames due to wrong assumption in raw_rcv

[Tom Evans <tom_usenet@optusnet.com.au>]

On 5/07/2015 2:54 AM, Oliver Hartkopp wrote:
> Hi Stephane,
> ...
> While testing the patches
> ...
> I discovered an increase of out-of-order CAN frame receptions.
> My setup is a core i7 with a PCAN USB and a PCAN USB pro connected to my
> full busload CAN source (1MBit/s, ~8008 frames/s).

Out of order reception is guaranteed with some CAN hardware and driver 
software, such as the MCP2515 controller and Linux. The chip doesn't 
implement a FIFO, but has two receive buffers which can give message 
swaps quite easily. This can be fixed in the driver, but nobody has. 
Details here:

http://www.microchip.com/forums/m620741.aspx

The PCAN-USB uses an SJA1000 which doesn't have that problem. It has a 
64 byte FIFO. What is inside the PCAN-USB Pro isn't documented on their 
web page, but it may be faster or have less transaction overhead or 
latency or something. The PCAN-USB Pro is "no longer manufactured", the 
replacement "PCAN-USB Pro FD" has an FPGA controller.

 > It's more with the PCAN USB and very few with PCAN USB pro.

I'd guess the Pro has less overhead and can get messages over USB faster 
than the other one.

 > I'm a bit confused as this effect seems to increase with Linux kernel
 > version numbers.

As for the later kernels being worse, that looks like a simple case of 
"bloat", with them taking longer to get around to servicing the 
interrupts and reading the messages. Earlier ones are probably reading 
CAN messages one at a time, with each one getting through the stack 
before the next one arrives. Later kernels are probably reading them in 
bursts. Slower controllers (PCAN-USB) expose this sooner.

Can you drop back to a single core to see if this is a multicore 
problem? It will either fix it or make it worse if it is a loading/delay 
problem.

Reordering packets should be considered a serious bug as some CAN 
protocols can't handle this at all.

Regards,

Tom