All of lore.kernel.org
 help / color / mirror / Atom feed
From: J William Piggott <elseifthen@gmx.com>
To: Alexey Galakhov <agalakhov@gmail.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH] hwclock: flush stdout in hwclock -c
Date: Tue, 21 Apr 2015 15:12:57 -0400	[thread overview]
Message-ID: <5536A139.9030905@gmx.com> (raw)
In-Reply-To: <20150421175045.75d3ffe7@aga-ws-01>


On 04/21/2015 11:50 AM, Alexey Galakhov wrote:
> Am Tue, 21 Apr 2015 11:19:06 -0400
> schrieb J William Piggott <elseifthen@gmx.com>:
> 
>> I assume then, that you are only using columns one and two, because
>> columns 3 and 4 are invalid output.
> 
> IN the beginning I used column 3. By examining the source code I
> figured out that it is suitable for such kind of tests, at least
> if /etc/adjtime is empty.
> 
>> Your test could capture timestamps without hwclock's compare
>> function, yes?
> 
> Right now I reimplemented the whole (simplified) hwclock -c
> functionality in my own test. In fact, I recalculate column 3 on my own.
> 
> What I really want to see is a "correct" column 3. In my test I'm doing
> direct comparison.

So you are confirming my position that hwclock's compare function is
broken and that you are not using it for any useful purpose.


> Pseudocode:
> 
> while(1) {
>     do { // busy-wait
>         t1 = clock_gettime();
>         t2 = ioctl(RTC);
>     } while t2 does not change;
>     
>     drift = (t1 - t2) / total time;
> 
>     sleep(until t1 + 990ms);
> }
> 
> My test fails if a relative drift is more than expected with such a
> hardware. This is useful to quickly detect stupid bugs like wrong PLL
> configuration on new hardware ("time runs 10% faster" and so on). The
> reason why we do so is, nobody really cares about the system clock
> while installing the kernel and base system. Thus the problem is
> detected only when the complete user level is up and running, and
> nobody wants to touch the bootloader and the kernel at this time. So we
> created a bunch of "early warning tests" to detect non-obvious kernel
> and hardware issues.

Thank you for the detailed explanation Alexey. I can see how comparing
the System and Hardware clocks is useful for your situation and worthy
of a specialize test as you have written. In my opinion, comparing two
drifting clocks is not useful to end users, system administrators, or
distribution maintainers and I am hopeful that Karel will agree to its
removal from hwclock.

> 
> Regards,
> Alexey
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2015-04-21 19:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-16 15:26 [PATCH] hwclock: flush stdout in hwclock -c Alexey Galakhov
2015-04-20  0:34 ` J William Piggott
2015-04-20  7:28   ` Alexey Galakhov
2015-04-21 15:19     ` J William Piggott
2015-04-21 15:50       ` Alexey Galakhov
2015-04-21 19:12         ` J William Piggott [this message]
2015-04-27  8:27 ` Karel Zak
2015-04-27 21:27   ` J William Piggott
2015-04-27 21:42     ` Alexey Galakhov
2015-04-28  6:50       ` Bernhard Voelker
2015-04-28 11:27       ` J William Piggott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5536A139.9030905@gmx.com \
    --to=elseifthen@gmx.com \
    --cc=agalakhov@gmail.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.