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:	Wed, 17 Sep 2008 13:23:28 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	"Dâniel Fraga" <fragabr@...il.com>
cc:	David Miller <davem@...emloft.net>, thomas.jarosch@...ra2net.com,
	billfink@...dspring.com, Netdev <netdev@...r.kernel.org>,
	Patrick Hardy <kaber@...sh.net>,
	netfilter-devel@...r.kernel.org, kadlec@...ckhole.kfki.hu
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

On Tue, 16 Sep 2008, Dâniel Fraga wrote:

> On Tue, 16 Sep 2008 15:10:33 +0300 (EEST)
> "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:
> 
> > Only thing I know to ask is, do you have any idea if your ntpd is 
> > hard-stepping the time instead of adjusting the clock's rate a bit (the 
> > latter should keep the clock monotonious besides potential bugs)?
> 
> 	I assume it's adjusting the clock's rate a bit. Anyway, it's a
> pretty simple config:
> 
> fraga@...eporto ~$ cat /etc/ntp.conf 
> server ntp.usp.br
> server ntp.nasa.gov
> driftfile /etc/ntp.drift
> 
> 	And ntpd is running without any special parameters.
> 
> 	The log messages are as simple as:
> 
> Sep 15 03:56:04 teleporto ntpd[2301]: frequency initialized 5.891 PPM from /etc/ntp.drift
> Sep 15 03:59:25 teleporto ntpd[2304]: frequency initialized 5.891 PPM from /etc/ntp.drift
> Sep 15 04:03:49 teleporto ntpd[2304]: synchronized to 143.107.255.15, stratum 2
> Sep 15 04:03:49 teleporto ntpd[2304]: kernel time sync status change 0001
> Sep 15 04:10:16 teleporto ntpd[2304]: synchronized to 198.123.30.132, stratum 1
> Sep 15 04:11:58 teleporto ntpd[2301]: frequency initialized 5.891 PPM from /etc/ntp.drift
> Sep 15 04:16:18 teleporto ntpd[2301]: synchronized to 198.123.30.132, stratum 1
> Sep 15 04:16:18 teleporto ntpd[2301]: kernel time sync status change 0001
> Sep 15 12:08:53 teleporto ntpd[2301]: kernel time sync status change 4001
> Sep 15 12:34:31 teleporto ntpd[2301]: kernel time sync status change 0001
> Sep 15 14:34:06 teleporto ntpd[2301]: kernel time sync status change 4001
> Sep 15 14:51:12 teleporto ntpd[2301]: kernel time sync status change 0001 

I was to look where these (or actually the ones you mentioned earlier) 
messages exactly originate from in the source of ntpd but didn't yet have 
time.

> 	If I understood correctly what do you mean, ntpd adjusts nicely the time to not 
> cause huge differences in the time.

It is definately the default, if it's even possible to configure ntpd to 
just set forcibly the new time (with ntpdate you can decide that with 
-b/-B switch iirc).

> 	And we're reaching the conclusion that the timer code from 2.6.25 
> and above have something wrong, since 2.6.24 and below is ok, which 
> causes those stalls.

There were some other timer related complications in 2.6.25 but it's so 
long time ago that I hardly remember anything about those anymore (and 
I'm not an expert on those things anyway). And it's still very open issue 
how that would cause the problem you're seeing.

> 	And just a question: do you use ntpd on your own desktop?

Yes.


-- 
 i.

Powered by blists - more mailing lists