C_CAN: can frame drops

C_CAN: can frame drops

[Ssagarr Patil]

Hi,

I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).

When I use the candump tool to dump can frames I get following message,

'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'

SO to solve this problem if I use the -r option of candump and tried 
candump any -d -e -r 999999999 -l

If I do this the can frames are dropped in the driver ie I see 
this c_can_handle_lost_msg_obj() function being called frequently in which can frame
is overwritten.

How to solve this issue any pointers would be helpful.

Thanks,
--Sagar
 		 	   		  

Re: C_CAN: can frame drops

[Oliver Hartkopp]

Hello Sagar,

generally dropping CAN frames on driver level is a complete different problem
in opposite to dropping CAN frames on socket receive level.

A drop on the socket layer usually occurs, when the application does not get
enough CPU time to read and process the CAN frames. But drops on CAN driver
layer lead to a possible resource problem on your system.

Can you tell a bit more about your platform (hardware, CPU, cpu clock, RAM)
and Linux Kernel version?

Regards,
Oliver


On 23.07.2014 16:48, Ssagarr Patil wrote:
> Hi,
> 
> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
> 
> When I use the candump tool to dump can frames I get following message,
> 
> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
> 
> SO to solve this problem if I use the -r option of candump and tried 
> candump any -d -e -r 999999999 -l
> 
> If I do this the can frames are dropped in the driver ie I see 
> this c_can_handle_lost_msg_obj() function being called frequently in which can frame
> is overwritten.
> 
> How to solve this issue any pointers would be helpful.
> 
> Thanks,
> --Sagar
>  		 	   		  --
> 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
> 

RE: C_CAN: can frame drops

[Ssagarr Patil]

Hi Oliver,

Thanks for your response :-)

>
> generally dropping CAN frames on driver level is a complete different problem
> in opposite to dropping CAN frames on socket receive level.
>
Agreed.

> A drop on the socket layer usually occurs, when the application does not get
> enough CPU time to read and process the CAN frames. But drops on CAN driver
> layer lead to a possible resource problem on your system.
>
For the application layer I have used chrt so that it gets higher priority.

> Can you tell a bit more about your platform (hardware, CPU, cpu clock, RAM)
> and Linux Kernel version?
>
The Linux version is 2.6.37 where as I have patched this kernel to use the v3.15 
C_CAN driver(which uses D_CAN) to use. 

Hardware is DM8148 EVM, ARM clock is @1000Mhz, DDR @533Mhz,

Regards,
--Sagar

> Regards,
> Oliver
>
>
> On 23.07.2014 16:48, Ssagarr Patil wrote:
>> Hi,
>>
>> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
>> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
>>
>> When I use the candump tool to dump can frames I get following message,
>>
>> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
>>
>> SO to solve this problem if I use the -r option of candump and tried
>> candump any -d -e -r 999999999 -l
>>
>> If I do this the can frames are dropped in the driver ie I see
>> this c_can_handle_lost_msg_obj() function being called frequently in which can frame
>> is overwritten.
>>
>> How to solve this issue any pointers would be helpful.
>>
>> Thanks,
>> --Sagar
>> --
>> 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
>>
> --
> 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
 		 	   		  

RE: C_CAN: can frame drops

[Ssagarr Patil]

> Hi Oliver,
>
> Thanks for your response :-)
>
>>
>> generally dropping CAN frames on driver level is a complete different problem
>> in opposite to dropping CAN frames on socket receive level.
>>
> Agreed.
>
>> A drop on the socket layer usually occurs, when the application does not get
>> enough CPU time to read and process the CAN frames. But drops on CAN driver
>> layer lead to a possible resource problem on your system.
>>
> For the application layer I have used chrt so that it gets higher priority.
>
>> Can you tell a bit more about your platform (hardware, CPU, cpu clock, RAM)
>> and Linux Kernel version?
>>
> The Linux version is 2.6.37 where as I have patched this kernel to use the v3.15
> C_CAN driver(which uses D_CAN) to use.
>
> Hardware is DM8148 EVM, ARM clock is @1000Mhz, DDR @533Mhz,

BTW I also tried it on AM335x with the v3.16-rc5 which supports D_CAN
the problem is the same.

Thanks,
--Sagar

>
> Regards,
> --Sagar
>
>> Regards,
>> Oliver
>>
>>
>> On 23.07.2014 16:48, Ssagarr Patil wrote:
>>> Hi,
>>>
>>> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
>>> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
>>>
>>> When I use the candump tool to dump can frames I get following message,
>>>
>>> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
>>>
>>> SO to solve this problem if I use the -r option of candump and tried
>>> candump any -d -e -r 999999999 -l
>>>
>>> If I do this the can frames are dropped in the driver ie I see
>>> this c_can_handle_lost_msg_obj() function being called frequently in which can frame
>>> is overwritten.
>>>
>>> How to solve this issue any pointers would be helpful.
>>>
>>> Thanks,
>>> --Sagar
>>> --
>>> 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
>>>
>> --
>> 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
>
 		 	   		  

Re: C_CAN: can frame drops

[Oliver Hartkopp]

Hi Sagar,

unfortunately I'm not really a C_CAN expert.

I know from a Beaglebone Black which run's at 99% busload without any issues
on the two integrated D_CAN controllers.

Do you have these problems with a stock 2.6.37.x on your hardware too?

Can you send the dmesg output of the c_can related content?

Regards,
Oliver

On 24.07.2014 09:40, Ssagarr Patil wrote:
>> Hi Oliver,
>>
>> Thanks for your response :-)
>>
>>>
>>> generally dropping CAN frames on driver level is a complete different problem
>>> in opposite to dropping CAN frames on socket receive level.
>>>
>> Agreed.
>>
>>> A drop on the socket layer usually occurs, when the application does not get
>>> enough CPU time to read and process the CAN frames. But drops on CAN driver
>>> layer lead to a possible resource problem on your system.
>>>
>> For the application layer I have used chrt so that it gets higher priority.
>>
>>> Can you tell a bit more about your platform (hardware, CPU, cpu clock, RAM)
>>> and Linux Kernel version?
>>>
>> The Linux version is 2.6.37 where as I have patched this kernel to use the v3.15
>> C_CAN driver(which uses D_CAN) to use.
>>
>> Hardware is DM8148 EVM, ARM clock is @1000Mhz, DDR @533Mhz,
> 
> BTW I also tried it on AM335x with the v3.16-rc5 which supports D_CAN
> the problem is the same.
> 
> Thanks,
> --Sagar
> 
>>
>> Regards,
>> --Sagar
>>
>>> Regards,
>>> Oliver
>>>
>>>
>>> On 23.07.2014 16:48, Ssagarr Patil wrote:
>>>> Hi,
>>>>
>>>> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
>>>> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
>>>>
>>>> When I use the candump tool to dump can frames I get following message,
>>>>
>>>> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
>>>>
>>>> SO to solve this problem if I use the -r option of candump and tried
>>>> candump any -d -e -r 999999999 -l
>>>>
>>>> If I do this the can frames are dropped in the driver ie I see
>>>> this c_can_handle_lost_msg_obj() function being called frequently in which can frame
>>>> is overwritten.
>>>>
>>>> How to solve this issue any pointers would be helpful.
>>>>
>>>> Thanks,
>>>> --Sagar
>>>> --
>>>> 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
>>>>
>>> --
>>> 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
>>
>  		 	   		  
> 

RE: C_CAN: can frame drops

[Ssagarr Patil]

Hi Oliver,

>
> unfortunately I'm not really a C_CAN expert.
>
> I know from a Beaglebone Black which run's at 99% busload without any issues
> on the two integrated D_CAN controllers.
>
Ok.

> Do you have these problems with a stock 2.6.37.x on your hardware too?
>
Yes

> Can you send the dmesg output of the c_can related content?
>
Unfortunately in c_can driver there are no lot of debug prints but
I am only concerned about function c_can_handle_lost_msg_obj() 
being called frequently in which can frame is overwritten.

Rest of the driver works fine.

Regards,
--Sagar

 		 	   		  

Re: C_CAN: can frame drops

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On 07/23/2014 04:48 PM, Ssagarr Patil wrote:
> Hi,
> 
> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
> 
> When I use the candump tool to dump can frames I get following message,
> 
> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'

These are the CAN frames dropped by the socket, this means as Oliver
pointed out, that the candump fails to read the CAN frames fast enough
from the socket. How do you connect to the linux box with the c_can?
Where are the CAN frames printed to?

Dropped CAN frames by the hardware should be counted in the rx dropped
in ifconfig.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

RE: C_CAN: can frame drops

[Ssagarr Patil]

Hi Marc,

>>
>> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
>> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
>>
>> When I use the candump tool to dump can frames I get following message,
>>
>> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
>
> These are the CAN frames dropped by the socket, this means as Oliver
> pointed out, that the candump fails to read the CAN frames fast enough
> from the socket. How do you connect to the linux box with the c_can?
> Where are the CAN frames printed to?
>
Agreed this is dropped by the socket, so for this to solve I increased the socket size
(with -r option of candump to 111173056) after doing this I see that there is frame drop in
the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which
can frame is overwritten.

I have a can frame generator which I have connected to the EVM, the EVM is recieving the
frames and just dumping it on stdout going ahead I need to log the canframes to SD card.
 
> Dropped CAN frames by the hardware should be counted in the rx dropped
> in ifconfig.

Yes I can even see this too.

Thanks,
--Sagar
 		 	   		  

Re: C_CAN: can frame drops

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

On 07/25/2014 10:13 AM, Ssagarr Patil wrote:
>>> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
>>> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
>>>
>>> When I use the candump tool to dump can frames I get following message,
>>>
>>> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
>>
>> These are the CAN frames dropped by the socket, this means as Oliver
>> pointed out, that the candump fails to read the CAN frames fast enough
>> from the socket. How do you connect to the linux box with the c_can?
>> Where are the CAN frames printed to?
>>
> Agreed this is dropped by the socket, so for this to solve I increased the socket size
> (with -r option of candump to 111173056) after doing this I see that there is frame drop in
> the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which
> can frame is overwritten.
> 
> I have a can frame generator which I have connected to the EVM, the EVM is recieving the
> frames and just dumping it on stdout going ahead I need to log the canframes to SD card.

...and where is your stdout going? serial line, telnet, ssh?

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

RE: C_CAN: can frame drops

[Ssagarr Patil]

Hi Marc,

>
> On 07/25/2014 10:13 AM, Ssagarr Patil wrote:
>>>> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
>>>> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
>>>>
>>>> When I use the candump tool to dump can frames I get following message,
>>>>
>>>> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
>>>
>>> These are the CAN frames dropped by the socket, this means as Oliver
>>> pointed out, that the candump fails to read the CAN frames fast enough
>>> from the socket. How do you connect to the linux box with the c_can?
>>> Where are the CAN frames printed to?
>>>
>> Agreed this is dropped by the socket, so for this to solve I increased the socket size
>> (with -r option of candump to 111173056) after doing this I see that there is frame drop in
>> the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which
>> can frame is overwritten.
>>
>> I have a can frame generator which I have connected to the EVM, the EVM is recieving the
>> frames and just dumping it on stdout going ahead I need to log the canframes to SD card.
>
> ...and where is your stdout going? serial line, telnet, ssh?
>
Its the serial line.

Regards,
--Sagar
 		 	   		  

Re: C_CAN: can frame drops

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

On 07/25/2014 10:22 AM, Ssagarr Patil wrote:
> Hi Marc,
> 
>>
>> On 07/25/2014 10:13 AM, Ssagarr Patil wrote:
>>>>> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
>>>>> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
>>>>>
>>>>> When I use the candump tool to dump can frames I get following message,
>>>>>
>>>>> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
>>>>
>>>> These are the CAN frames dropped by the socket, this means as Oliver
>>>> pointed out, that the candump fails to read the CAN frames fast enough
>>>> from the socket. How do you connect to the linux box with the c_can?
>>>> Where are the CAN frames printed to?
>>>>
>>> Agreed this is dropped by the socket, so for this to solve I increased the socket size
>>> (with -r option of candump to 111173056) after doing this I see that there is frame drop in
>>> the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which
>>> can frame is overwritten.
>>>
>>> I have a can frame generator which I have connected to the EVM, the EVM is recieving the
>>> frames and just dumping it on stdout going ahead I need to log the canframes to SD card.
>>
>> ...and where is your stdout going? serial line, telnet, ssh?
>>
> Its the serial line.

That's not good. As printing to the serial console is quite costly.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

RE: C_CAN: can frame drops

[Ssagarr Patil]

Hi Marc,

Thanks for the response!
>
> On 07/25/2014 10:22 AM, Ssagarr Patil wrote:
>> Hi Marc,
>>
>>>
>>> On 07/25/2014 10:13 AM, Ssagarr Patil wrote:
>>>>>> I am using the c_can driver for latest kernel and using the latest canutils to dump to a file.
>>>>>> My can bus is set at a rate of 1Mb (receiving 7000fps bus load of 80%).
>>>>>>
>>>>>> When I use the candump tool to dump can frames I get following message,
>>>>>>
>>>>>> 'DROPCOUNT: dropped 2223 CAN frames on 'any' socket (total drops 1629092)'
>>>>>
>>>>> These are the CAN frames dropped by the socket, this means as Oliver
>>>>> pointed out, that the candump fails to read the CAN frames fast enough
>>>>> from the socket. How do you connect to the linux box with the c_can?
>>>>> Where are the CAN frames printed to?
>>>>>
>>>> Agreed this is dropped by the socket, so for this to solve I increased the socket size
>>>> (with -r option of candump to 111173056) after doing this I see that there is frame drop in
>>>> the driver ie I see this function c_can_handle_lost_msg_obj() being called frequently in which
>>>> can frame is overwritten.
>>>>
>>>> I have a can frame generator which I have connected to the EVM, the EVM is recieving the
>>>> frames and just dumping it on stdout going ahead I need to log the canframes to SD card.
>>>
>>> ...and where is your stdout going? serial line, telnet, ssh?
>>>
>> Its the serial line.
>
> That's not good. As printing to the serial console is quite costly.
>
Yes agreed, although I also see some frame drops pointed by ifconfig can0
when dumping it to file (with -l option of candump)
I have also used chrt to increase the priority of candump.

Any suggestion on how to still improve the performance so as there is zero frame loss ?
either on driver or application side.

Thanks,
--Sagar
 		 	   		  

Re: C_CAN: can frame drops

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On 07/25/2014 10:35 AM, Ssagarr Patil wrote:
>>>> ...and where is your stdout going? serial line, telnet, ssh?
>>>>
>>> Its the serial line.
>>
>> That's not good. As printing to the serial console is quite costly.
>>
> Yes agreed, although I also see some frame drops pointed by ifconfig can0
> when dumping it to file (with -l option of candump)
> I have also used chrt to increase the priority of candump.
> 
> Any suggestion on how to still improve the performance so as there is zero frame loss ?
> either on driver or application side.

Use the latest kernel, at least v3.15 which has tglx's patches
integrated. v3.16 might even be better. If you want to log all CAN
messages, you can probably make use of recvmmsg() to receive more than
one CAN frame at a time (instead of using recvmsg() or read()). When
writing to disk, don't write a single CAN frame at a time, it's better
to write large blocks, i.e. several 4k of data.

Depending on the actual c_can/d_can implementation you're using, there
might be some optimisation left in the driver, i.e. use 32 bit access if
possible. However before touching the driver, measurement to identify
the hot spots should be done.

The next step would be to switch to preempt rt enabled system.

Hope that helps,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

RE: C_CAN: can frame drops

[Ssagarr Patil]

Hi Marc,

>>>
>>> That's not good. As printing to the serial console is quite costly.
>>>
>> Yes agreed, although I also see some frame drops pointed by ifconfig can0
>> when dumping it to file (with -l option of candump)
>> I have also used chrt to increase the priority of candump.
>>
>> Any suggestion on how to still improve the performance so as there is zero frame loss ?
>> either on driver or application side.
>
> Use the latest kernel, at least v3.15 which has tglx's patches
> integrated. v3.16 might even be better. If you want to log all CAN
> messages, you can probably make use of recvmmsg() to receive more than
> one CAN frame at a time (instead of using recvmsg() or read()). When
> writing to disk, don't write a single CAN frame at a time, it's better
> to write large blocks, i.e. several 4k of data.
>
I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)

OK will try experiment with recvmmsg() & and writing to disk with large blocks.
 
> Depending on the actual c_can/d_can implementation you're using, there
> might be some optimisation left in the driver, i.e. use 32 bit access if
> possible. However before touching the driver, measurement to identify
> the hot spots should be done.
>
OK

> The next step would be to switch to preempt rt enabled system.
>
I am afraid I cant use this, as project needs to be run on normal Linux.

Thanks,
--Sagar


 		 	   		  

Re: C_CAN: can frame drops

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

On 07/25/2014 11:47 AM, Ssagarr Patil wrote:
>>> Any suggestion on how to still improve the performance so as there is zero frame loss ?
>>> either on driver or application side.
>>
>> Use the latest kernel, at least v3.15 which has tglx's patches
>> integrated. v3.16 might even be better. If you want to log all CAN
>> messages, you can probably make use of recvmmsg() to receive more than
>> one CAN frame at a time (instead of using recvmsg() or read()). When
>> writing to disk, don't write a single CAN frame at a time, it's better
>> to write large blocks, i.e. several 4k of data.
>>
> I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
> 
> OK will try experiment with recvmmsg() & and writing to disk with large blocks.
>  
>> Depending on the actual c_can/d_can implementation you're using, there
>> might be some optimisation left in the driver, i.e. use 32 bit access if
>> possible. However before touching the driver, measurement to identify
>> the hot spots should be done.
>>
> OK
> 
>> The next step would be to switch to preempt rt enabled system.
>>
> I am afraid I cant use this, as project needs to be run on normal Linux.

Preempt-rt is a normal Linux system, though. :)

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

RE: C_CAN: can frame drops

[Ssagarr Patil]

Hi Marc,

>
> On 07/25/2014 11:47 AM, Ssagarr Patil wrote:
>>>> Any suggestion on how to still improve the performance so as there is zero frame loss ?
>>>> either on driver or application side.
>>>
>>> Use the latest kernel, at least v3.15 which has tglx's patches
>>> integrated. v3.16 might even be better. If you want to log all CAN
>>> messages, you can probably make use of recvmmsg() to receive more than
>>> one CAN frame at a time (instead of using recvmsg() or read()). When
>>> writing to disk, don't write a single CAN frame at a time, it's better
>>> to write large blocks, i.e. several 4k of data.
>>>
>> I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
>>
>> OK will try experiment with recvmmsg() & and writing to disk with large blocks.
>>
>>> Depending on the actual c_can/d_can implementation you're using, there
>>> might be some optimisation left in the driver, i.e. use 32 bit access if
>>> possible. However before touching the driver, measurement to identify
>>> the hot spots should be done.
>>>
>> OK
>>
>>> The next step would be to switch to preempt rt enabled system.
>>>
>> I am afraid I cant use this, as project needs to be run on normal Linux.
>
> Preempt-rt is a normal Linux system, though. :)
>
Yes but our requirement is to not to have on rt-linux :(

Thanks,
--Sagar
 		 	   		  

Re: C_CAN: can frame drops

[Oliver Hartkopp]

Hi Sagar,

>>
>>  If you want to log all CAN
>> messages, you can probably make use of recvmmsg() to receive more than
>> one CAN frame at a time (instead of using recvmsg() or read()). When
>> writing to disk, don't write a single CAN frame at a time, it's better
>> to write large blocks, i.e. several 4k of data.
>>
> I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
> 
> OK will try experiment with recvmmsg() & and writing to disk with large blocks.
>  

I implemented a proof-of-concept for recvmmsg() for candump.

You can try:

https://gitorious.org/linux-can/canpump

:-)

Maybe it helps.

Regards,
Oliver

RE: C_CAN: can frame drops

[Ssagarr Patil]

Hi Oliver,

>
>>>
>>> If you want to log all CAN
>>> messages, you can probably make use of recvmmsg() to receive more than
>>> one CAN frame at a time (instead of using recvmsg() or read()). When
>>> writing to disk, don't write a single CAN frame at a time, it's better
>>> to write large blocks, i.e. several 4k of data.
>>>
>> I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
>>
>> OK will try experiment with recvmmsg() & and writing to disk with large blocks.
>>
>
> I implemented a proof-of-concept for recvmmsg() for candump.
>
> You can try:
>
> https://gitorious.org/linux-can/canpump
>
> :-)
>
Thanks for implementing it I was too doing the same thing although you have removed
the logging part of it I am adding it and testing.


Thanks,
--sagar
 		 	   		  

Re: C_CAN: can frame drops

[Prabhakar Lad]

Hi Oliver,

On Fri, Jul 25, 2014 at 11:43 AM, Oliver Hartkopp
<socketcan@hartkopp.net> wrote:
> Hi Sagar,
>
>>>
>>>  If you want to log all CAN
>>> messages, you can probably make use of recvmmsg() to receive more than
>>> one CAN frame at a time (instead of using recvmsg() or read()). When
>>> writing to disk, don't write a single CAN frame at a time, it's better
>>> to write large blocks, i.e. several 4k of data.
>>>
>> I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
>>
>> OK will try experiment with recvmmsg() & and writing to disk with large blocks.
>>
>
> I implemented a proof-of-concept for recvmmsg() for candump.
>
> You can try:
>
> https://gitorious.org/linux-can/canpump
>

Any plans of adding this into mainline can-utils ?

Thanks,
--Prabhakar Lad

Re: C_CAN: can frame drops

[Oliver Hartkopp]

On 30.07.2014 13:28, Prabhakar Lad wrote:

>>>>  If you want to log all CAN
>>>> messages, you can probably make use of recvmmsg() to receive more than
>>>> one CAN frame at a time (instead of using recvmsg() or read()). When
>>>> writing to disk, don't write a single CAN frame at a time, it's better
>>>> to write large blocks, i.e. several 4k of data.
>>>>
>>> I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
>>>
>>> OK will try experiment with recvmmsg() & and writing to disk with large blocks.
>>>
>>
>> I implemented a proof-of-concept for recvmmsg() for candump.
>>
>> You can try:
>>
>> https://gitorious.org/linux-can/canpump
>>
> 
> Any plans of adding this into mainline can-utils ?
> 

Hm - currently not.

If it turns out to really help to increase the throughput for e.g. candump it
would be worth thinking to integrate it into candump.

But so far there was no feedback from Sagar, if it was at least helpful.

So from my current perspective the canpump source code would be a candidate
for can-tests as many other SocketCAN code examples are sitting there too.

Regards,
Oliver

RE: C_CAN: can frame drops

[Ssagarr Patil]

Hi Oliver,

Sorry for the delayed response! was busy with other work load.

>
>>>>> If you want to log all CAN
>>>>> messages, you can probably make use of recvmmsg() to receive more than
>>>>> one CAN frame at a time (instead of using recvmsg() or read()). When
>>>>> writing to disk, don't write a single CAN frame at a time, it's better
>>>>> to write large blocks, i.e. several 4k of data.
>>>>>
>>>> I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
>>>>
>>>> OK will try experiment with recvmmsg() & and writing to disk with large blocks.
>>>>
>>>
>>> I implemented a proof-of-concept for recvmmsg() for candump.
>>>
>>> You can try:
>>>
>>> https://gitorious.org/linux-can/canpump
>>>
>>
>> Any plans of adding this into mainline can-utils ?
>>
>
> Hm - currently not.
>
> If it turns out to really help to increase the throughput for e.g. candump it
> would be worth thinking to integrate it into candump.
>
> But so far there was no feedback from Sagar, if it was at least helpful.
>
Yes it was beneficial I used MSG_WAITALL flag for recvmmsg() so that 
it waits for n frames and there is no memory wastage.

Also is it possible to configure qdiscs for improving the performance ?

Regards,
--Sagar

 		 	   		  

Re: C_CAN: can frame drops

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

On 07/31/2014 02:41 PM, Ssagarr Patil wrote:
> Hi Oliver,
> 
> Sorry for the delayed response! was busy with other work load.
> 
>>
>>>>>> If you want to log all CAN
>>>>>> messages, you can probably make use of recvmmsg() to receive more than
>>>>>> one CAN frame at a time (instead of using recvmsg() or read()). When
>>>>>> writing to disk, don't write a single CAN frame at a time, it's better
>>>>>> to write large blocks, i.e. several 4k of data.
>>>>>>
>>>>> I am using the v3.16 (the master branch from git://gitorious.org/linux-can/linux-can.git)
>>>>>
>>>>> OK will try experiment with recvmmsg() & and writing to disk with large blocks.
>>>>>
>>>>
>>>> I implemented a proof-of-concept for recvmmsg() for candump.
>>>>
>>>> You can try:
>>>>
>>>> https://gitorious.org/linux-can/canpump
>>>>
>>>
>>> Any plans of adding this into mainline can-utils ?
>>>
>>
>> Hm - currently not.
>>
>> If it turns out to really help to increase the throughput for e.g. candump it
>> would be worth thinking to integrate it into candump.
>>
>> But so far there was no feedback from Sagar, if it was at least helpful.
>>
> Yes it was beneficial I used MSG_WAITALL flag for recvmmsg() so that 
> it waits for n frames and there is no memory wastage.
> 
> Also is it possible to configure qdiscs for improving the performance ?

AFAIK qdiscs are only used in the tx path.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

Re: C_CAN: can frame drops

[Oliver Hartkopp]

On 31.07.2014 14:42, Marc Kleine-Budde wrote:
> On 07/31/2014 02:41 PM, Ssagarr Patil wrote:

>>> But so far there was no feedback from Sagar, if it was at least helpful.
>>>
>> Yes it was beneficial I used MSG_WAITALL flag for recvmmsg() so that 
>> it waits for n frames and there is no memory wastage.
>>

This is probably not usable for candump, which has to provide the displayed
CAN frames pretty fast. I think there's some timeout mechanism too, to stop
the infinitive waiting for n frames.

>> Also is it possible to configure qdiscs for improving the performance ?
> 
> AFAIK qdiscs are only used in the tx path.

Yep! See:
http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf


Regards,
Oliver

Re: C_CAN: can frame drops

[Prabhakar Lad]

Hi Oliver,

On Thu, Jul 31, 2014 at 3:11 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> On 31.07.2014 14:42, Marc Kleine-Budde wrote:
>> On 07/31/2014 02:41 PM, Ssagarr Patil wrote:
>
>>>> But so far there was no feedback from Sagar, if it was at least helpful.
>>>>
>>> Yes it was beneficial I used MSG_WAITALL flag for recvmmsg() so that
>>> it waits for n frames and there is no memory wastage.
>>>
>
> This is probably not usable for candump, which has to provide the displayed
> CAN frames pretty fast. I think there's some timeout mechanism too, to stop
> the infinitive waiting for n frames.
>
It would be helpful with -l option being enabled ?

Regards,
--Prabhakar Lad

>>> Also is it possible to configure qdiscs for improving the performance ?
>>
>> AFAIK qdiscs are only used in the tx path.
>
> Yep! See:
> http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
>
>
> Regards,
> Oliver
>

[RFC] sched policies for candump

[Oliver Hartkopp]

Hello Prabhakar,

I just discovered your pull-request for candump to add scheduling policies for candump:

https://gitorious.org/linux-can/can-utils/commit/0ea8caacfa723271778d000e8cb97b2be4f92165

Is this still needed / valuable?

If so I would suggest to make the commandline option able to handle more than only SCHED_RR ...

Would the following patch be ok for you?

Regards,
Oliver

---

diff --git a/candump.c b/candump.c
index a1146f5..4334be5 100644
--- a/candump.c
+++ b/candump.c
@@ -51,6 +51,7 @@
 #include <libgen.h>
 #include <time.h>
 #include <errno.h>
+#include <sched.h>
 
 #include <sys/time.h>
 #include <sys/types.h>
@@ -124,6 +125,7 @@ void print_usage(char *prg)
 	fprintf(stderr, "         -e          (dump CAN error frames in human-readable format)\n");
 	fprintf(stderr, "         -x          (print extra message infos, rx/tx brs esi)\n");
 	fprintf(stderr, "         -T <msecs>  (terminate after <msecs> without any reception)\n");
+	fprintf(stderr, "         -R <p:prio> (set priority for scheduling policy p={R,F})\n");
 	fprintf(stderr, "\n");
 	fprintf(stderr, "Up to %d CAN interfaces with optional filter sets can be specified\n", MAXSOCK);
 	fprintf(stderr, "on the commandline in the form: <ifname>[,filter]*\n");
@@ -216,6 +218,8 @@ int main(int argc, char **argv)
 	unsigned char logfrmt = 0;
 	int count = 0;
 	int rcvbuf_size = 0;
+	int sched_policy = 0;
+	int sched_priority = 0;
 	int opt, ret;
 	int currmax, numfilter;
 	char *ptr, *nptr;
@@ -240,7 +244,7 @@ int main(int argc, char **argv)
 	last_tv.tv_sec  = 0;
 	last_tv.tv_usec = 0;
 
-	while ((opt = getopt(argc, argv, "t:ciaSs:b:B:u:ldxLn:r:heT:?")) != -1) {
+	while ((opt = getopt(argc, argv, "t:ciaSs:b:B:u:ldxLn:r:heT:R:?")) != -1) {
 		switch (opt) {
 		case 't':
 			timestamp = optarg[0];
@@ -366,6 +370,23 @@ int main(int argc, char **argv)
 			timeout_config.tv_usec = (timeout_config.tv_usec % 1000) * 1000;
 			timeout_current = &timeout;
 			break;
+
+		case 'R':
+		{
+			/* check for supported scheduling policy 'p:<prio>' */
+			if (optarg[0] == 'R' && optarg[1] == ':')
+				sched_policy = SCHED_RR;
+			else if (optarg[0] == 'F' && optarg[1] == ':')
+				sched_policy = SCHED_FIFO;
+			else {
+				print_usage(basename(argv[0]));
+				exit(1);
+			}
+			/* get priority from behind the ':' */
+			sched_priority = atoi(optarg+2);
+			break;
+		}
+
 		default:
 			print_usage(basename(argv[0]));
 			exit(1);
@@ -596,6 +617,17 @@ int main(int argc, char **argv)
 		}
 	}
 
+	/* set scheduler policy and priority */
+	if (sched_policy) {
+		struct sched_param sched;
+
+		memset(&sched, 0, sizeof sched);
+		sched.sched_priority = sched_priority;
+		if (sched_setscheduler(0, sched_policy, &sched) < 0)
+			fprintf(stderr, "\nFailed to select scheduler policy: %s (%d)\n",
+				strerror(errno), errno);
+	}
+
 	/* these settings are static and can be held out of the hot path */
 	iov.iov_base = &frame;
 	msg.msg_name = &addr;

Re: [RFC] sched policies for candump

[Prabhakar Lad]

Hi Oliver,

On Thu, Dec 18, 2014 at 3:11 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Hello Prabhakar,
>
> I just discovered your pull-request for candump to add scheduling policies for candump:
>
> https://gitorious.org/linux-can/can-utils/commit/0ea8caacfa723271778d000e8cb97b2be4f92165
>
> Is this still needed / valuable?
>
If I remember correctly we agreed upon using chrt/nice to achieve this.

But I still feel having an option in the tool itself would be better
choice as some
of the novice users might not be aware of chrt/nice.

> If so I would suggest to make the commandline option able to handle more than only SCHED_RR ...
>
> Would the following patch be ok for you?
>
I am OK with it, but still depends on Marc.

Regards,
--Prabhakar Lad

Re: [RFC] sched policies for candump

[Oliver Hartkopp]

On 18.12.2014 13:33, Prabhakar Lad wrote:

>> Is this still needed / valuable?
>>
> If I remember correctly we agreed upon using chrt/nice to achieve this.
>
> But I still feel having an option in the tool itself would be better
> choice as some
> of the novice users might not be aware of chrt/nice.
>

Ah - now I remember myself.

The point was that you then become in charge to put this into all relevant 
tools - which is probably not what you want.

So increase the awareness for novice users to use chrt/nice looks like the 
better option ;-)

Best regards,
Oliver