All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephane Grosjean <s.grosjean@peak-system.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
	Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
	tom_usenet@optusnet.com.au,
	Manfred Schlaegl <manfred.schlaegl@gmx.at>
Subject: Re: [BULK]Re: [BULK]Re: [PATCH] can: fix loss of frames due to wrong assumption in raw_rcv
Date: Mon, 06 Jul 2015 09:58:14 +0200	[thread overview]
Message-ID: <559A3516.7080404@peak-system.com> (raw)
In-Reply-To: <55980FCE.4030304@hartkopp.net>

Hi Oliver,

${CUSTOMER}'s problem was rather a "loss of frame" issue than an 
"out-of-order" issue... In fact, it seems it was a simple "rookie" error 
of non-testing errno == ENOBUF after having written on the CAN socket.

Regards,

Stéphane

Le 04/07/2015 18:54, Oliver Hartkopp a écrit :
> Hi Stephane,
>
> On 29.06.2015 18:13, Oliver Hartkopp wrote:
>> Hi Stephane,
>>
>> On 25.06.2015 11:36, Oliver Hartkopp wrote:
>>>> Stephane Grosjean <s.grosjean@peak-system.com>
>>>> (..)
>>>> tells that he's facing some loss of frames with the PEAK-System 
>>>> PCAN-USB
>>>> adapter, in case of "relatively"  high bus load... He's running two
>>>> Kernels (3.19 and the last 4.1 patched with this recent "fix"). At the
>>>> moment, he says he always notes some frame leakage, especially when he
>>>> (for example) "resizes windows on his desktop"...
>
> Is $COSTUMERs problem fixed now?
>
> While testing the patches
>
> can: fix loss of CAN frames in raw_rcv
> http://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can.git/commit/?h=testing&id=36c01245eb8046c16eee6431e7dbfbb302635fa8 
>
>
> and
>
> can: replace timestamp as unique skb attribute
> http://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can.git/commit/?h=testing&id=a6ffebda241e513f6e839662d769b60b084d0957 
>
>
> 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).
>
> With 3.16 the out-of-order CAN frame reception is 'relatively' seldom.
> It's more with the PCAN USB and very few with PCAN USB pro.
>
> With the latest 4.2-merge the effect is reproducible after some time 
> (~10min).
>
> Examples:
>
>  drop detected: expected 204 received 212
>  drop detected: expected 237 received 204
>  drop detected: expected 212 received 237
>  drop detected: expected 68 received 69
>  drop detected: expected 70 received 68
>  drop detected: expected 69 received 70
>
> Obviously the frames do not get lost BUT are reordered.
>
> newcounter = frame.data[0];
> if (((counter + 1) & 0xFF) != newcounter) {
>  printf(" drop detected: expected %u received %u\n", counter + 1, 
> newcounter);
> }
> counter = newcounter;
>
> I'm a bit confused as this effect seems to increase with Linux kernel 
> version numbers. I removed all the changes for 4.1 in the 4.2-merge 
> kernel to have a 4.0 CAN subsystem (which was stable for a long time) 
> - but even this patch removal did not fix the out of order reception.
>
> Good thing: The latest changes in 4.1 (which patches) do not drop CAN 
> frames by accident.
>
> Bad thing: Why is the out-of-order reception increasing in Linux?
>
> I /assume/ some changes with RPS (receive packet steering) in the 
> network layer ...
>
>
> Regards,
> Oliver
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt
Handelsregister Darmstadt HRB 9183 
Geschaeftsfuehrung: Alexander Gach, Uwe Wilhelm
--

  parent reply	other threads:[~2015-07-06  7:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-20 17:21 [PATCH] can: fix loss of frames due to wrong assumption in raw_rcv Manfred Schlaegl
2015-06-20 22:42 ` Oliver Hartkopp
2015-06-20 22:42   ` Oliver Hartkopp
2015-06-22  9:48   ` Manfred Schlaegl
2015-06-22  9:48     ` Manfred Schlaegl
2015-06-22 10:24     ` Oliver Hartkopp
2015-06-22 10:24       ` Oliver Hartkopp
     [not found]       ` <5588E6FB.5040903@optusnet.com.au>
2015-06-23  8:01         ` Oliver Hartkopp
2015-06-24  2:13           ` Tom Evans
2015-06-24 19:56             ` Oliver Hartkopp
2015-06-25  8:32               ` [BULK]Re: " Stephane Grosjean
2015-06-25  9:36                 ` Oliver Hartkopp
2015-06-29 16:13                   ` Oliver Hartkopp
2015-07-04 16:54                     ` Oliver Hartkopp
2015-07-05  1:18                       ` Tom Evans
2015-07-05 18:21                         ` Oliver Hartkopp
2015-07-06  5:44                           ` Oliver Hartkopp
2015-07-06  6:50                             ` Tom Evans
2015-07-06 17:09                               ` Oliver Hartkopp
2015-07-06  7:58                       ` Stephane Grosjean [this message]
2015-07-06 17:14                         ` [BULK]Re: " Oliver Hartkopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=559A3516.7080404@peak-system.com \
    --to=s.grosjean@peak-system.com \
    --cc=linux-can@vger.kernel.org \
    --cc=manfred.schlaegl@gmx.at \
    --cc=mkl@pengutronix.de \
    --cc=socketcan@hartkopp.net \
    --cc=tom_usenet@optusnet.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.