Re: Problem of accuracy

Re: Problem of accuracy

[Oliver Hartkopp]

On 05.07.2012 10:12, Mohamed HAMZAOUI wrote:
> Hi,
>
> i'm a new user of socketcan and, i cross compile can-utils for my craneboard
> card (a card with CAN).
> When i run cangen with 1 ms period, the period is not respected (1,407, 1.399,
> ...) !
>
> How can i fix this problem ?
>
> my can version in /proc/net/can/version is "rev 20090105 abi 8" and i'm on
> : Linux am3517-crane 2.6.32 #1 Mon Apr 23 00:13:28 CEST 2012 armv7l GNU/Linux
>

Hello Mohamed,

first please move to the new CAN mailing list (see CC) - and don't use 
HTML-mails (text-only is better) ;-)

Regarding your problem:

Usually i get smaller derivations on my system - but your Linux box is 
probably not very fast, so that you can see these scheduling influences with 
cangen ...

cangen is a userpace app and therefore it is usually not that precise as 
hrtimers inside the Linux kernel (if you don't use any realtime Linux).

But you may try the Broadcast-Manager to place a 'cyclic sending job' inside 
the Linux kernel. See an example here:

http://svn.berlios.de/wsvn/socketcan/trunk/test/tst-bcm-cycle.c

Regards,
Oliver

Re: [Socketcan-users] back to back can frames.

[Kurt Van Dijck]

Max,

(please switch using linux-can@vger.kernel.org, as Oliver suggested)

to answer your question, see below

On Thu, Jul 05, 2012 at 11:35:46AM +0000, Max S. wrote:
> Hello,
> 
> While trying to test a can device I wrote a short program to
> continuously send can frames... However after a short while I get a
> buffer overflow error. Seems the internal queue is filled and overrun...
> 
> How can I send can frames at maximum throughput? simply one after the
> other, back to back.
> 
> what i have now is something like this:
> 
> 
> do{
> 	//prepare next frame...
> }while(write( sfd, frame, sizeof(*arguments.frame) ) == sizeof(*frame));
> //print error message...

> 
> since the write simply pushes the frame into the queue, it is logical
> that the queue would fill up quickly and get overflown?overrun?full.

my core loop would look like this:

	int ret;
	while (1) {
		ret = write(sfd, frame, sizeof(*frame));
		if ((ret < 0) && (errno == ENOBUFS)) {
			usleep(1000);
		} else
			break;
	}
	if (ret < 0)
		/* print error message */

> 
> Thanks,
> Max S.
> 
> _______________________________________________
> Socketcan-users mailing list
> Socketcan-users@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/socketcan-users

-- 
Kurt Van Dijck
GRAMMER EiA ELECTRONICS
http://www.eia.be
kurt.van.dijck@eia.be
+32-38708534

Re: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

Hi,

I recompiled the Kernel with activate preemption. I test cangen and
tst-bcm-cycle but i have the same result around accuracy. I tried to
change the application priority with nice command to high priority but
the problem persist  !

Regards,
Mohamed

Le jeudi 5 juillet 2012, Oliver Hartkopp a écrit :
>
> On 05.07.2012 10:12, Mohamed HAMZAOUI wrote:
>>
>> Hi,
>>
>> i'm a new user of socketcan and, i cross compile can-utils for my craneboard
>> card (a card with CAN).
>> When i run cangen with 1 ms period, the period is not respected (1,407, 1.399,
>> ...) !
>>
>> How can i fix this problem ?
>>
>> my can version in /proc/net/can/version is "rev 20090105 abi 8" and i'm on
>> : Linux am3517-crane 2.6.32 #1 Mon Apr 23 00:13:28 CEST 2012 armv7l GNU/Linux
>>
>
> Hello Mohamed,
>
> first please move to the new CAN mailing list (see CC) - and don't use HTML-mails (text-only is better) ;-)
>
> Regarding your problem:
>
> Usually i get smaller derivations on my system - but your Linux box is probably not very fast, so that you can see these scheduling influences with cangen ...
>
> cangen is a userpace app and therefore it is usually not that precise as hrtimers inside the Linux kernel (if you don't use any realtime Linux).
>
> But you may try the Broadcast-Manager to place a 'cyclic sending job' inside the Linux kernel. See an example here:
>
> http://svn.berlios.de/wsvn/socketcan/trunk/test/tst-bcm-cycle.c
>
> Regards,
> Oliver

Re: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

On 07/07/2012 12:02 PM, Mohamed HAMZAOUI wrote:
> Hi,
> 
> I recompiled the Kernel with activate preemption. I test cangen and
> tst-bcm-cycle but i have the same result around accuracy. I tried to
> change the application priority with nice command to high priority but
> the problem persist  !

This problem is not CAN related. Anyway, you can read/try/check:

- are high-resolution timers enabled in your kernel?
- use cyclictest [1] to measure user-space timing accuracy.
- use clock_nanosleep for periodic tasks.
- try to start cangen with "chrt -f 10 cangen can0".
- read "man sched_setscheduler" for a description of the Linux
  scheduling scheme.

[1] https://rt.wiki.kernel.org/index.php/Cyclictest

Wolfgang.

> Le jeudi 5 juillet 2012, Oliver Hartkopp a écrit :
>>
>> On 05.07.2012 10:12, Mohamed HAMZAOUI wrote:
>>>
>>> Hi,
>>>
>>> i'm a new user of socketcan and, i cross compile can-utils for my craneboard
>>> card (a card with CAN).
>>> When i run cangen with 1 ms period, the period is not respected (1,407, 1.399,
>>> ...) !
>>>
>>> How can i fix this problem ?
>>>
>>> my can version in /proc/net/can/version is "rev 20090105 abi 8" and i'm on
>>> : Linux am3517-crane 2.6.32 #1 Mon Apr 23 00:13:28 CEST 2012 armv7l GNU/Linux
>>>
>>
>> Hello Mohamed,
>>
>> first please move to the new CAN mailing list (see CC) - and don't use HTML-mails (text-only is better) ;-)
>>
>> Regarding your problem:
>>
>> Usually i get smaller derivations on my system - but your Linux box is probably not very fast, so that you can see these scheduling influences with cangen ...
>>
>> cangen is a userpace app and therefore it is usually not that precise as hrtimers inside the Linux kernel (if you don't use any realtime Linux).
>>
>> But you may try the Broadcast-Manager to place a 'cyclic sending job' inside the Linux kernel. See an example here:
>>
>> http://svn.berlios.de/wsvn/socketcan/trunk/test/tst-bcm-cycle.c
>>
>> 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
> 
> 

Re: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

Hi,

> This problem is not CAN related. Anyway, you can read/try/check:
>
> - are high-resolution timers enabled in your kernel?

My high resolution timers is enabled in Kernel and i activate
Preemptible kernel (low latency desktop)

> - use cyclictest [1] to measure user-space timing accuracy.

the cyclictest mesure with 0% load is 307 in maximum

> - use clock_nanosleep for periodic tasks.

i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
with another CAN transeiver is an average of 1.30 ms (delta = 300 µs)
!

> - try to start cangen with "chrt -f 10 cangen can0".

no effect.

> - read "man sched_setscheduler" for a description of the Linux
>   scheduling scheme.

I test with two type of SCHED : RR and FIFO but the result is same

Maybe i need to pass to Xenomai or PREEMPT-RT ?

Your advise are welcome

Regards,
Mohamed

Re: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

On 07/08/2012 09:43 PM, Mohamed HAMZAOUI wrote:
> Hi,
> 
>> This problem is not CAN related. Anyway, you can read/try/check:
>>
>> - are high-resolution timers enabled in your kernel?
> 
> My high resolution timers is enabled in Kernel and i activate
> Preemptible kernel (low latency desktop)
> 
>> - use cyclictest [1] to measure user-space timing accuracy.
> 
> the cyclictest mesure with 0% load is 307 in maximum

You mean 302 us? Did you generate some load? That normally makes a big
difference.

> 
>> - use clock_nanosleep for periodic tasks.
> 
> i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
> with another CAN transeiver is an average of 1.30 ms (delta = 300 µs)
> !

That means that you see a period of 1.3ms instead of 1ms? That's really
strange. I assume that the timing on the system with the other CAN
transceiver is accurate.

>> - try to start cangen with "chrt -f 10 cangen can0".
> 
> no effect.
> 
>> - read "man sched_setscheduler" for a description of the Linux
>>   scheduling scheme.
> 
> I test with two type of SCHED : RR and FIFO but the result is same
> 
> Maybe i need to pass to Xenomai or PREEMPT-RT ?

What system, kernel and CAN controller do you use? Is it an MCP25xx?

Wolfgang.

Re: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

The other transeiver is a KVASER USBCan II (HS,HS) it's an usb gateway
CAN and it's accurate because i use it with other CAN transeiver
(IXXAT PCI or Vector CanboardXL) and i have always the same result.

My board is Craneboard "AM3517-crane" and i compiled my system with
OpenEmbedded which done : (cat /proc/version) Linux version 2.6.32
(requinham@pearl) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1
PREEMPT Fri Jul 6 21:46:07 CEST 2012

My CAN Controller is the TI CAN controller provide with the
microcontroller TI Cortex A8 (cat /proc/net/can/version) rev 20090105
abi 8

Regards,
Mohamed

On Sun, Jul 8, 2012 at 10:13 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> On 07/08/2012 09:43 PM, Mohamed HAMZAOUI wrote:
>> Hi,
>>
>>> This problem is not CAN related. Anyway, you can read/try/check:
>>>
>>> - are high-resolution timers enabled in your kernel?
>>
>> My high resolution timers is enabled in Kernel and i activate
>> Preemptible kernel (low latency desktop)
>>
>>> - use cyclictest [1] to measure user-space timing accuracy.
>>
>> the cyclictest mesure with 0% load is 307 in maximum
>
> You mean 302 us? Did you generate some load? That normally makes a big
> difference.
>
>>
>>> - use clock_nanosleep for periodic tasks.
>>
>> i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
>> with another CAN transeiver is an average of 1.30 ms (delta = 300 盜)
>> !
>
> That means that you see a period of 1.3ms instead of 1ms? That's really
> strange. I assume that the timing on the system with the other CAN
> transceiver is accurate.
>
>>> - try to start cangen with "chrt -f 10 cangen can0".
>>
>> no effect.
>>
>>> - read "man sched_setscheduler" for a description of the Linux
>>>   scheduling scheme.
>>
>> I test with two type of SCHED : RR and FIFO but the result is same
>>
>> Maybe i need to pass to Xenomai or PREEMPT-RT ?
>
> What system, kernel and CAN controller do you use? Is it an MCP25xx?
>
> Wolfgang.
>

Re: [SocketCan] Problem of accuracy

[Kurt Van Dijck]

> > 
> >> - use clock_nanosleep for periodic tasks.
> > 
> > i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
> > with another CAN transeiver is an average of 1.30 ms (delta = 300 µs)
> > !
> 
> That means that you see a period of 1.3ms instead of 1ms? That's really
> strange. I assume that the timing on the system with the other CAN
> transceiver is accurate.

IMHO, the precise receiver side accuracy is less important.
For the sender, if each 1ms period becomes 1.3ms, the effective period
becomes 1.3ms.
On the receiver side, even if receive interrupts may introduce up to .3ms delays,
the effective (average) period does not change.

So on the receiver side, with a bit of averaging, you can easily
tell the effective period.

-- 
Kurt Van Dijck
GRAMMER EiA ELECTRONICS
http://www.eia.be
kurt.van.dijck@eia.be
+32-38708534

Re: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

On 07/08/2012 10:30 PM, Mohamed HAMZAOUI wrote:
> The other transeiver is a KVASER USBCan II (HS,HS) it's an usb gateway
> CAN and it's accurate because i use it with other CAN transeiver
> (IXXAT PCI or Vector CanboardXL) and i have always the same result.

Well, I would not use a USB CAN controller for accurate timing (if it
does not use hardware time stamps). Anyway, I think that's not the
problem, as Kurt already pointed out.

> My board is Craneboard "AM3517-crane" and i compiled my system with
> OpenEmbedded which done : (cat /proc/version) Linux version 2.6.32
> (requinham@pearl) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1
> PREEMPT Fri Jul 6 21:46:07 CEST 2012

OK, then you use the ti_hecc driver, which hit mainline in 2.6.33! Could
you show as the source of your "drivers/net/can/ti_hecc.c"? There is at
least one issue in the early driver version, which makes sense to fix:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e3f240f460a36b158217944b52a85f304914c1a6

If that doesn't help, you should use ftrace to understand what's going
on. Well, not sure if ftrace already works with 2.6.32 on ARM... that
would be another good reason to update to a more recent version of the
kernel. Would that be an option for you?

Wolfgang.

> On Sun, Jul 8, 2012 at 10:13 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> On 07/08/2012 09:43 PM, Mohamed HAMZAOUI wrote:
>>> Hi,
>>>
>>>> This problem is not CAN related. Anyway, you can read/try/check:
>>>>
>>>> - are high-resolution timers enabled in your kernel?
>>>
>>> My high resolution timers is enabled in Kernel and i activate
>>> Preemptible kernel (low latency desktop)
>>>
>>>> - use cyclictest [1] to measure user-space timing accuracy.
>>>
>>> the cyclictest mesure with 0% load is 307 in maximum
>>
>> You mean 302 us? Did you generate some load? That normally makes a big
>> difference.
>>
>>>
>>>> - use clock_nanosleep for periodic tasks.
>>>
>>> i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
>>> with another CAN transeiver is an average of 1.30 ms (delta = 300 盜)
>>> !
>>
>> That means that you see a period of 1.3ms instead of 1ms? That's really
>> strange. I assume that the timing on the system with the other CAN
>> transceiver is accurate.
>>
>>>> - try to start cangen with "chrt -f 10 cangen can0".
>>>
>>> no effect.
>>>
>>>> - read "man sched_setscheduler" for a description of the Linux
>>>>   scheduling scheme.
>>>
>>> I test with two type of SCHED : RR and FIFO but the result is same
>>>
>>> Maybe i need to pass to Xenomai or PREEMPT-RT ?
>>
>> What system, kernel and CAN controller do you use? Is it an MCP25xx?
>>
>> Wolfgang.
>>
> --
> 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: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

I cannot use the 2.6.33 kernel version because it's not support my
board and, until this moment only, the kernel version 2.6.32*  can be
found for my board for which i can not find any adeos patch or
preempt-rt patch.
I will test the patch for ti_hecc.c and i will return for you.
* (TI provide a 2.6.37 kernel version but with problem Kernel PANIC !)

Regards,
Mohamed

On Mon, Jul 9, 2012 at 9:18 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> On 07/08/2012 10:30 PM, Mohamed HAMZAOUI wrote:
>> The other transeiver is a KVASER USBCan II (HS,HS) it's an usb gateway
>> CAN and it's accurate because i use it with other CAN transeiver
>> (IXXAT PCI or Vector CanboardXL) and i have always the same result.
>
> Well, I would not use a USB CAN controller for accurate timing (if it
> does not use hardware time stamps). Anyway, I think that's not the
> problem, as Kurt already pointed out.
>
>> My board is Craneboard "AM3517-crane" and i compiled my system with
>> OpenEmbedded which done : (cat /proc/version) Linux version 2.6.32
>> (requinham@pearl) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1
>> PREEMPT Fri Jul 6 21:46:07 CEST 2012
>
> OK, then you use the ti_hecc driver, which hit mainline in 2.6.33! Could
> you show as the source of your "drivers/net/can/ti_hecc.c"? There is at
> least one issue in the early driver version, which makes sense to fix:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e3f240f460a36b158217944b52a85f304914c1a6
>
> If that doesn't help, you should use ftrace to understand what's going
> on. Well, not sure if ftrace already works with 2.6.32 on ARM... that
> would be another good reason to update to a more recent version of the
> kernel. Would that be an option for you?
>
> Wolfgang.
>
>> On Sun, Jul 8, 2012 at 10:13 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> On 07/08/2012 09:43 PM, Mohamed HAMZAOUI wrote:
>>>> Hi,
>>>>
>>>>> This problem is not CAN related. Anyway, you can read/try/check:
>>>>>
>>>>> - are high-resolution timers enabled in your kernel?
>>>>
>>>> My high resolution timers is enabled in Kernel and i activate
>>>> Preemptible kernel (low latency desktop)
>>>>
>>>>> - use cyclictest [1] to measure user-space timing accuracy.
>>>>
>>>> the cyclictest mesure with 0% load is 307 in maximum
>>>
>>> You mean 302 us? Did you generate some load? That normally makes a big
>>> difference.
>>>
>>>>
>>>>> - use clock_nanosleep for periodic tasks.
>>>>
>>>> i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
>>>> with another CAN transeiver is an average of 1.30 ms (delta = 300 盜)
>>>> !
>>>
>>> That means that you see a period of 1.3ms instead of 1ms? That's really
>>> strange. I assume that the timing on the system with the other CAN
>>> transceiver is accurate.
>>>
>>>>> - try to start cangen with "chrt -f 10 cangen can0".
>>>>
>>>> no effect.
>>>>
>>>>> - read "man sched_setscheduler" for a description of the Linux
>>>>>   scheduling scheme.
>>>>
>>>> I test with two type of SCHED : RR and FIFO but the result is same
>>>>
>>>> Maybe i need to pass to Xenomai or PREEMPT-RT ?
>>>
>>> What system, kernel and CAN controller do you use? Is it an MCP25xx?
>>>
>>> Wolfgang.
>>>
>> --
>> 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: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

On 07/09/2012 10:14 AM, Mohamed HAMZAOUI wrote:
> I cannot use the 2.6.33 kernel version because it's not support my
> board and, until this moment only, the kernel version 2.6.32*  can be
> found for my board for which i can not find any adeos patch or
> preempt-rt patch

I was thinking about Linux > 3.4. Anyway, I understand your problem.
Xenomai will not help without extra effort because there is no RT-CAN
driver for the TI HECC. What are your real-time requirements?

> I will test the patch for ti_hecc.c and i will return for you.
> * (TI provide a 2.6.37 kernel version but with problem Kernel PANIC !)

:(

Wolfgang.

> On Mon, Jul 9, 2012 at 9:18 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> On 07/08/2012 10:30 PM, Mohamed HAMZAOUI wrote:
>>> The other transeiver is a KVASER USBCan II (HS,HS) it's an usb gateway
>>> CAN and it's accurate because i use it with other CAN transeiver
>>> (IXXAT PCI or Vector CanboardXL) and i have always the same result.
>>
>> Well, I would not use a USB CAN controller for accurate timing (if it
>> does not use hardware time stamps). Anyway, I think that's not the
>> problem, as Kurt already pointed out.
>>
>>> My board is Craneboard "AM3517-crane" and i compiled my system with
>>> OpenEmbedded which done : (cat /proc/version) Linux version 2.6.32
>>> (requinham@pearl) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1
>>> PREEMPT Fri Jul 6 21:46:07 CEST 2012
>>
>> OK, then you use the ti_hecc driver, which hit mainline in 2.6.33! Could
>> you show as the source of your "drivers/net/can/ti_hecc.c"? There is at
>> least one issue in the early driver version, which makes sense to fix:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e3f240f460a36b158217944b52a85f304914c1a6
>>
>> If that doesn't help, you should use ftrace to understand what's going
>> on. Well, not sure if ftrace already works with 2.6.32 on ARM... that
>> would be another good reason to update to a more recent version of the
>> kernel. Would that be an option for you?
>>
>> Wolfgang.
>>
>>> On Sun, Jul 8, 2012 at 10:13 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>>> On 07/08/2012 09:43 PM, Mohamed HAMZAOUI wrote:
>>>>> Hi,
>>>>>
>>>>>> This problem is not CAN related. Anyway, you can read/try/check:
>>>>>>
>>>>>> - are high-resolution timers enabled in your kernel?
>>>>>
>>>>> My high resolution timers is enabled in Kernel and i activate
>>>>> Preemptible kernel (low latency desktop)
>>>>>
>>>>>> - use cyclictest [1] to measure user-space timing accuracy.
>>>>>
>>>>> the cyclictest mesure with 0% load is 307 in maximum
>>>>
>>>> You mean 302 us? Did you generate some load? That normally makes a big
>>>> difference.
>>>>
>>>>>
>>>>>> - use clock_nanosleep for periodic tasks.
>>>>>
>>>>> i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
>>>>> with another CAN transeiver is an average of 1.30 ms (delta = 300 盜)
>>>>> !
>>>>
>>>> That means that you see a period of 1.3ms instead of 1ms? That's really
>>>> strange. I assume that the timing on the system with the other CAN
>>>> transceiver is accurate.
>>>>
>>>>>> - try to start cangen with "chrt -f 10 cangen can0".
>>>>>
>>>>> no effect.
>>>>>
>>>>>> - read "man sched_setscheduler" for a description of the Linux
>>>>>>   scheduling scheme.
>>>>>
>>>>> I test with two type of SCHED : RR and FIFO but the result is same
>>>>>
>>>>> Maybe i need to pass to Xenomai or PREEMPT-RT ?
>>>>
>>>> What system, kernel and CAN controller do you use? Is it an MCP25xx?
>>>>
>>>> Wolfgang.
>>>>
>>> --
>>> 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: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

My real-time requirement is minimum to be accurate on 1ms for manage
deterministic CAN protocol (like MILCAN).

On Mon, Jul 9, 2012 at 10:20 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> On 07/09/2012 10:14 AM, Mohamed HAMZAOUI wrote:
>> I cannot use the 2.6.33 kernel version because it's not support my
>> board and, until this moment only, the kernel version 2.6.32*  can be
>> found for my board for which i can not find any adeos patch or
>> preempt-rt patch
>
> I was thinking about Linux > 3.4. Anyway, I understand your problem.
> Xenomai will not help without extra effort because there is no RT-CAN
> driver for the TI HECC. What are your real-time requirements?
>
>> I will test the patch for ti_hecc.c and i will return for you.
>> * (TI provide a 2.6.37 kernel version but with problem Kernel PANIC !)
>
> :(
>
> Wolfgang.
>
>> On Mon, Jul 9, 2012 at 9:18 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> On 07/08/2012 10:30 PM, Mohamed HAMZAOUI wrote:
>>>> The other transeiver is a KVASER USBCan II (HS,HS) it's an usb gateway
>>>> CAN and it's accurate because i use it with other CAN transeiver
>>>> (IXXAT PCI or Vector CanboardXL) and i have always the same result.
>>>
>>> Well, I would not use a USB CAN controller for accurate timing (if it
>>> does not use hardware time stamps). Anyway, I think that's not the
>>> problem, as Kurt already pointed out.
>>>
>>>> My board is Craneboard "AM3517-crane" and i compiled my system with
>>>> OpenEmbedded which done : (cat /proc/version) Linux version 2.6.32
>>>> (requinham@pearl) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1
>>>> PREEMPT Fri Jul 6 21:46:07 CEST 2012
>>>
>>> OK, then you use the ti_hecc driver, which hit mainline in 2.6.33! Could
>>> you show as the source of your "drivers/net/can/ti_hecc.c"? There is at
>>> least one issue in the early driver version, which makes sense to fix:
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e3f240f460a36b158217944b52a85f304914c1a6
>>>
>>> If that doesn't help, you should use ftrace to understand what's going
>>> on. Well, not sure if ftrace already works with 2.6.32 on ARM... that
>>> would be another good reason to update to a more recent version of the
>>> kernel. Would that be an option for you?
>>>
>>> Wolfgang.
>>>
>>>> On Sun, Jul 8, 2012 at 10:13 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>>>> On 07/08/2012 09:43 PM, Mohamed HAMZAOUI wrote:
>>>>>> Hi,
>>>>>>
>>>>>>> This problem is not CAN related. Anyway, you can read/try/check:
>>>>>>>
>>>>>>> - are high-resolution timers enabled in your kernel?
>>>>>>
>>>>>> My high resolution timers is enabled in Kernel and i activate
>>>>>> Preemptible kernel (low latency desktop)
>>>>>>
>>>>>>> - use cyclictest [1] to measure user-space timing accuracy.
>>>>>>
>>>>>> the cyclictest mesure with 0% load is 307 in maximum
>>>>>
>>>>> You mean 302 us? Did you generate some load? That normally makes a big
>>>>> difference.
>>>>>
>>>>>>
>>>>>>> - use clock_nanosleep for periodic tasks.
>>>>>>
>>>>>> i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
>>>>>> with another CAN transeiver is an average of 1.30 ms (delta = 300 盜)
>>>>>> !
>>>>>
>>>>> That means that you see a period of 1.3ms instead of 1ms? That's really
>>>>> strange. I assume that the timing on the system with the other CAN
>>>>> transceiver is accurate.
>>>>>
>>>>>>> - try to start cangen with "chrt -f 10 cangen can0".
>>>>>>
>>>>>> no effect.
>>>>>>
>>>>>>> - read "man sched_setscheduler" for a description of the Linux
>>>>>>>   scheduling scheme.
>>>>>>
>>>>>> I test with two type of SCHED : RR and FIFO but the result is same
>>>>>>
>>>>>> Maybe i need to pass to Xenomai or PREEMPT-RT ?
>>>>>
>>>>> What system, kernel and CAN controller do you use? Is it an MCP25xx?
>>>>>
>>>>> Wolfgang.
>>>>>
>>>> --
>>>> 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: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

On 07/09/2012 11:19 AM, Mohamed HAMZAOUI wrote:
> My real-time requirement is minimum to be accurate on 1ms for manage
> deterministic CAN protocol (like MILCAN).

Well, what jitter would be acceptable for a period of 1ms?

BTW: what happens if you use a period of 0.7 ms. Do you then see a
period of 1ms on the bus?

Wolfgang.

Fwd: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

I think that is caused by Socketcan. Maybe, the nannosecond sleep is
correct but when the system call write on a CAN socket it takes 0.3 ms
to inject the data on the bus

|_______________________________|_____________|
nannosleep        1000µs                  call        300µs    real sending time

It's this possible and if this is true can i assume a fix 0.3 ms in
all my period ?

Regards
Mohamed

On Mon, Jul 9, 2012 at 12:21 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> On 07/09/2012 11:54 AM, Mohamed HAMZAOUI wrote:
>> Jitter : +- 10盜 (1% of the period)
>
> That's *not* achievable with the hardware you us! Neither with
> preempt-rt nor with Xenomai.
>
>> I test with 700000 ns 0.7ms and i have 1ms of period but I think it's
>> not usually true because it's probably depend of the CPU load !
>
> Wired, don't know where the 300us get lost systematically.
>
> Wolfgang

Re: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

Please do not drop the CC to the Linux-CAN mailing list...

On 07/09/2012 01:25 PM, Mohamed HAMZAOUI wrote:
> I think that is caused by Socketcan. Maybe, the nannosecond sleep is
> correct but when the system call write on a CAN socket it takes 0.3 ms
> to inject the data on the bus
> 
> |_______________________________|_____________|
> nannosleep        1000µs                  call        300µs    real sending time
> 
> It's this possible and if this is true can i assume a fix 0.3 ms in
> all my period ?

Even if it takes 0.3ms to get the message out to the bus, it should not
change the period if you program clock_nanosleep() properly (waiting on
the next 1ms period).

Wolfgang.

Re: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

If i have understood you correctly, I think it must change the period
if the write function is a synchronous call !
if my function is like this :

while(1)
{
    nannosleep(1000000);
    write (myFrame in opened CAN socket);
}

then the result is 1ms + timeOf (write) for every iteration.
but if the write call is asynchronous we return to case you mentioned !

Is this correct ?

On Mon, Jul 9, 2012 at 1:40 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Please do not drop the CC to the Linux-CAN mailing list...
>
> On 07/09/2012 01:25 PM, Mohamed HAMZAOUI wrote:
>> I think that is caused by Socketcan. Maybe, the nannosecond sleep is
>> correct but when the system call write on a CAN socket it takes 0.3 ms
>> to inject the data on the bus
>>
>> |_______________________________|_____________|
>> nannosleep        1000盜                  call        300盜    real sending time
>>
>> It's this possible and if this is true can i assume a fix 0.3 ms in
>> all my period ?
>
> Even if it takes 0.3ms to get the message out to the bus, it should not
> change the period if you program clock_nanosleep() properly (waiting on
> the next 1ms period).
>
> Wolfgang.

Re: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

On 07/09/2012 01:57 PM, Mohamed HAMZAOUI wrote:
> If i have understood you correctly, I think it must change the period
> if the write function is a synchronous call !
> if my function is like this :
> 
> while(1)
> {
>     nannosleep(1000000);
>     write (myFrame in opened CAN socket);
> }
> 
> then the result is 1ms + timeOf (write) for every iteration.

Yep.

> but if the write call is asynchronous we return to case you mentioned !

The write call is asynchronous and I'm surprised that it takes 300us to
return. Could you show us your test program?

> Is this correct ?

Anyway, in a previous mail you wrote:

> i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
> with another CAN transeiver is an average of 1.30 ms (delta = 300 µs)
> !

You cannot expect precises timing with nanosloeep(). Have a look to
cyclictest.c to understand how to implement a periodic task.

Wolfgang.

Re: [SocketCan] Problem of accuracy

[Pavel Pisa]

Hello Mohamed,

On Monday 09 July 2012 13:57:11 Mohamed HAMZAOUI wrote:
> If i have understood you correctly, I think it must change the period
> if the write function is a synchronous call !
> if my function is like this :
>
> while(1)
> {
>     nannosleep(1000000);
>     write (myFrame in opened CAN socket);
> }

You should use some loop which compensates for time spent
in the loop workload. One solution is to use costruct
bellow

#include <time.h>

const struct timespec period = {/*seconds*/, /*nanoseconds*/};
struct timespec time_to_wait;
clock_gettime(CLOCK_MONOTONIC,&time_to_wait);

while(!Finished)
{
  do_work();
  
  timespec_add(&time_to_wait,&time_to_wait,&period);
  clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &time_to_wait,NULL);
}

and link with librt (i.e. -lrt). You can take timespec_add()
and timespec_sub() sources from our Computers for Control course page

http://support.dce.felk.cvut.cz/pos/hlavni_uloha/timespec_routines.h

The solution can result in infinite/busy loop if the work activity
is longer than period. There should be some check for that situation
and skip of some sampling intervals or error reporting and switching
to emergency/safe stop mode.

Best wishes,

                Pavel

Re: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

My loop code is there :

 /*change the scheduler politic for this process */
    err = sched_setscheduler(0, SCHED_FIFO, &p);
    if (err)
          fprintf(stderr, "ret %d\n", err);
       ...
       ...

i open the socket and :

 while (i < loop_nbr)
 {
        /* send frame */
        if ((nbytes = write(s, &frame, sizeof(frame))) != sizeof(frame)) {
                perror("write frame on bus");
                return 1;
        }
        /* go to sleep */
        clock_nanosleep(CLOCK_REALTIME, 0,
                                   &ts,
                                   NULL);
        i++;
}


On Mon, Jul 9, 2012 at 3:19 PM, Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote:
> Hello Mohamed,
>
> On Monday 09 July 2012 13:57:11 Mohamed HAMZAOUI wrote:
>> If i have understood you correctly, I think it must change the period
>> if the write function is a synchronous call !
>> if my function is like this :
>>
>> while(1)
>> {
>>     nannosleep(1000000);
>>     write (myFrame in opened CAN socket);
>> }
>
> You should use some loop which compensates for time spent
> in the loop workload. One solution is to use costruct
> bellow
>
> #include <time.h>
>
> const struct timespec period = {/*seconds*/, /*nanoseconds*/};
> struct timespec time_to_wait;
> clock_gettime(CLOCK_MONOTONIC,&time_to_wait);
>
> while(!Finished)
> {
>   do_work();
>
>   timespec_add(&time_to_wait,&time_to_wait,&period);
>   clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &time_to_wait,NULL);
> }
>
> and link with librt (i.e. -lrt). You can take timespec_add()
> and timespec_sub() sources from our Computers for Control course page
>
> http://support.dce.felk.cvut.cz/pos/hlavni_uloha/timespec_routines.h
>
> The solution can result in infinite/busy loop if the work activity
> is longer than period. There should be some check for that situation
> and skip of some sampling intervals or error reporting and switching
> to emergency/safe stop mode.
>
> Best wishes,
>
>                 Pavel
>

Re: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

Sorry but I don't understand your approach. This approach can increase
the delta, no ?

On Mon, Jul 9, 2012 at 3:19 PM, Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote:
> Hello Mohamed,
>
> On Monday 09 July 2012 13:57:11 Mohamed HAMZAOUI wrote:
>> If i have understood you correctly, I think it must change the period
>> if the write function is a synchronous call !
>> if my function is like this :
>>
>> while(1)
>> {
>>     nannosleep(1000000);
>>     write (myFrame in opened CAN socket);
>> }
>
> You should use some loop which compensates for time spent
> in the loop workload. One solution is to use costruct
> bellow
>
> #include <time.h>
>
> const struct timespec period = {/*seconds*/, /*nanoseconds*/};
> struct timespec time_to_wait;
> clock_gettime(CLOCK_MONOTONIC,&time_to_wait);
>
> while(!Finished)
> {
>   do_work();
>
>   timespec_add(&time_to_wait,&time_to_wait,&period);
>   clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &time_to_wait,NULL);
> }
>
> and link with librt (i.e. -lrt). You can take timespec_add()
> and timespec_sub() sources from our Computers for Control course page
>
> http://support.dce.felk.cvut.cz/pos/hlavni_uloha/timespec_routines.h
>
> The solution can result in infinite/busy loop if the work activity
> is longer than period. There should be some check for that situation
> and skip of some sampling intervals or error reporting and switching
> to emergency/safe stop mode.
>
> Best wishes,
>
>                 Pavel
>

Re: [SocketCan] Problem of accuracy

[Kurt Van Dijck]

On Mon, Jul 09, 2012 at 03:19:04PM +0200, Pavel Pisa wrote:
> Hello Mohamed,
> 
> On Monday 09 July 2012 13:57:11 Mohamed HAMZAOUI wrote:
> > If i have understood you correctly, I think it must change the period
> > if the write function is a synchronous call !
> > if my function is like this :
> >
> > while(1)
> > {
> >     nannosleep(1000000);
> >     write (myFrame in opened CAN socket);
> > }
> 
> You should use some loop which compensates for time spent
> in the loop workload. One solution is to use costruct
> bellow
> 
> #include <time.h>
> 
> const struct timespec period = {/*seconds*/, /*nanoseconds*/};
> struct timespec time_to_wait;
> clock_gettime(CLOCK_MONOTONIC,&time_to_wait);
> 
> while(!Finished)
> {
>   do_work();
>   
>   timespec_add(&time_to_wait,&time_to_wait,&period);
>   clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &time_to_wait,NULL);
> }
> 

I tend to use itimer:
	#include <sys/time.h>

	int sigalrm;

	void hndalrm(int sig)
	{
		sigalrm = 1;
		signal(SIGALRM, hndalrm);
	}

	const struct itimerval itimer = {
		.it_interval = { /* seconds*/, /*useconds*/, },
		.it_value = { 0, 1, }, /* schedule first run quasi immediately */
	};

	main ()
	{
		signal(SIGALRM, hndalrm);

		setitimer(ITIMER_REAL, &itimer, NULL);

		while (1) {
			poll(NULL, 0, -1); /* wait indefinite until signal */
			write(...).
		}
	}

I just realised that this algorithm does not need measuring time spent,
it will automatically skip cycles, at the cost of having to deal with signal's.
I don't know if it is based on hrtimer in kernel too, I assume yes.


-- 
Kurt Van Dijck
GRAMMER EiA ELECTRONICS
http://www.eia.be
kurt.van.dijck@eia.be
+32-38708534

Re: [SocketCan] Problem of accuracy

[Alexander Stein]

Am Montag, 9. Juli 2012, 16:40:42 schrieb Kurt Van Dijck:
> I tend to use itimer:
> 	#include <sys/time.h>
> 
> 	int sigalrm;
> 
> 	void hndalrm(int sig)
> 	{
> 		sigalrm = 1;
> 		signal(SIGALRM, hndalrm);
> 	}
> 
> 	const struct itimerval itimer = {
> 		.it_interval = { /* seconds*/, /*useconds*/, },
> 		.it_value = { 0, 1, }, /* schedule first run quasi immediately */
> 	};
> 
> 	main ()
> 	{
> 		signal(SIGALRM, hndalrm);
> 
> 		setitimer(ITIMER_REAL, &itimer, NULL);
> 
> 		while (1) {
> 			poll(NULL, 0, -1); /* wait indefinite until signal */
> 			write(...).
> 		}
> 	}
>
> I just realised that this algorithm does not need measuring time spent,
> it will automatically skip cycles, at the cost of having to deal with
> signal's.
> I don't know if it is based on hrtimer in kernel too, I assume yes.

I compared itimer with clock_nanosleep on an ARM board and noticed the signal 
overhead of itimer is much bigger, resulting in a higher CPU usage, than 
clock_nanosleep upon hrtimer.
So I ended up using clock_nanosleep adding a constant to the last timeout.
itimer should also be based on hrtimer.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein

SYS TEC electronic GmbH
August-Bebel-Str. 29
D-07973 Greiz

Tel: +49-3661-6279-0, Fax: +49-3661-6279-99
eMail:    Alexander.Stein@systec-electronic.com
Internet: http://www.systec-electronic.com

Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Jena, HRB 205563

Re: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

> I compared itimer with clock_nanosleep on an ARM board and noticed the signal
> overhead of itimer is much bigger, resulting in a higher CPU usage, than
> clock_nanosleep upon hrtimer.
> So I ended up using clock_nanosleep adding a constant to the last timeout.

but my problem is that when i specify 1 ms of period i have 1.3ms and
the problem is how to eliminate the 0.3ms. If i substitute 0.3 ms from
all payload, what's the assurance that it does not change with CPU
load  change ?

Regards,
Mohamed

Re: [SocketCan] Problem of accuracy

[Oliver Hartkopp]

On 09.07.2012 17:39, Mohamed HAMZAOUI wrote:

>> I compared itimer with clock_nanosleep on an ARM board and noticed the signal
>> overhead of itimer is much bigger, resulting in a higher CPU usage, than
>> clock_nanosleep upon hrtimer.
>> So I ended up using clock_nanosleep adding a constant to the last timeout.
> 
> but my problem is that when i specify 1 ms of period i have 1.3ms and
> the problem is how to eliminate the 0.3ms. If i substitute 0.3 ms from
> all payload, what's the assurance that it does not change with CPU
> load  change ?
> 


Hello Mohamed,

have you ever tried your test with a virtual CAN interface?

http://lxr.linux.no/#linux+v3.4.4/Documentation/networking/can.txt#L606

#> modprobe vcan
#> ip link add dev vcan0 type vcan
#> ifconfig vcan0 up
#> cangen vcan0

gives on my second terminal somthing like this:

#> candump -td any
 (000.000000)  vcan0  595  [3] ED 26 C7
 (000.200149)  vcan0  105  [1] CF
 (000.200149)  vcan0  346  [8] F7 4F 39 1D AD F5 76 30
 (000.200184)  vcan0  1BC  [8] DC E8 0E 19 26 9C 7E 33
 (000.200142)  vcan0  685  [4] 52 9B 56 50
 (000.200147)  vcan0  446  [2] 5F FF
 (000.200149)  vcan0  208  [8] F5 42 36 0C 5E CD AD 4A
 (000.200141)  vcan0   8D  [2] 0F 22
 (000.200143)  vcan0  4D5  [8] 2E 87 7E 11 DA ED 43 61
 (000.200143)  vcan0  38E  [8] 67 AD 44 27 D4 1E B0 0B
(..)

cangen generates a frame every 200ms (see cangen -?) and 'candump -td any'
prints the delta timestamps. As cangen arms the timer after the frame has been
sent, the cycle is ~145 us away from the default of 200ms.


When using the in-kernel hrtimers by utilizing the broadcast manager (can_bcm)
with the tst-bcm-cycle test tool
(see http://svn.berlios.de/wsvn/socketcan/trunk/test/tst-bcm-cycle.c)

it looks like this:

#> candump -td any
 (000.000000)  vcan2   42  [8] EF BE AD DE EF BE AD DE
 (000.004206)  vcan2   42  [8] EF BE AD DE EF BE AD DE
 (000.500061)  vcan2   42  [8] EF BE AD DE EF BE AD DE
 (000.500068)  vcan2   42  [8] EF BE AD DE EF BE AD DE
 (000.500059)  vcan2   42  [8] EF BE AD DE EF BE AD DE
 (000.500057)  vcan2   42  [8] EF BE AD DE EF BE AD DE
 (000.500072)  vcan2   42  [8] EF BE AD DE EF BE AD DE
 (000.500062)  vcan2   42  [8] EF BE AD DE EF BE AD DE
 (000.500070)  vcan2   42  [8] EF BE AD DE EF BE AD DE
(..)

so with the bcm you have a delay of ~60us.

Here also the timer is armed after the frame is send with bcm_tx_op() see:
http://lxr.linux.no/#linux+v3.4.4/net/can/bcm.c#L356

Additionally the tasklet is invoked by the hrtimer in bcm_tx_timeout_handler()
some lines below.

But both of these offsets is are far away from your measurements.

Can you confirm these values with the virtual CAN interface on your system?
FYI my values have been picked on a core i7 M 640 @ 2.80GHz notebook ...

Regards,
Oliver

Re: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

On 07/09/2012 05:39 PM, Mohamed HAMZAOUI wrote:
>> I compared itimer with clock_nanosleep on an ARM board and noticed the signal
>> overhead of itimer is much bigger, resulting in a higher CPU usage, than
>> clock_nanosleep upon hrtimer.
>> So I ended up using clock_nanosleep adding a constant to the last timeout.
> 
> but my problem is that when i specify 1 ms of period i have 1.3ms and

So far, you did not specify 1 ms of period. You used a delay of 1 ms
(using nanosleep).

> the problem is how to eliminate the 0.3ms. If i substitute 0.3 ms from
> all payload, what's the assurance that it does not change with CPU
> load  change ?

To understand the real-time capabilities of your system run cyclictest
again, but this time with real system load and running for more than an
hour:

  # cyclictest -t1 -p80 -n -i1000

What do you achieve?

Modify your CAN test program using clock_nanosleep() handling the period
properly, e.g. as suggested by Pavel. Here is another example:


http://www.rts.uni-hannover.de/xenomai/lxr/source/examples/rtdm/profiles/can/rtcan_rtt.c#092

What do you get with such a program?

Still, the 300us for the asynchronous write is bogus. But maybe your
system is that slow.

Wolfgang.

Re: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

Hi,

i run cyclictest command like your description with system load at 90%
(i use stress command  stress -t 3600 -c 1 --io 2 --vm-bytes 256M) and
i have :
Min 0 Avg 158 Max 334

then i create a program with timer (set to zero for increasing to
maximum CPU load) who call periodically an empty function. This
program have a priority 99 set using sched_setscheduler(0, SCHED_RR,
&p);
when i call this program cyclictest freeze and display me after a
moment a very bigger value in Max, then i concluded that the OS
schedule correctly the process according to the priority order.

I will send you the result of the second test and the result of the
patch as soon as possible to advise me on the best solution.
I will measure the really period in sending frame with an oscilloscope
to have the exact value.

Thank you.

On Mon, Jul 9, 2012 at 10:50 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> On 07/09/2012 05:39 PM, Mohamed HAMZAOUI wrote:
>>> I compared itimer with clock_nanosleep on an ARM board and noticed the signal
>>> overhead of itimer is much bigger, resulting in a higher CPU usage, than
>>> clock_nanosleep upon hrtimer.
>>> So I ended up using clock_nanosleep adding a constant to the last timeout.
>>
>> but my problem is that when i specify 1 ms of period i have 1.3ms and
>
> So far, you did not specify 1 ms of period. You used a delay of 1 ms
> (using nanosleep).
>
>> the problem is how to eliminate the 0.3ms. If i substitute 0.3 ms from
>> all payload, what's the assurance that it does not change with CPU
>> load  change ?
>
> To understand the real-time capabilities of your system run cyclictest
> again, but this time with real system load and running for more than an
> hour:
>
>   # cyclictest -t1 -p80 -n -i1000
>
> What do you achieve?
>
> Modify your CAN test program using clock_nanosleep() handling the period
> properly, e.g. as suggested by Pavel. Here is another example:
>
>
> http://www.rts.uni-hannover.de/xenomai/lxr/source/examples/rtdm/profiles/can/rtcan_rtt.c#092
>
> What do you get with such a program?
>
> Still, the 300us for the asynchronous write is bogus. But maybe your
> system is that slow.
>
> Wolfgang.
>
>
>

Re: [SocketCan] Problem of accuracy

[Mohamed HAMZAOUI]

Hi,

I run the test and actually i have around 1ms (my specified period) ,
the jitter is up to 24 microseonds. it's better than using only
clock_nannosleep.

I think my preblem is solved but can I minimize the gitter and why
when i use only clock_nannosleep i have the 300 us ?

Regards,
Mohamed

On Wed, Jul 11, 2012 at 12:11 AM, Mohamed HAMZAOUI <requinham@gmail.com> wrote:
> Hi,
>
> i run cyclictest command like your description with system load at 90%
> (i use stress command  stress -t 3600 -c 1 --io 2 --vm-bytes 256M) and
> i have :
> Min 0 Avg 158 Max 334
>
> then i create a program with timer (set to zero for increasing to
> maximum CPU load) who call periodically an empty function. This
> program have a priority 99 set using sched_setscheduler(0, SCHED_RR,
> &p);
> when i call this program cyclictest freeze and display me after a
> moment a very bigger value in Max, then i concluded that the OS
> schedule correctly the process according to the priority order.
>
> I will send you the result of the second test and the result of the
> patch as soon as possible to advise me on the best solution.
> I will measure the really period in sending frame with an oscilloscope
> to have the exact value.
>
> Thank you.
>
> On Mon, Jul 9, 2012 at 10:50 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> On 07/09/2012 05:39 PM, Mohamed HAMZAOUI wrote:
>>>> I compared itimer with clock_nanosleep on an ARM board and noticed the signal
>>>> overhead of itimer is much bigger, resulting in a higher CPU usage, than
>>>> clock_nanosleep upon hrtimer.
>>>> So I ended up using clock_nanosleep adding a constant to the last timeout.
>>>
>>> but my problem is that when i specify 1 ms of period i have 1.3ms and
>>
>> So far, you did not specify 1 ms of period. You used a delay of 1 ms
>> (using nanosleep).
>>
>>> the problem is how to eliminate the 0.3ms. If i substitute 0.3 ms from
>>> all payload, what's the assurance that it does not change with CPU
>>> load  change ?
>>
>> To understand the real-time capabilities of your system run cyclictest
>> again, but this time with real system load and running for more than an
>> hour:
>>
>>   # cyclictest -t1 -p80 -n -i1000
>>
>> What do you achieve?
>>
>> Modify your CAN test program using clock_nanosleep() handling the period
>> properly, e.g. as suggested by Pavel. Here is another example:
>>
>>
>> http://www.rts.uni-hannover.de/xenomai/lxr/source/examples/rtdm/profiles/can/rtcan_rtt.c#092
>>
>> What do you get with such a program?
>>
>> Still, the 300us for the asynchronous write is bogus. But maybe your
>> system is that slow.
>>
>> Wolfgang.
>>
>>
>>

Re: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

On 07/11/2012 12:11 AM, Mohamed HAMZAOUI wrote:
> Hi,
> 
> i run cyclictest command like your description with system load at 90%
> (i use stress command  stress -t 3600 -c 1 --io 2 --vm-bytes 256M) and
> i have :
> Min 0 Avg 158 Max 334

Please create almost 100% load on all CPUs and run the test for a while
(at least an hour).

> then i create a program with timer (set to zero for increasing to
> maximum CPU load) who call periodically an empty function. This
> program have a priority 99 set using sched_setscheduler(0, SCHED_RR,
> &p);
> when i call this program cyclictest freeze and display me after a
> moment a very bigger value in Max, then i concluded that the OS
> schedule correctly the process according to the priority order.

The programm does block cyclictest becase it does have a higher
priority. That's pretty normal.

Wolfgang

Re: [SocketCan] Problem of accuracy

[Wolfgang Grandegger]

On 07/11/2012 02:35 PM, Mohamed HAMZAOUI wrote:
> Hi,
> 
> I run the test and actually i have around 1ms (my specified period) ,

Sounds better.

> the jitter is up to 24 microseonds. it's better than using only
> clock_nannosleep.

With or without load?

> I think my preblem is solved but can I minimize the gitter and why
> when i use only clock_nannosleep i have the 300 us ?

The jitter above is far to good for Linux without preempt-rt. Try with
more load and a longer run time.

Wolfgang.