Re: [Xenomai-help] Re: Latencies due to RT-Socket-CAN register accesses

[Wolfgang Grandegger <wg@domain.hid>]

Roland Tollenaar wrote:
> Hi Wolfgang,
> 
> Typically without load the average latecny is 30 us and 20 us min 
> latency. Yes I am using the latency program of the test suit.
> 
> Where do I check to find the latency "killer" settings? The 
> powermanagement and all that s switched of. As is the PC speaker. What 
> else can I look at?

Here is what I get on a much slower PC (Athlon 1.1 GHz):
[root@domain.hid bin]# ./latency -p500
    RTT|  00:00:01  (periodic user-mode task, 500 us period, priority 99)
    RTH|-----lat min|-----lat avg|-----lat max|-overrun|
    ---|------------|------------|------------|--------|
    RTS|       1.309|       1.988|      10.723|       0|

Could you show us your .config file as Stephane ask for and the output 
of /proc/cpuinfo. Unfortunately, I have little experience with PC 
hardware and it's bad impact on the latency.

Wolfgang.


> Wolfgang Grandegger wrote:
>> Roland Tollenaar wrote:
>>> Hi Wolfgang,
>>>
>>> I think that this kind of latency should be fine for controller 
>>> intervals of 1ms.
>>>
>>> Another question:
>>> The PC has a 3Ghz processor and an 800Mhz FSB. That should not class 
>>> as "slow" in the conventional sense. What hardware is responsible for 
>>> the latency i.e. makes the PC "slow" from the RT perspective? In 
>>> other words what must one look at when purchasing a machine that 
>>> should give minimal latency?
>>
>> I ment "slow" in the sense of little CPU power, but that's obviously 
>> not the case. How have you measured these figures? With the "latency" 
>> program from the test suite? What is the min latency _without_ load? 
>> And also check Xenomai's TROUBLESHOOTING file. Already changing the 
>> kernel configuration to avoid latency "killers" might help.
>>
>> Wolfgang.
>>
>>> Regards,
>>>
>>> Roland.
>>>
>>>
>>> Wolfgang Grandegger wrote:
>>>> roland Tollenaar wrote:
>>>>> Hi Wolfgang,
>>>>>
>>>>> Just to answer an open question still
>>>>>
>>>>>> > BTW, what are the latencies you measure on your system under load
>>>>>> > (without RT-Socket-CAN).
>>>>>
>>>>> lat min 20.952
>>>>> lat ave 31.009
>>>>> lat max 60.504
>>>>> lat best 19.276
>>>>>
>>>>> this was with the loading as you described in this thread and running
>>>>> for 12 hours.
>>>>>
>>>>> Anything special about the above figures? Not very good I presume but
>>>>> I am not running with tsc enabled.
>>>>
>>>> The latencies depend a lot on the hardware. The minimal latency of 
>>>> 20 us indicates, that you have a rather slow system. Then a maximum 
>>>> of 60 us is reasonable. Note that worst case latencies of better 
>>>> than 20us are difficult to achieve, even with high end PCs.
>>>>
>>>> Wolfgang.
>>>>
>>>>> Kind regards,
>>>>>
>>>>> Roland
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Roland
>>>>>>
>>>>>>
>>>>>> >
>>>>>> > Wolfgang.
>>>>>> >
>>>>>> >> Thanks,
>>>>>> >>
>>>>>> >> Roland
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> Wolfgang Grandegger wrote:
>>>>>> >>> Hallo,
>>>>>> >>>
>>>>>> >>> in the meantime I have measured the latencies introduced through
>>>>>> >>> messages sent and received by RT-Socket-CAN. The SJA1000 register
>>>>>> >>> access times on my rather old PC with an Athlon 1100 Mhz are:
>>>>>> >>>
>>>>>> >>> PEAK-Dongle: read  access: 11807 ns
>>>>>> >>> PEAK-Dongle: write access: 11677 ns
>>>>>> >>>
>>>>>> >>> IXXAT-PCI  : read  access:   729 ns
>>>>>> >>> IXXAT-PCI  : write access:   305 ns
>>>>>> >>>
>>>>>> >>> I measured an increase of the latency of approx. 170us with the
>>>>>> >>> PEAK-Dongle and approx 13us with the IXXAT-PCI card for the 
>>>>>> reception
>>>>>> >>> of a full CAN message (with 8 bytes payload). Sending messages 
>>>>>> is a
>>>>>> >>> bit less disturbing. I have attached a small patch to measure the
>>>>>> >>> SJA1000 register access times when the driver is initialized. 
>>>>>> You are
>>>>>> >>> welcome to apply it on your setup and report the results. I'm
>>>>>> >>> especially interested in numbers for the ISA bus (or PC-104).
>>>>>> >>>
>>>>>> >>> Wolfgang.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> 
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>> >>>
>>>>>> >>> + diff -u xenomai/ksrc/drivers/can/rtcan_dev.c.IOTEST
>>>>>> >>> xenomai/ksrc/drivers/can/rtcan_dev.c
>>>>>> >>> + diff -u xenomai/ksrc/drivers/can/sja1000/rtcan_sja1000.c.IOTEST
>>>>>> >>> xenomai/ksrc/drivers/can/sja1000/rtcan_sja1000.c
>>>>>> >>> --- xenomai/ksrc/drivers/can/sja1000/rtcan_sja1000.c.IOTEST
>>>>>> >>> 2007-02-26 09:17:27.000000000 +0100
>>>>>> >>> +++ xenomai/ksrc/drivers/can/sja1000/rtcan_sja1000.c    
>>>>>> 2007-03-13
>>>>>> >>> 10:01:47.000000000 +0100
>>>>>> >>> @@ -728,6 +728,30 @@
>>>>>> >>>      if (chip == NULL)
>>>>>> >>>      return -EINVAL;
>>>>>> >>>
>>>>>> >>> +#if 1
>>>>>> >>> +    {
>>>>>> >>> +    nanosecs_abs_t begin, diff;
>>>>>> >>> +    volatile u8 reg;
>>>>>> >>> +    int i, count = 100000;
>>>>>> >>> +    begin = rtdm_clock_read();
>>>>>> >>> +    for (i = 0; i < count; i++) {
>>>>>> >>> +        reg = chip->read_reg(dev, 0);
>>>>>> >>> +    }
>>>>>> >>> +    diff = rtdm_clock_read() - begin;
>>>>>> >>> +    printk("%s: register read time for %d accessed: %ld (%ld per
>>>>>> >>> access)\n",
>>>>>> >>> +           dev->board_name, count,
>>>>>> >>> +           (unsigned long)diff, (unsigned long)diff / count);
>>>>>> >>> +    begin = rtdm_clock_read();
>>>>>> >>> +    for (i = 0; i < count; i++) {
>>>>>> >>> +        chip->write_reg(dev, 0, reg);
>>>>>> >>> +    }
>>>>>> >>> +    diff = rtdm_clock_read() - begin;
>>>>>> >>> +    printk("%s: register write time for %d accessed: %ld (%ld 
>>>>>> per
>>>>>> >>> access)\n",
>>>>>> >>> +           dev->board_name, count,
>>>>>> >>> +           (unsigned long)diff, (unsigned long)diff / count);
>>>>>> >>> +    }
>>>>>> >>> +#endif
>>>>>> >>> +
>>>>>> >>>      /* Set dummy state for following call */
>>>>>> >>>      dev->state = CAN_STATE_ACTIVE;
>>>>>> >>>      /* Enter reset mode */
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xenomai-help mailing list
>>>>>> Xenomai-help@domain.hid
>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
>