linux-kernel - Re: [PATCHv2 0/6] pps: time synchronization over LPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Mar 2010 23:42:01 +0300
From:	Alexander Gordeev <lasaine@....cs.msu.su>
To:	john stultz <johnstul@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, linuxpps@...enneenne.com,
	"Nikita V. Youshchenko" <yoush@...msu.su>, stas@....cs.msu.su,
	Rodolfo Giometti <giometti@...eenne.com>
Subject: Re: [PATCHv2 0/6] pps: time synchronization over LPT

Hi John,

Sorry for the delay...

В Mon, 8 Mar 2010 19:25:07 -0800
john stultz <johnstul@...ibm.com> пишет:

> On Wed, Feb 24, 2010 at 4:28 AM, Alexander Gordeev
> <lasaine@....cs.msu.su> wrote:
> > This patchset is tested against the vanilla 2.6.32.9 kernel. But we
> > are actually using it on 2.6.31.12-rt20 rt-preempt kernel most of
> > the time. Also there is a version which should be applied on top of
> > LinuxPPS out of tree patches (i.e. all clients and low-level irq
> > timestamps stuff). Those who are interested in other versions of
> > the patchset can find them in my git repository:
> > http://lvk.cs.msu.su/~lasaine/timesync/linux-2.6-timesync.git
> >
> > There is one problem however: hardpps() works bad when used on top
> > of 2.6.33-rc* with CONFIG_NO_HZ enabled. The reason for this is
> > commit a092ff0f90cae22b2ac8028ecd2c6f6c1a9e4601. Without it
> > hardpps() is able to sync to 1us precision in about 10 seconds.
> > With it
> 
> Uh. Not sure I see right off why the logarithmic time accumulation
> would give you troubles. Its actually there to try to fix a couple of
> NTP issues that cropped up when the accumulation interval was pushed
> out to 2HZ with CONFIG_NO_HZ.

Yes, I know. I guess (based on the commit log and other sources) that
this change was added to make chrony work better on tickless kernel.
So chrony corrects the time using only frequency corrections?
My approach is different: use time_offset t remove the phase error and
adjust time_freq to remove frequency error.

> Do you have any extra insight here as to whats going on with your
> code?   The only thing I could guess would be second_overflow() is
> happening closer to the actual overflow, but maybe less regularly? But
> again, I'm not sure how this would be drastically different then
> before with the 2HZ accumulation period.

I still can't find this out (partially because I'm too busy with other
tasks). The new code seems ok to mee. time_offset is added at
second_overflow as usual. Maybe the problem is with the frequency
correction. I'm going to run some tests that should show where the
problem is: in the phase or freq correction.

I hope I'll have time for this next week.

-- 
  Alexander

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)