Re: [SocketCan] Problem of accuracy

[Oliver Hartkopp <socketcan@hartkopp.net>]

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