What IS the right NTP behaviour ?

[Tim Kientzle]

I like your outline here.

One concern I keep running into:  Using NTP in VMs that are frequently suspended/resumed.  Though I suppose this may be covered by your 'workstation' scenario (just step it after VM resume when you see the large skew).

Tim


> On Sep 23, 2015, at 2:05 AM, Poul-Henning Kamp <phk at freebsd.org> wrote:
> 
> As you probably know I'm working on a new NTP client called Ntimed.
> 
> It is no surprise that people have different expectations of how
> timekeeping should behave, and I'm trying to figure out
> what Do What I Want is.
> 
> I think I have identified three variations of "DWIW", which I have
> named "eCommerce", "SCADA" and "Workstation"
> 
> Please let me know (private email to keep list noise down) if your
> needs would not be served by any of these three variations or for
> that matter any other comment or input on this topic.
> 
> Thanks
> 
> Poul-Henning
> 
> 
> eCommerce
> ---------
> 
> 	Correct system time is mandatory.
> 
> 	Bootup fails if correct time cannot established.
> 		What do we mean by "fails" ?
> 			Does it hang until success ?
> 			Does it fail into single-user ?
> 			Does it raise a big red flag ?
> 
> 	Stepping time after bootup is *never* allowed.
> 		If time drifts out of tolerance:
> 			Raise Alarm
> 				How ?
> 				Signal init(8) into single-user mode ?
> 			Slew clock, no matter how far.
> 			Syslog periodically how wrong system time is
> 
> SCADA
> -----
> 
> 	We don't need the system clock to be on time, as long as
> 	we know exactly how wrong it is.
> 
> 	Startup should be as quick and reliable as possible.
> 		Configurable timer for how long we hold up startup.
> 
> 	Startup step only allowed during this time interval.
> 
> 	Stepping time after bootup is never allowed.
> 		If time drifts out of tolerance:
> 			Slew clock, no matter how far.
> 			Syslog periodically how wrong system time is
> 			Raise Alarm (optional)
> 				How ?
> 
> Workstation
> -----------
> 
> 	Startup should be fast-ish
> 
> 	Steps are allowed any time necessary
> 		suspend/resume
> 		change in network topology
> 		clock drift
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>