clocksource 'tsc' marked unstable, CLOCK_HOST_REALTIME went bananas

clocksource 'tsc' marked unstable, CLOCK_HOST_REALTIME went bananas

[Per Oberg]

Hello list!

I am running Xenomai 3.0.7. released version with Kernel 4.9.90 patchlevel 6.

We have a new x86-64 hardware, and during a test-run the clocksource went unstable, see (1) below for dmesg.

After this, calls to "clock_gettime(CLOCK_HOST_REALTIME,&timeStamp)"  went bananas. Like if time stopped completely, (or possibly jumped back in time at least a few hours). Stuff running on timers (using CLOCK_MONOTONIC)kept running fine. I tried switching time to hpet using "clocksource=hpet" but this didn't work at all. Either time (CLOCK_HOST_REALTIME) jumped back and forth or it completely stopped.  Now I'm using "tsc=reliable" and haven't seen any issues since. 

I think I know why tsc may be deemed unreliable, but why can't I run using hpet?

What are the drawbacks for xenomai with using tsc=reliable ?


----------------- (1) ----------------- 
[19139.502750] clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as unstable because the skew is too large:
[19139.503499] clocksource:                       'hpet' wd_now: f347622d wd_last: 35ab9afb mask: ffffffff
[19139.504245] clocksource:                       'tsc' cs_now: 31567c07fb36 cs_last: 30ffd3d5ec2d mask: ffffffffffffffff
[19139.505045] clocksource: Switched to clocksource hpet
----------------- (1) ----------------- 

Best regards
Per Öberg 

Re: clocksource 'tsc' marked unstable, CLOCK_HOST_REALTIME went bananas

[Jan Kiszka]

On 28.03.19 09:47, Per Oberg via Xenomai wrote:
> Hello list!
> 
> I am running Xenomai 3.0.7. released version with Kernel 4.9.90 patchlevel 6.
> 
> We have a new x86-64 hardware, and during a test-run the clocksource went unstable, see (1) below for dmesg.
> 
> After this, calls to "clock_gettime(CLOCK_HOST_REALTIME,&timeStamp)"  went bananas. Like if time stopped completely, (or possibly jumped back in time at least a few hours). Stuff running on timers (using CLOCK_MONOTONIC)kept running fine. I tried switching time to hpet using "clocksource=hpet" but this didn't work at all. Either time (CLOCK_HOST_REALTIME) jumped back and forth or it completely stopped.  Now I'm using "tsc=reliable" and haven't seen any issues since.
> 
> I think I know why tsc may be deemed unreliable, but why can't I run using hpet?
> 

The TSC may be detected as unreliable by Linux if a the RT application disturbs 
the detection algorithm too much (e.g. via long-running RT workload). You can 
let it switch to HPET, but CLOCK_HOST_REALTIME will no longer work, as you 
noticed, because it assumes that Linux is using TSC as clocksource.

> What are the drawbacks for xenomai with using tsc=reliable ?
> 

Practically, none, provided your tsc is actually reliable. If not, also Xenomai 
and its RT applications would have serious problems.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux