MR
Michael Rothwell
Wed, Nov 30, 2016 2:21 PM
... was just announced.
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html?m=1
DJ
David J Taylor
Wed, Nov 30, 2016 3:16 PM
Subject: [time-nuts] Google public NTP service
... was just announced.
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html?m=1
One "service" I will /not/ be using.
Hope it doesn't mess up too many folk. It's completely against the
recommendations, of course.
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
Subject: [time-nuts] Google public NTP service
... was just announced.
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html?m=1
_______________________________________________
One "service" I will /not/ be using.
Hope it doesn't mess up too many folk. It's completely against the
recommendations, of course.
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
PK
Poul-Henning Kamp
Wed, Nov 30, 2016 3:19 PM
Hope it doesn't mess up too many folk. It's completely against the
recommendations, of course.
But in difference from these, it actually works.
Trust me, they'll get thousands of users...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
--------
In message <706C789A8B5440B3911A8A02C93E3E54@Alta>, "David J Taylor" writes:
>Hope it doesn't mess up too many folk. It's completely against the
>recommendations, of course.
But in difference from these, it actually works.
Trust me, they'll get thousands of users...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
GE
Gary E. Miller
Wed, Nov 30, 2016 8:14 PM
I sort of see where they are coming from, but this will cause problems.
The NTP packets google sends out have no way to be marked as 'not UTC'.
Given how promiscuous people are sharing NTP chimers these 'not UTC'
chimers will get into the mix. When they diverge from the real UTC servers
it will sorely confuse NTP clients.
I would support an RFC to mark the type a time an chimer is servings.
Not only smeared and UTC, but also TAI, UT, UT0, UT1, UT2, ET, TDT, TDB,
TT, TCG, TCB, GPS, etc...
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Yo Michael!
On Wed, 30 Nov 2016 14:21:39 +0000
Michael Rothwell <michael@rothwell.us> wrote:
> ... was just announced.
> https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html?m=1
I sort of see where they are coming from, but this will cause problems.
The NTP packets google sends out have no way to be marked as 'not UTC'.
Given how promiscuous people are sharing NTP chimers these 'not UTC'
chimers will get into the mix. When they diverge from the real UTC servers
it will sorely confuse NTP clients.
I would support an RFC to mark the type a time an chimer is servings.
Not only smeared and UTC, but also TAI, UT, UT0, UT1, UT2, ET, TDT, TDB,
TT, TCG, TCB, GPS, etc...
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
GM
Gregory Maxwell
Wed, Nov 30, 2016 8:24 PM
Obvious outcome is obvious. Leap smear prevented faults between google
systems but then created the problem that other things don't agree
with google's timestamps-- and the leapseconds still cause problems
for many other parties.
On Wed, Nov 30, 2016 at 2:21 PM, Michael Rothwell <michael@rothwell.us> wrote:
> ... was just announced.
> https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html?m=1
Obvious outcome is obvious. Leap smear prevented faults between google
systems but then created the problem that other things don't agree
with google's timestamps-- and the leapseconds still cause problems
for many other parties.
BC
Bob Camp
Wed, Nov 30, 2016 8:26 PM
I sort of see where they are coming from, but this will cause problems.
The NTP packets google sends out have no way to be marked as 'not UTC'.
Given how promiscuous people are sharing NTP chimers these 'not UTC'
chimers will get into the mix. When they diverge from the real UTC servers
it will sorely confuse NTP clients.
I would support an RFC to mark the type a time an chimer is servings.
Not only smeared and UTC, but also TAI, UT, UT0, UT1, UT2, ET, TDT, TDB,
TT, TCG, TCB, GPS, etc…
That would probably be a good point to make on the NTP list :)
The gotcha is that there is essentially zero time to approve and implement something like that before the end of next
month …
Bob
Hi
> On Nov 30, 2016, at 3:14 PM, Gary E. Miller <gem@rellim.com> wrote:
>
> Yo Michael!
>
> On Wed, 30 Nov 2016 14:21:39 +0000
> Michael Rothwell <michael@rothwell.us> wrote:
>
>> ... was just announced.
>> https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html?m=1
>
> I sort of see where they are coming from, but this will cause problems.
>
> The NTP packets google sends out have no way to be marked as 'not UTC'.
> Given how promiscuous people are sharing NTP chimers these 'not UTC'
> chimers will get into the mix. When they diverge from the real UTC servers
> it will sorely confuse NTP clients.
>
> I would support an RFC to mark the type a time an chimer is servings.
> Not only smeared and UTC, but also TAI, UT, UT0, UT1, UT2, ET, TDT, TDB,
> TT, TCG, TCB, GPS, etc…
That would probably be a good point to make on the NTP list :)
The gotcha is that there is essentially zero time to approve and implement something like that before the end of next
month …
Bob
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> gem@rellim.com Tel:+1 541 382 8588
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
PK
Poul-Henning Kamp
Wed, Nov 30, 2016 8:31 PM
I would support an RFC to mark the type a time an chimer is servings.
Not only smeared and UTC, but also TAI, UT, UT0, UT1, UT2, ET, TDT, TDB,
TT, TCG, TCB, GPS, etc…
That would probably be a good point to make on the NTP list :)
The gotcha is that there is essentially zero time to approve and implement something like that before the end of next month …
And no space in the NTP packets for the bits.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
--------
In message <F80F97D3-CE19-43B9-B37F-BE5D5F186D7E@n1k.org>, Bob Camp writes:
>> I would support an RFC to mark the type a time an chimer is servings.
>> Not only smeared and UTC, but also TAI, UT, UT0, UT1, UT2, ET, TDT, TDB,
>> TT, TCG, TCB, GPS, etc…
>
>That would probably be a good point to make on the NTP list :)
>
>The gotcha is that there is essentially zero time to approve and implement something like that before the end of next month …
And no space in the NTP packets for the bits.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
GE
Gary E. Miller
Wed, Nov 30, 2016 8:31 PM
Yo Bob!
On Wed, 30 Nov 2016 15:26:34 -0500
Bob Camp kb8tq@n1k.org wrote:
I would support an RFC to mark the type a time an chimer is
servings. Not only smeared and UTC, but also TAI, UT, UT0, UT1,
UT2, ET, TDT, TDB, TT, TCG, TCB, GPS, etc…
That would probably be a good point to make on the NTP list :)
Already done. In private and on BTPsec.
The gotcha is that there is essentially zero time to approve and
implement something like that before the end of next month …
You gotta start sometime. Now is a good time. This is not the first
time Google has done this, and certainly will not be the last. It had
bad consequences last time and they did not learn from that.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Yo Bob!
On Wed, 30 Nov 2016 15:26:34 -0500
Bob Camp <kb8tq@n1k.org> wrote:
> > I would support an RFC to mark the type a time an chimer is
> > servings. Not only smeared and UTC, but also TAI, UT, UT0, UT1,
> > UT2, ET, TDT, TDB, TT, TCG, TCB, GPS, etc…
>
>
> That would probably be a good point to make on the NTP list :)
Already done. In private and on BTPsec.
> The gotcha is that there is essentially zero time to approve and
> implement something like that before the end of next month …
You gotta start sometime. Now is a good time. This is not the first
time Google has done this, and certainly will not be the last. It had
bad consequences last time and they did not learn from that.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
GE
Gary E. Miller
Wed, Nov 30, 2016 8:35 PM
Yo Poul-Henning!
On Wed, 30 Nov 2016 20:31:09 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:
I would support an RFC to mark the type a time an chimer is
servings. Not only smeared and UTC, but also TAI, UT, UT0, UT1,
UT2, ET, TDT, TDB, TT, TCG, TCB, GPS, etc…
That would probably be a good point to make on the NTP list :)
The gotcha is that there is essentially zero time to approve and
implement something like that before the end of next month …
And no space in the NTP packets for the bits.
Not true. NTP has provision for arbitrrary extensions to an ntp packet.
See RFC 5905. https://www.ietf.org/rfc/rfc5905.txt section 7.3:
"The packet format consists of three components: the header itself,
one or more optional extension fields, and an optional message
authentication code (MAC). "
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Yo Poul-Henning!
On Wed, 30 Nov 2016 20:31:09 +0000
"Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
> --------
> In message <F80F97D3-CE19-43B9-B37F-BE5D5F186D7E@n1k.org>, Bob Camp
> writes:
>
> >> I would support an RFC to mark the type a time an chimer is
> >> servings. Not only smeared and UTC, but also TAI, UT, UT0, UT1,
> >> UT2, ET, TDT, TDB, TT, TCG, TCB, GPS, etc…
> >
> >That would probably be a good point to make on the NTP list :)
> >
> >The gotcha is that there is essentially zero time to approve and
> >implement something like that before the end of next month …
>
> And no space in the NTP packets for the bits.
Not true. NTP has provision for arbitrrary extensions to an ntp packet.
See RFC 5905. https://www.ietf.org/rfc/rfc5905.txt section 7.3:
"The packet format consists of three components: the header itself,
one or more optional extension fields, and an optional message
authentication code (MAC). "
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
PK
Poul-Henning Kamp
Wed, Nov 30, 2016 8:42 PM
Not true. NTP has provision for arbitrrary extensions to an ntp packet.
Good luck getting that through firewalls after the lastest rounds
of NTP amplification attacks...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
--------
In message <20161130123506.63853273@spidey.rellim.com>, "Gary E. Miller" writes
:
>Not true. NTP has provision for arbitrrary extensions to an ntp packet.
Good luck getting that through firewalls after the lastest rounds
of NTP amplification attacks...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
