[Xenomai-core] Clock drift.

[Xenomai-core] Clock drift.

[Gilles Chanteperdrix]

Hi,

I run clocktest on a system here, not running NTP, using
CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
this happen? Does it come from the error due to the multiply and shift
used for tsc to/from ns conversions ?

TIA,

-- 
                                                 Gilles.

Re: [Xenomai-core] Clock drift.

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Hi,
> 
> I run clocktest on a system here, not running NTP, using
> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
> this happen? Does it come from the error due to the multiply and shift
> used for tsc to/from ns conversions ?

What clocksource is used by Linux? Also tsc?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] Clock drift.

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I run clocktest on a system here, not running NTP, using
>> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
>> this happen? Does it come from the error due to the multiply and shift
>> used for tsc to/from ns conversions ?
> 
> What clocksource is used by Linux? Also tsc?

It is an ARM, but yes, the timer used to emulate the tsc is also used by
Linux. Here is the relevant code:

notrace unsigned long long __ipipe_mach_get_tsc(void)
{
        if (likely(ixp4xx_timer_initialized)) {
                union tsc_reg *local_tsc, result;
                unsigned long stamp;

                local_tsc = &tsc[ipipe_processor_id()];

                __asm__ ("ldmia %1, %M0\n":
                         "=r"(result.full): "r"(local_tsc),
"m"(*local_tsc));
                barrier();
                stamp = *IXP4XX_OSTS;
                if (unlikely(stamp < result.low))
                        /* 32 bit counter wrapped, increment high word. */
                        result.high++;
                result.low = stamp;
                return result.full;
        }

        return 0;
}

cycle_t ixp4xx_get_cycles(void)
{
        return *IXP4XX_OSTS;
}

static struct clocksource clocksource_ixp4xx = {
        .name           = "OSTS",
        .rating         = 200,
        .read           = ixp4xx_get_cycles,
        .mask           = CLOCKSOURCE_MASK(32),
        .shift          = 20,
        .flags          = CLOCK_SOURCE_IS_CONTINUOUS,
};

unsigned long ixp4xx_timer_freq = FREQ;
static int __init ixp4xx_clocksource_init(void)
{
        clocksource_ixp4xx.mult =
                clocksource_hz2mult(ixp4xx_timer_freq,
                                    clocksource_ixp4xx.shift);
        clocksource_register(&clocksource_ixp4xx);

        return 0;
}


-- 
                                                 Gilles.

Re: [Xenomai-core] Clock drift.

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Hi,
> 
> I run clocktest on a system here, not running NTP, using
> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
> this happen? Does it come from the error due to the multiply and shift
> used for tsc to/from ns conversions ?
>

- ipipe_request_tickdev() returning a timer freq we don't like?
- does using your generic arith ops instead of the arch-dependent fast ops help?

> TIA,
> 


-- 
Philippe.

Re: [Xenomai-core] Clock drift.

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> I run clocktest on a system here, not running NTP, using
>> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
>> this happen? Does it come from the error due to the multiply and shift
>> used for tsc to/from ns conversions ?
>>
> 
> - ipipe_request_tickdev() returning a timer freq we don't like?

Well, I would expect ipipe_request_tickdev() to return the same
frequency as the one used by Linux.

> - does using your generic arith ops instead of the arch-dependent fast ops help?

Linux itself uses a multiply and shift strategy, so maybe the
computation of the multiply and shift factors done by Xenomai does not
find the same result as the one used by Linux?

-- 
                                                 Gilles.

Re: [Xenomai-core] Clock drift.

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> I run clocktest on a system here, not running NTP, using
>>> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
>>> this happen? Does it come from the error due to the multiply and shift
>>> used for tsc to/from ns conversions ?
>>>
>> - ipipe_request_tickdev() returning a timer freq we don't like?
> 
> Well, I would expect ipipe_request_tickdev() to return the same
> frequency as the one used by Linux.
>

Yes it does. But this value is used by Xenomai code.

>> - does using your generic arith ops instead of the arch-dependent fast ops help?
> 
> Linux itself uses a multiply and shift strategy, so maybe the
> computation of the multiply and shift factors done by Xenomai does not
> find the same result as the one used by Linux?
> 

Time to involve printk() in this battle.

-- 
Philippe.

Re: [Xenomai-core] Clock drift.

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Hi,
>>>>
>>>> I run clocktest on a system here, not running NTP, using
>>>> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
>>>> this happen? Does it come from the error due to the multiply and shift
>>>> used for tsc to/from ns conversions ?
>>>>
>>> - ipipe_request_tickdev() returning a timer freq we don't like?
>> Well, I would expect ipipe_request_tickdev() to return the same
>> frequency as the one used by Linux.
>>
> 
> Yes it does. But this value is used by Xenomai code.

It turns out that the frequency used to convert tsc to ns is the cpu
frequency (which is kind of a misnomer, since your emulated tsc on arm
does not run at cpu frequency), which is computed though it should have
the same value as the timer frequency but is suject to rounding errors.

-- 
                                                 Gilles.

Re: [Xenomai-core] Clock drift.

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> Philippe Gerum wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Hi,
>>>>>
>>>>> I run clocktest on a system here, not running NTP, using
>>>>> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
>>>>> this happen? Does it come from the error due to the multiply and shift
>>>>> used for tsc to/from ns conversions ?
>>>>>
>>>> - ipipe_request_tickdev() returning a timer freq we don't like?
>>> Well, I would expect ipipe_request_tickdev() to return the same
>>> frequency as the one used by Linux.
>>>
>> Yes it does. But this value is used by Xenomai code.
> 
> It turns out that the frequency used to convert tsc to ns is the cpu
> frequency (which is kind of a misnomer, since your emulated tsc on arm
> does not run at cpu frequency), which is computed though it should have
> the same value as the timer frequency but is suject to rounding errors.

The timer frequency is as approximate as the cpu frequency,
ipipe_request_tickdev does this:

	freq = (1000000000ULL * evtdev->mult) >> evtdev->shift;
	*tmfreq = (unsigned long)freq;

-- 
                                                 Gilles.

Re: [Xenomai-core] Clock drift.

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Philippe Gerum wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I run clocktest on a system here, not running NTP, using
>>>>>> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
>>>>>> this happen? Does it come from the error due to the multiply and shift
>>>>>> used for tsc to/from ns conversions ?
>>>>>>
>>>>> - ipipe_request_tickdev() returning a timer freq we don't like?
>>>> Well, I would expect ipipe_request_tickdev() to return the same
>>>> frequency as the one used by Linux.
>>>>
>>> Yes it does. But this value is used by Xenomai code.
>> It turns out that the frequency used to convert tsc to ns is the cpu
>> frequency (which is kind of a misnomer, since your emulated tsc on arm
>> does not run at cpu frequency), which is computed though it should have
>> the same value as the timer frequency but is suject to rounding errors.
> 
> The timer frequency is as approximate as the cpu frequency,
> ipipe_request_tickdev does this:
> 
> 	freq = (1000000000ULL * evtdev->mult) >> evtdev->shift;
> 	*tmfreq = (unsigned long)freq;
> 

Ok. But linux uses the same approximate frequency. So, the error is
somewhere else.

-- 
                                                 Gilles.

Re: [Xenomai-core] Clock drift.

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> Philippe Gerum wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Hi,
>>>>>
>>>>> I run clocktest on a system here, not running NTP, using
>>>>> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
>>>>> this happen? Does it come from the error due to the multiply and shift
>>>>> used for tsc to/from ns conversions ?
>>>>>
>>>> - ipipe_request_tickdev() returning a timer freq we don't like?
>>> Well, I would expect ipipe_request_tickdev() to return the same
>>> frequency as the one used by Linux.
>>>
>> Yes it does. But this value is used by Xenomai code.
> 
> It turns out that the frequency used to convert tsc to ns is the cpu
> frequency (which is kind of a misnomer, since your emulated tsc on arm
> does not run at cpu frequency),

Yes, that's bad. We have a timebase frequency that applies to our clock readings
for calculating delays, and a timer frequency used to rescale those delays for
programming timer shots. The CPU frequency has no relevance here. The fact that
x86 once assumed CPU freq == TSC freq is an unfortunate legacy that goes down
deep to the I-pipe as well.

 which is computed though it should have
> the same value as the timer frequency but is suject to rounding errors.
> 


-- 
Philippe.