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
| ||
|
Date: Mon, 31 Jan 2022 11:21:08 +0100 From: Miroslav Lichvar <mlichvar@...hat.com> To: Richard Cochran <richardcochran@...il.com> Cc: netdev@...r.kernel.org, Yangbo Lu <yangbo.lu@....com> Subject: Re: [PATCH net-next 5/5] ptp: start virtual clocks at current system time. On Thu, Jan 27, 2022 at 02:01:16PM -0800, Richard Cochran wrote: > On Thu, Jan 27, 2022 at 12:45:36PM +0100, Miroslav Lichvar wrote: > > When a virtual clock is being created, initialize the timecounter to the > > current system time instead of the Unix epoch to avoid very large steps > > when the clock will be synchronized. > > I think we agreed that, going forward, new PHC drivers should start at > zero (1970) instead of TAI - 37. I tried to find the discussion around this decision, but failed. Do you have a link? To me, it seems very strange to start the PHC at 0. It makes the initial clock correction unnecessarily larger by ~7 orders of magnitude. The system clock is initialized from the RTC, which can have an error comparable to the TAI-UTC offset, especially if the machine was turned off for a longer period of time, so why not initialize the PHC from the system time? The error is much smaller than billions of seconds. -- Miroslav Lichvar
Powered by blists - more mailing lists