Google announced public NTP service some time ago: https://developers.google.com/time/
On Tue, Dec 20, 2016 at 7:29 PM Laurent Dumont <ad...@coldnorthadmin.com> wrote: > I do think that the point of the Pool network is to be used by both > > consumers and vendors. And as mentioned before, there is a process if > > you are a vendor and want to use the pool within a commercial product. I > > have 3 NTP servers running and I don't really care who is using it. > > > > That said, setting up your own infrastructure is also worth considering > > if it's a business critical feature. I assume that a Snapchat app that > > fails to have accurate time or correct itself could be abused. > > > > To be honest, the fact that NTP is still something managed by volunteers > > and not a regulated entity (a bit like DNS) is mind boggling. > > > > On 12/20/2016 09:41 PM, Keenan Tims wrote: > > > Better for whom? I'm sure all mobile operating systems provide some > > > access to time, with a least 'seconds' resolution. If an app deems > > > this time source untrustworthy for some reason, I don't think the > > > reasonable response is to make independent time requests from a > > > volunteer-operated pool for public servers designed for host > > > synchronization. Particularly on mobile, the compartmentalization of > > > applications means that this 'better' time will only be accessible to > > > one application, and many applications may have this 'better time' > > > requirement. These developers should be lobbying Apple and Google for > > > better time, if they need it, not making many millions of calls to the > > > NTP pool. To make things worse, I'm fairly sure that Apple's 'no > > > background tasks' policy means that an application can't *maintain* > > > its sense of time, so it would not surprise me if it fires off NTP > > > requests every time it is focused, further compounding the burden. > > > > > > Time is already available, and having every application query for its > > > own time against a public resource doesn't seem very friendly. It > > > certainly doesn't scale. If they are unsuccessful lobbying the OS, why > > > not trust the time provided by the API calls they are surely doing to > > > their own servers? Most HTTP responses include a timestamp; surely > > > this is good enough for expiring Snaps. Or at least operate their own > > > NTP infrastructure. > > > > > > I'm sure that Snap had no malicious intent and commend them for their > > > quick and appropriate response once the issue was identified, but I > > > don't think this behaviour is very defensible. I for one was not > > > harmed by the ~10x increase in load and traffic on my NTP pool node, > > > but the 100x increase if a handful of similar apps decided they 'need' > > > more accurate time than the OS provides would be cause for concern, > > > and I suspect a great many pool nodes would simply disappear, > > > compounding the problem. Please make use of these and similar services > > > as they are designed to be used, and as efficiently as possible, > > > especially if you are responsible for millions of users / machines. > > > > > > In a similar vein, I've always been curious what the ratio Google sees > > > of ICMP echo vs. DNS traffic to 8.8.8.8 is... > > > > > > Keenan > > > > > > > > > On 2016-12-20 18:16, Tim Raphael wrote: > > >> Exactly, > > >> > > >> Also they’re across Android and iOS and getting parity of operations > > >> across those two OSs isn’t easy. > > >> Better to just embed what they need inside the app if it is > > >> specialised enough. > > >> > > >> - Tim > > >> > > >>> On 21 Dec. 2016, at 10:13 am, Emille Blanc > > >>> <emi...@abccommunications.com> wrote: > > >>> > > >>> Perhaps the host OS' to which snapchat caters, don't all have a > > >>> devent ntp subststem available? > > >>> I have vague recollections of some other software (I'm sure we all > > >>> know which) implemented it's own malloc layer for every system it > > >>> ran on, for less trivial reasons. ;) > > >>> > > >>> ________________________________________ > > >>> From: NANOG [nanog-boun...@nanog.org] On Behalf Of Tim Raphael > > >>> [raphael.timo...@gmail.com] > > >>> Sent: Tuesday, December 20, 2016 5:34 PM > > >>> To: Gary E. Miller > > >>> Cc: nanog@nanog.org > > >>> Subject: Re: Recent NTP pool traffic increase > > >>> > > >>> This was my thought actually, Apple does offer some time services as > > >>> part of the OS but it’s becoming common with larger / more popular > > >>> apps to provide some of these services internally. > > >>> Look at the FB app for example, there are a lot of “system” things > > >>> they do themselves due to the ability to control specifics. Users > > >>> don’t want to have to install a second “specialised app” for this > > >>> either. > > >>> > > >>> With regard to an ephemeral chat app requiring time sync, I can > > >>> think of quite a few use cases and mechanisms in the app that might > > >>> require time services. > > >>> > > >>> - Tim > > >>> > > >>> > > >>>> On 21 Dec. 2016, at 9:26 am, Gary E. Miller <g...@rellim.com> wrote: > > >>>> > > >>>> Yo valdis.kletni...@vt.edu! > > >>>> > > >>>> On Tue, 20 Dec 2016 20:20:48 -0500 > > >>>> valdis.kletni...@vt.edu wrote: > > >>>> > > >>>>> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: > > >>>>>> Mostly out of curiosity, what was the reason for the change in the > > >>>>>> Snapchat code, and what plans does Snap have for whatever reason > > >>>>>> the NTP change was put in place? > > >>>>> From other comments in the thread, it sounds like the app was simply > > >>>>> linked against a broken version of a library.... > > >>>> But why is a chat app doing NTP at all? it should rely on the OS, or > > >>>> a specialized app, to keep local time accurate. > > >>>> > > >>>> RGDS > > >>>> GARY > > >>>> > --------------------------------------------------------------------------- > > >>>> > > >>>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > > >>>> g...@rellim.com Tel:+1 541 382 8588 > > > > > > >
