[ClusterLabs] boothd-site/boothd-arbitrator: WARN: packet timestamp older than previous one

[Nicolas Huillard]

Le samedi 11 novembre 2017 à 10:46 +0100, Dejan Muhamedagic a écrit :
> Hmm, there is supposed to be a guarantee that the clock is
> monotonic (we use CLOCK_MONOTONIC). The clock_getres(3) does say
> though that it "is affected by the incremental adjustments
> performed by adjtime(3) and NTP." But normally those
> adjustments shouldn't exceed certain threshold per second.
> Anyway, maybe you can try with hpet as a clock source.

I tried with hpet avec acpi_pm (arbitrator using tsc, one site using
hpet, the other one using acpi_pm), with the same result.
Note that the booth message "packet timestamp older than previous one"
really means "not newer than", ie. it may happen even if the clock is
monotonic, but simply outputs the same value two consecutive times.
There should not be NTP abnormalities here, since clocks are in sync
and stable since a long time.

> > The CPUs are currently underutilised, which can lead to increased
> > discrepancy between cores TSCs.
> > I can either:
> > * switch to another clocksource (I don't yet know how to do that)
> 
> You can do that with sysfs: in
> /sys/devices/system/clocksource/clocksource0/ see
> available_clocksource and current_clocksource. To modify it on
> boot there are certainly some kernel parameters.

I just changed it and restated boothd only. I don't plan on changing
the clock source in the long run.

> No idea. If you feel like experimenting, you could add a bit more
> information into the debug messages (i.e. time difference) and
> log all time diffs. Otherwise, though it doesn't look so to me,
> maybe we do have some issue in the code, one never knows ;-)

I don't have much time to recompile and test booth, but I may
eventually do it on the arbitrator (which unfortunately is also the
machine less prone to trigger those warnings). I'll try to add the
time-diff, to check if it is 0 or less when the warning appears.

In the mean time, I'll just ignore those warnings.

Thank you very much!

-- 
Nicolas Huillard