It looks very nice, but I'd dispute that only data centers need an accurate idea of the time (rather than one that is intermittently synced to an accurate time). Some computers these days have horrifically inaccurate clocks: on one of my machines I'd need to run sntp every ten minutes to keep it from acquiring >100ms errors, which is disconcertingly frequent.
Accurate time sync matters; the classic example is when running make(1) on remote fses capable of millisecond timing, you need a time sync accurate to the *millisecond*. (Perhaps NFS is 'data center only' these days, but I use it and I've never set foot in a data center.)
Posted Sep 1, 2011 14:26 UTC (Thu) by salimma (subscriber, #34460)
[Link]
My worst device is, ironically, Google's Nexus One. There's no user-exposed "intent" for setting the system clock, so if the mobile provider does not provide time information via the NITZ protocol, there's no way to use an NTP client to do the same without rooting the phone.
I get clock drift of about 1 minute a day. Horrendous.
LinuxCon: Mobile network management with ConnMan
Posted Sep 10, 2011 13:04 UTC (Sat) by lab (subscriber, #51153)
[Link]
Posted Sep 1, 2011 17:00 UTC (Thu) by njs (guest, #40338)
[Link]
IIUC, "simple NTP" is just NTP where you trust a single upstream time server, instead of talking to multiple servers simultaneously and combining their estimates for higher accuracy.
LinuxCon: Mobile network management with ConnMan
Posted Sep 1, 2011 17:34 UTC (Thu) by nix (subscriber, #2304)
[Link]
Ah, I thought it was a 'check time server at intervals, rather than continuously' thing. (At least, that's how all SNTP clients I've ever seen have worked. Mind you, I haven't looked at all hard.)
LinuxCon: Mobile network management with ConnMan
Posted Sep 1, 2011 17:51 UTC (Thu) by njs (guest, #40338)
[Link]
Oh, well, I just looked at the spec, so don't trust me.
Checking at intervals should work fine so long as you use the information to do some sort of drift-correction on the local clock, but I don't know if anyone does.
The ridiculous thing is that most of these devices have a GPS receiver in them, but AFAICT my phone can't be bothered to actually use that as a time reference, even when it's turned on...
LinuxCon: Mobile network management with ConnMan
Posted Sep 2, 2011 23:04 UTC (Fri) by dmarti (subscriber, #11625)
[Link]
Does the cellular network have its own time protocol? "Dumb" phones are getting their time over the network somehow. Maybe it's available to userspace somewhere.
LinuxCon: Mobile network management with ConnMan
Posted Sep 3, 2011 0:07 UTC (Sat) by mjg59 (subscriber, #23239)
[Link]
Most (but not all) GSM networks send a usable time signal. I think all CDMA ones do.
LinuxCon: Mobile network management with ConnMan
Posted Sep 7, 2011 23:45 UTC (Wed) by Baylink (subscriber, #755)
[Link]
Don't, in fact, trust njs, nix: you're right. Using SNTP as a client to sync your clock is a "sync now, and pray the local clock's disciplined" approach, and fails for all the reasons you think it ought to.
Running a local ntpd is a Very Good Idea, even on a laptop or cellphone; it's not like it sucks a lot of cycles.
LinuxCon: Mobile network management with ConnMan
Posted Sep 8, 2011 0:53 UTC (Thu) by nix (subscriber, #2304)
[Link]
Yeah. Though good god ntpd has a lot of failure modes. I just noticed another one: suspend a machine for twelve hours or so, so its awful hardware clock has to take the burden of keeping time, then resume it. ntpd silently decides that the time has drifted too far for slewing to work, and decides that it is best to do nothing. Log anything? Of course it doesn't log anything, why would you care that your time is suddenly not synchronized!
Gah!
LinuxCon: Mobile network management with ConnMan
Posted Sep 1, 2011 17:17 UTC (Thu) by jake (editor, #205)
[Link]
> It looks very nice, but I'd dispute that only data centers
> need an accurate idea of the time
I think Marcel's point was that *extreme* accuracy is not required for mobile devices. I didn't have it in my notes, but his slides mention 200us accuracy as being overkill. So they want reasonably accurate time, but not insanely accurate time -- or that is my understanding from his talk ...