Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On Saturday, June 14, 2014 9:52:46 PM UTC-5, Harlan Stenn wrote: Yes, and remember we live in a world of NAT. While there is much to be said for running your NTP servers that talk to outside NTP servers and having all of your other NTP clients talk to your NTP servers, some folks don't do this, and that means their clients can send a lot of queries to external servers and these requests will be coming from (different ports from) a single IP address (due to NAT). This is a good point. As a matter of fact, IPv4 has been exhausted in many locations around the world (first in Europe, then in Asia and, this month, in Latin America). Many IPv4-starved ISPs, having sit on their hands for years about moving to IPv6, have increasingly resorted to NAT for large swaths of their customers. This is bad in many ways, as the Internet grew out of one address per node. Unfortunately, this is bound to be a problem for years, when packets seem to come from the same address at a high rate. I'd be inclined to reject such likely NAT sources as if they were abusers, but this would just punish the customers of an irresponsible ISP. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On Tue, Jun 24, 2014 at 06:25:37PM +0200, Jochen Bern wrote: On -10.01.-28163 20:59, Miroslav Lichvar wrote: Agreed, but wouldn't switching to TAI everywhere be much more difficult than stopping messing with UTC and keep it a fixed offset from TAI? Having computer clocks run on UTC(frozen) instead of TAI makes the adaptation easier today, more difficult tomorrow (do we *really* need to work on that for (n3) seconds of an offset!?), and no less necessary in the long run (when UT1-TAI has grown much larger than UT1-UTC(frozen), and changes much faster as well). I prefer to have the slope right where the ball needs to get rolling. ;-) I was thinking about larger adjustments in the timezones, like 15, 30 or 60 minutes. They could be announced decades or centuries ahead, but possibly they would be hidden in the noise of the political/religious adjustments that are common today. Before the first correction is needed, maybe a global fixed timezone (or UTC directly) is already used everywhere and the position of the Sun observed at 12:00 is let to slowly revolve around Earth. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On Tue, Jun 24, 2014 at 06:13:17PM -0500, Mike S wrote: On 6/24/2014 5:59 AM, Miroslav Lichvar wrote: To me, it seems the reasonable thing to do would be to decouple UTC and UT1 completely and make the adjustment at a higher level like timezones if necessary. You're doing it wrong. If you don't want leap seconds, use a timescale which doesn't have them (e.g. TAI, GPS). UTC was created to closely track Sol. Decoupling that breaks its purpose, and the promise made when it took over from GMT. Yes, but to me it looks like redefining UTC to not track solar time anymore is easier than converting everyone and everything to keep time in TAI. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Part of this thread has gone OT. I don't think this is the right list to be discussing this. the Leap Second Discussion List leaps...@leapsecond.com is available for exactly this debate. However, that said, here's my 2 cents. As has been mentioned, UTC with leaps seconds, has been defined to track UT1 and thus solar time. The reason why it hasn't been fiddled with for a while, is the very fact that it tracks Solar time, and has become the basis of legal times globally. Many people, including up to now a majority of those voting at ITU-R, consider it essential that the legal time scale should represent human experience and rhythms, and not machine ticks. The lobby for change is essentially basing its arguments on experiences of bad engineering and sloppy systems design. The argument being that it would cost less to ignore leap seconds. For me, there is no reason that we cannot keep UTC with leap seconds, for 2 or 3 hundred years if necessary, while a replacement is designed which will keep the solar link. However we need not wait that long as VLBA measurements of variations in the earths rotation are approaching real time ( already hourly IIRC ). So it would be simple to include corrections, in terms of a frequency adjustment, in the GPS stream ( space is available). That correction could then be exploited by next gen GPS receivers and client software ( NTP). Those who got this far before pressing delete, will have noted that it requires a change in the definition of UTC, to abandon the link between the SI second and legal time. Why not? SI secs would still be available from the GPS stream. See you on the leapsecs list maybe. Mike Le 25 juin 2014 à 11:31, Miroslav Lichvar a écrit : On Tue, Jun 24, 2014 at 06:13:17PM -0500, Mike S wrote: On 6/24/2014 5:59 AM, Miroslav Lichvar wrote: To me, it seems the reasonable thing to do would be to decouple UTC and UT1 completely and make the adjustment at a higher level like timezones if necessary. You're doing it wrong. If you don't want leap seconds, use a timescale which doesn't have them (e.g. TAI, GPS). UTC was created to closely track Sol. Decoupling that breaks its purpose, and the promise made when it took over from GMT. Yes, but to me it looks like redefining UTC to not track solar time anymore is easier than converting everyone and everything to keep time in TAI. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On Mon, Jun 23, 2014 at 11:45:16PM -0500, Mike S wrote: On 6/16/2014 6:05 AM, Jochen Bern wrote: There are four official slots - two primary, two secondary - over the course of the year to insert leap seconds, Those are only preferences. Leap seconds may be inserted at any month boundary. A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. - ITU-R TF.460-6 Sooner or later, not even 12 leap seconds per year will be enough to keep UTC close to UT1. Hopefully they will be abolished long before that. Practically speaking, beside having to make more than two corrections per year (which is not expected to happen in the next few decades), could there be any reason to do it in other months than June and December? Older ntpd versions ( 4.2.5p53) used to check the month before setting the leap flag and I'm wondering if it still can used to detect spurious leap seconds. FWIW, the IERS announcements say Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, Miroslav Lichvar wrote: On Mon, Jun 23, 2014 at 11:45:16PM -0500, Mike S wrote: On 6/16/2014 6:05 AM, Jochen Bern wrote: There are four official slots - two primary, two secondary - over the course of the year to insert leap seconds, Those are only preferences. Leap seconds may be inserted at any month boundary. I'm positive that I've *seen* ntpd do the poll-interval-reduce on a *quarterly* base a couple years back. As Miroslav mentioned, the IERS - the guys who *schedule* leap seconds - currently *use* only the primaries, while still *mentioning* the secondaries as well: Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. [...] According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September. -- http://www.iers.org/nn_10828/IERS/EN/Publications/Bulletins/directLinks/bulletin__C__MD.html Of course the number of leap seconds required in recent years helped sticking with only the primaries, so it's a bit unclear to me which of all those choices are for the moment and which are long-term ... Sooner or later, not even 12 leap seconds per year will be enough to keep UTC close to UT1. Hopefully they will be abolished long before that. I do not wish to see that day, regardless of whether you're referring to a couple millennia of Earth-Moon tide-locking or a major off-center impact giving the crust a new spin. :-S Practically speaking, beside having to make more than two corrections per year (which is not expected to happen in the next few decades), could there be any reason to do it in other months than June and December? I've browsed the results of the infamous poll and most of the people voting abolish leap seconds apparently didn't mean to actually *abolish* them (as in, decouple UT1 and UTC, or whatever their successors might be called), but to have them *rearranged* into fewer and larger leaps. Of course, one can imagine that to go the other way - i.e., smaller but more frequent leaps. In general, I consider the entire procedure to first and foremost reflect a couple *external* facts - namely, a) the time necessary to propagate the decision on leap [whatever] scheduling to wherever it has to be carried out (NTP is *not* the critical path there, I'd guess) and b) the (ever-improving) quality of *prediction* of Earth's rotation. If those two restrictions were to be removed (assume a giant tooth fairy if you must ;-), I don't see a reason why the current UT1-UTC delta could not be communicated through an NTP-ng in the same way today's NTP shoves server-client deltas around and corrects for them - piecemeal with every poll. (Returning to your question as phrased, and circumstances as of today: IIUC the quality of prediction *would* already suffice to attempt scheduling leap seconds so as to aim for min-sum-of-squares, rather than predefined schedule slots.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On Tue, Jun 24, 2014 at 12:08:10PM +0200, Jochen Bern wrote: I've browsed the results of the infamous poll and most of the people voting abolish leap seconds apparently didn't mean to actually *abolish* them (as in, decouple UT1 and UTC, or whatever their successors might be called), but to have them *rearranged* into fewer and larger leaps. Of course, one can imagine that to go the other way - i.e., smaller but more frequent leaps. As someone who implemented support for leap seconds in several applications, I'd really like to see them gone. Fixing all software where time is critical to handle them correctly may not be possible and from what I've heard a common solution is just to turn it off and wait until it passes. Making smaller but more frequent corrections would probably only make it worse. To me, it seems the reasonable thing to do would be to decouple UTC and UT1 completely and make the adjustment at a higher level like timezones if necessary. Countries adjust their timezones all the time, we can handle that better. (Returning to your question as phrased, and circumstances as of today: IIUC the quality of prediction *would* already suffice to attempt scheduling leap seconds so as to aim for min-sum-of-squares, rather than predefined schedule slots.) Good point. The question is if they will ever choose to do that. Thanks, -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Jochen Bern writes: If those two restrictions were to be removed (assume a giant tooth fairy if you must ;-), I don't see a reason why the current UT1-UTC delta could not be communicated through an NTP-ng in the same way today's NTP shoves server-client deltas around and corrects for them - piecemeal with every poll. And have UTC jump around as erratically as does the Earth's rotation? Why? Might as well set up a tranit and set your clock by the sun. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, Miroslav Lichvar wrote: As someone who implemented support for leap seconds in several applications, I'd really like to see them gone. Fixing all software where time is critical to handle them correctly may not be possible So your POV is that of someone managing computers who sees the attempts to sync a technical notion of time to the movement of the planet somewhere under your feet as breaking features like monotonicity and continuity of the computers' genuine clocks. While I may have started from the same setting, I *did* try to put myself into the shoes of astronomers and people operating satellite systems (which, ironically, includes the popular stratum 0 of GPS). There's not much you can do about the fact that users tend to be mostly friction locked to the surface of the planet while satellites and celestial bodies are not, short of outright denial and perpetual puzzlement why your models refuse to work properly. Personally, I'd say that if a computer's clock's best suited to run on TAI (or equivalent) and all data needs to be converted from it to $TZ for the users, anyway, then having it run on TAI and disseminating and handling a TAI-UTC delta along with the sync and timezone deltas seems like the proper approach. But that wish doesn't change gettimeofday() implementations all over the globe with a snap of my fingers, does it. Making smaller but more frequent corrections would probably only make it worse. That depends on your definition of worse. Results in lower max offsets (that mechanisms like NTP will silently take care of) seems to be a quite popular definition of better, FWIW. To me, it seems the reasonable thing to do would be to decouple UTC and UT1 completely and make the adjustment at a higher level like timezones if necessary. Countries adjust their timezones all the time, we can handle that better. I've seen enough platforms allowed access to a (local) NTP server but not updates, enough such platforms being considered secure(d into a world of their own) enough not to be updated, enough devices whose owners never thought of firmware updates to even *exist*, yadda yadda to assert that the better mechanism of making that data part of regular but fundamentally *optional* OS updates (instead of a well-defined, verifiably secure or at least harmless, dedicated on-demand communication protocol) is downright *nonfunctional* often enough. Too many people expect their devices to usually tell them the right time (:= as per local timezone) with naught but an occasional setting it right (:= manually inserting a single delta with no understanding of the background mechanisms involved) to make you should have updated every now and then an accepted excuse for those devices giving themselves airs of being computers instead (caution, irony). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On Tue, Jun 24, 2014 at 03:46:15PM +0200, Jochen Bern wrote: While I may have started from the same setting, I *did* try to put myself into the shoes of astronomers and people operating satellite systems (which, ironically, includes the popular stratum 0 of GPS). Do these people work just with UTC? I'd think it's not accurate enough for their purposes and they need to include the current UTC-UT1 offset anyway. Personally, I'd say that if a computer's clock's best suited to run on TAI (or equivalent) and all data needs to be converted from it to $TZ for the users, anyway, then having it run on TAI and disseminating and handling a TAI-UTC delta along with the sync and timezone deltas seems like the proper approach. But that wish doesn't change gettimeofday() implementations all over the globe with a snap of my fingers, does it. Agreed, but wouldn't switching to TAI everywhere be much more difficult than stopping messing with UTC and keep it a fixed offset from TAI? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Jochen Bern jochen.b...@linworks.de wrote: While I may have started from the same setting, I *did* try to put myself into the shoes of astronomers and people operating satellite systems (which, ironically, includes the popular stratum 0 of GPS). Note that while those people would like to keep UTC in sync with sun time, they already have to live with the fact that it isn't. Or do you think that the insertion of a leap second now and then gives them sufficient accuracy at any moment? They already have to work with the difference between UTC and sun time and that it steps by a second every few years. When this stepping would end and the difference would accumulate, that would not make the situation more difficult for them than it already is. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, John Hasler wrote: Jochen Bern writes: If those two restrictions were to be removed (assume a giant tooth fairy if you must ;-), I don't see a reason why the current UT1-UTC delta could not be communicated through an NTP-ng in the same way today's NTP shoves server-client deltas around and corrects for them - piecemeal with every poll. And have UTC jump around as erratically as does the Earth's rotation? Why? Might as well set up a tranit and set your clock by the sun. The premise of this statement was to describe a scenario where the UT1-UTC offset as known by random devices would be updated as often as imaginable. Whether your local clock should then attempt to approximate UTC, some variant of UTC with different (upstream) leap [whatever] decisions, actual infinitesimal (and locally-known-only) leaps a.k.a. UT1, or a leapful time based on that latter and rules how to quantize the drift into a (again locally-known-only) sufficiently small leap, is a *somewhat* separate question. I don't know of any telecopes, satellite dishes, ... with an aperture / beam so narrow as to being forced to have the tracking mechanism based on UT1 instead of UTC, but that doesn't mean that there *are no* cases where you need a better realtime approximation of UT1 (preferably *without* setting up your own transit observation gear), and possibly *still* having UTC as well (say, for logging). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, Miroslav Lichvar wrote: On Tue, Jun 24, 2014 at 03:46:15PM +0200, Jochen Bern wrote: While I may have started from the same setting, I *did* try to put myself into the shoes of astronomers and people operating satellite systems (which, ironically, includes the popular stratum 0 of GPS). Do these people work just with UTC? I'd think it's not accurate enough for their purposes and they need to include the current UTC-UT1 offset anyway. I'm pretty sure that you cannot operate a system like GPS without having a better idea of UT1 than UTC, even if (IIRC) the satellites' downlinks do not disseminate that data to the terminal units. No idea whether looking at the USNO data once a week or day does suffice. All I can say is that transit measurements are, by definition, not available as often as one might like. I don't think that anyone dealing with communication satellites (i.e., in orbit around Earth) or a telescope smaller than a house needs to bother with UT1-UTC beyond the max offset guarantees currently in effect, though. Personally, I'd say that if a computer's clock's best suited to run on TAI (or equivalent) and all data needs to be converted from it to $TZ for the users, anyway, then having it run on TAI and disseminating and handling a TAI-UTC delta along with the sync and timezone deltas seems like the proper approach. But that wish doesn't change gettimeofday() implementations all over the globe with a snap of my fingers, does it. Agreed, but wouldn't switching to TAI everywhere be much more difficult than stopping messing with UTC and keep it a fixed offset from TAI? Having computer clocks run on UTC(frozen) instead of TAI makes the adaptation easier today, more difficult tomorrow (do we *really* need to work on that for (n3) seconds of an offset!?), and no less necessary in the long run (when UT1-TAI has grown much larger than UT1-UTC(frozen), and changes much faster as well). I prefer to have the slope right where the ball needs to get rolling. ;-) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Miroslav writes: Do these people work just with UTC? I'd think it's not accurate enough for their purposes and they need to include the current UTC-UT1 offset anyway. I believe that astronomers use Terrestrial Time, which is defined in terms of TAI. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Jochen Bern writes: I don't know of any telecopes, satellite dishes, ... with an aperture / beam so narrow as to being forced to have the tracking mechanism based on UT1 instead of UTC, but that doesn't mean that there *are no* cases where you need a better realtime approximation of UT1 (preferably *without* setting up your own transit observation gear), and possibly *still* having UTC as well (say, for logging). Astronomers use TT for logging. I believe that they see such things as variations in the Earth's rotation as systematic errors to be corrected and have a system for distributing the relevant data. They certainly need detailed knowledge of the motion of the Earth but I don't think that they consider it the definition of correct time. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Jochen Bern jochen.b...@linworks.de wrote: While I may have started from the same setting, I *did* try to put myself into the shoes of astronomers and people operating satellite systems (which, ironically, includes the popular stratum 0 of GPS). Note that the GPS system does not use UTC. GPS has its own clock and broadcasts the current offset of UTC relative to that clock. This offset changes every time the silly leap second thingy is done. The GPS clock keeps ticking as before. Maybe computers should just use GPS time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Jochen Bern writes: Having computer clocks run on UTC(frozen) instead of TAI makes the adaptation easier today, more difficult tomorrow How? You just start distributing the leap second corrections in the zone files. Much simpler and no more need for flag days. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On 24/06/14 17:25, Jochen Bern wrote: I'm pretty sure that you cannot operate a system like GPS without having a better idea of UT1 than UTC, even if (IIRC) the satellites' downlinks do not disseminate that data to the terminal units. No idea whether I assume the DUT1 information is implicit in the ephemeris data. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On 6/24/2014 5:59 AM, Miroslav Lichvar wrote: To me, it seems the reasonable thing to do would be to decouple UTC and UT1 completely and make the adjustment at a higher level like timezones if necessary. You're doing it wrong. If you don't want leap seconds, use a timescale which doesn't have them (e.g. TAI, GPS). UTC was created to closely track Sol. Decoupling that breaks its purpose, and the promise made when it took over from GMT. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On 6/16/2014 6:05 AM, Jochen Bern wrote: There are four official slots - two primary, two secondary - over the course of the year to insert leap seconds, Those are only preferences. Leap seconds may be inserted at any month boundary. A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. - ITU-R TF.460-6 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
Brian Inglis wrote:
BlackLists wrote:
restrict -4 default limited kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict ::1
restrict 224.0.1.1 mask 255.255.255.255 nomodify
restrict source nomodify
These above lines are relevant regardless of a static IP;
{Many of them are perhaps necessary if you are going to
expose your NTP server to the internet.}
restrict aa.bb.cc.dd mask ww.xx.yy.zz nomodify # your LAN
Only this one line is relevant to a static IP. -^
FYI thought this could be handy info,
but untested as I do not have a static IP:
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
brian.cun...@gmail.com wrote:
Is there a suggested way to rate-limit queries by broken clients?
Firewall rules?
{Depends how broken the remote client is,
sometimes this makes them hammer more,
if you can get you ISP to block them at the ISP's end,
at least it won't cost you bandwidth.
Use a unique subdomain for your ntp server,
so you can make it resolve to something else,
or not resolve if needed.
Are there any other techniques people have found to be helpful?
https://manage.ntppool.org/manage/servers
Set connection Speed
set it to something lower, 384K?
and wait _many_ weeks then redo your statistics.
restrict -4 default limited kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict ::1
restrict 224.0.1.1 mask 255.255.255.255 nomodify
restrict aa.bb.cc.dd mask ww.xx.yy.zz nomodify # your LAN
restrict source nomodify
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
On 2014-06-18 13:32, E-Mail Sent to this address will be added to the
BlackLists wrote:
http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
brian.cun...@gmail.com wrote:
Is there a suggested way to rate-limit queries by broken clients?
Firewall rules?
{Depends how broken the remote client is,
sometimes this makes them hammer more,
if you can get you ISP to block them at the ISP's end,
at least it won't cost you bandwidth.
Use a unique subdomain for your ntp server,
so you can make it resolve to something else,
or not resolve if needed.
Are there any other techniques people have found to be helpful?
https://manage.ntppool.org/manage/servers
Set connection Speed
set it to something lower, 384K?
and wait _many_ weeks then redo your statistics.
restrict -4 default limited kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict ::1
restrict 224.0.1.1 mask 255.255.255.255 nomodify
restrict aa.bb.cc.dd mask ww.xx.yy.zz nomodify # your LAN
restrict source nomodify
FYI thought this could be handy info, but untested as I do not have a static IP:
# Linux kernel 2.3.15+ CONFIG_NETFILTER `Y'
# iptables/ip6tables
# http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html
# NTP monlist LOG rule 1/minute
-A PREROUTING -p udp -m udp --ports ntp \
-m u32 --u32 0220x3C@80xFF=42 -m limit --limit 1/m --limit-burst 1 \
-j LOG --log-prefix BLOCKED: NTPMONLIST
# NTP monlist DROP rule
-A PREROUTING -p udp -m udp --ports ntp -m u32 --u32 0220x3C@80xFF=42 -j DROP
# NTP input drop more than 8p/16s = 10p/20s
# modprobe.conf - options xt_recent ip_list_tot=1 ip_pkt_list_tot=12
# insmod xt_recent
# modinfo xt_recent
# or
# echo 1 /sys/module/xt_recent/parameters/ip_list_tot
# echo 12 /sys/module/xt_recent/parameters/ip_pkt_list_tot
-A INPUT -p udp -m udp --dport ntp -m recent --name ntprate --rsource --set
# NTP drop more than 8p/16s = 10p/20s LOG rule 1/minute
-p udp -m udp --dport ntp \
-m recent --name ntprate --rsource --update --seconds 20 --hitcount 10 \
-m limit --limit 1/m --limit-burst 1 \
-j LOG --log-prefix DROPPED: NTPRATE
# NTP drop more than 8p/16s = 10p/20s DROP rule
-A INPUT -p udp -m udp --dport ntp \
-m recent --name ntprate --rsource --check --seconds 20 --hitcount 10 \
-j DROP
# check /proc/net/xt_recent/ntprate
# NTP accept NEW,ESTABLISHED
-A INPUT -p udp -m udp --dport ntp -m state --state NEW -j ACCEPT
-A INPUT -p udp --sport ntp -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -p udp --dport ntp -m state --state NEW,ESTABLISHED -j ACCEPT
# HeartBleed LOG rule 1/minute
-A INPUT -p tcp --dport https \
-m u32 --u32 52=0x1803:0x1803 -m limit --limit 1/m \
-j LOG --log-prefix BLOCKED: HEARTBEAT
# HeartBleed DROP rule
-A INPUT -p tcp --dport https -m u32 --u32 52=0x1803:0x1803 -j DROP
# HeartBleed Wireshark rules
#tshark -i interface port https -R 'frame[68:1] == 18'
#tshark -i interface port https -R 'ssl.record.content_type == 24'
--
Take care. Thanks, Brian Inglis
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
David Woolley wrote: On 15/06/14 15:16, Jason Rabel wrote: On a related note, is there any way to determine if the requests are made by ntpdate vs ntpd? I realize ntpdate is depreciated but ntpdate cannot send a valid stratum or reference time. Strictly speaking it should obey the SNTP rules and send most of the fields as 0. I don't know if it actually conforms with the SNTP request requirements, but repeated requests with a reference timestamp of zero would indicate ntpdate or SNTP. You can also check for port 123 as both the source and target port, this shows up very clearly in my ntpq -nc mrulist requests: Pretty much all true ntpd clients show up in that table using 123 as the source port, while all the sntp/ntpdate request use some random high port number. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, Jason Rabel wrote: Yes, every now and then I too, like the OP, will see huge spikes in my packets received/sent that occur at or very close to an on-hour mark at particular times (like midnight or 4 am), my guess is a poor implementation in a router somewhere. I've never had the time to track it down though because it occurs so infrequently I guess that you *would* have noticed if it were *that* regular, but just in case: There are four official slots - two primary, two secondary - over the course of the year to insert leap seconds, and since there (sadly) is no requirement for stratum 1 servers to raise the leap flags early enough to guarantee that that info will drizzle all the way to stratum 14 at maximum poll intervals, (at least some versions of) ntpd poll(s) more frequently as these slots approach. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
brian.cun...@gmail.com brian.cun...@gmail.com wrote: Hi All, Is there a suggested way to rate-limit queries by broken clients? There isn't any. In fact, many methods to do that are likely to make the problem worse. For example, people suggest to limit the number of queries answered or even to send KOD packets. However, broken clients don't implement KOD and think they just got a damaged answer that they can fix by asking again. And when they don't get an answer on their query they often re-try. The re-try interval may be even shorter than the usual interval between polls. There is really nothing you can do from the serverside to affect the upstream bandwidth usage by clients. When you have to pay for traffic and you cannot afford it, the best solution is to go out of the pool. (and even that will not help immediately, as client software often does a DNS lookup at startup and then keeps using the same IP address until restarted. you will see gradually decreasing traffic, but there may be clients that are still there after a year or more) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On 15/06/14 15:16, Jason Rabel wrote: On a related note, is there any way to determine if the requests are made by ntpdate vs ntpd? I realize ntpdate is depreciated but ntpdate cannot send a valid stratum or reference time. Strictly speaking it should obey the SNTP rules and send most of the fields as 0. I don't know if it actually conforms with the SNTP request requirements, but repeated requests with a reference timestamp of zero would indicate ntpdate or SNTP. (Broken thread) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Jason Rabel writes: On a related note, is there any way to determine if the requests are made by ntpdate vs ntpd? I realize ntpdate is depreciated but it is still used (or a hacked down version) by a lot of routers, and many distros still include it too. Not that I'm aware of - each sends a normal NTP query request. Ditto for the sntp code. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
Hi All, Is there a suggested way to rate-limit queries by broken clients? Running an NTP Pool Server costs me $40/month in Amazon AWS Outbound Bandwidth (if you want the full scoop, read here: http://pivotallabs.com/ntp-server-costing-500year/ ). I suspect that broken NTP clients are part of the problem (for example, 2 IP addresses in Puerto Rico query my server on the average 11.5 times per second--eliminating just those 2 would save me almost $1/month). Are there any other techniques people have found to be helpful? I like running a server for the NTP Pool, I just don't want to spend a lot of money doing it. Thanks, --Brian p.s. No, my server isn't being used in a reflection attack: monlist is disabled, and the NTP traffic load is symmetric. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
On 2014-06-14 12:59, brian.cun...@gmail.com wrote: Is there a suggested way to rate-limit queries by broken clients? Running an NTP Pool Server costs me $40/month in Amazon AWS Outbound Bandwidth (if you want the full scoop, read here: http://pivotallabs.com/ntp-server-costing-500year/ ). I suspect that broken NTP clients are part of the problem (for example, 2 IP addresses in Puerto Rico query my server on the average 11.5 times per second--eliminating just those 2 would save me almost $1/month). Are there any other techniques people have found to be helpful? I like running a server for the NTP Pool, I just don't want to spend a lot of money doing it. p.s. No, my server isn't being used in a reflection attack: monlist is disabled, and the NTP traffic load is symmetric. Everyone should have restrict default kod limited... but often this is boneheaded configuration or bad rookie software, that does not respect the KOD packets or RATE codes, as others have found, so other than asking AWS to block those abusers, you can only take down that name and address (many bozos prefer using IP addresses, for many bozo reasons; as opposed to engineers using IP addresses for engineering reasons), and set up another or elsewhere. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is there a suggested way to rate-limit?
On 2014-06-14 12:59, brian.cun...@gmail.com wrote: Is there a suggested way to rate-limit queries by broken clients? Running an NTP Pool Server costs me $40/month in Amazon AWS Outbound Bandwidth (if you want the full scoop, read here: http://pivotallabs.com/ntp-server-costing-500year/ ). I suspect that broken NTP clients are part of the problem (for example, 2 IP addresses in Puerto Rico query my server on the average 11.5 times per second--eliminating just those 2 would save me almost $1/month). Are there any other techniques people have found to be helpful? I like running a server for the NTP Pool, I just don't want to spend a lot of money doing it. p.s. No, my server isn't being used in a reflection attack: monlist is disabled, and the NTP traffic load is symmetric. Everyone should have restrict default kod limited... but often this is boneheaded configuration or bad rookie software, that does not respect the KOD packets or RATE codes, as others have found, so other than asking AWS to block those abusers, you can only take down that name and address (many bozos prefer using IP addresses, for many bozo reasons; as opposed to engineers using IP addresses for engineering reasons), and set up another or elsewhere. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Brian, A few things you did not mention in your post or your article... What bandwidth setting (Net Speed) did you specify on the NTP Pool website for your server? What Zone(s) is it listed in? Also, can you provide a link to your NTP Pool server's page? The URL would look something as follows (this is my server): http://www.pool.ntp.org/scores/216.230.228.242 I have my net speed set to 10Mbit and my server averages about 20 NTP packets per second and can peak up to 70/sec under normal traffic. I could bump it higher, my colo'ed server includes 10TB of bandwidth a month (and I'm nowhere near that), but I prefer to incrementally bump it up and see how traffic is affected. What does your NTP configuration look like? Specifically any 'restrict' and 'discard' lines would be most helpful. As someone else already posted, you should have some minimal settings configured to prevent someone 'pounding' your server, please check the following page: http://www.eecis.udel.edu/~mills/ntp/html/accopt.html There seems to be a lot of discussion about whether to use the KoD setting or not (for various reasons). I personally fall into the group that prefers / recommends NOT to use that variable and instead use various rate limiting methods to prevent abuse (whether intentional or accidental). If you are running Linux you can do rate limiting with iptables rather easy too. No client should be querying more than once every second (or maybe it's every 2 seconds), that is the speed iburst does. Regular query intervals would be much longer. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
Jason Rabel writes: No client should be querying more than once every second (or maybe it's every 2 seconds), that is the speed iburst does. Regular query intervals would be much longer. Yes, and remember we live in a world of NAT. While there is much to be said for running your NTP servers that talk to outside NTP servers and having all of your other NTP clients talk to your NTP servers, some folks don't do this, and that means their clients can send a lot of queries to external servers and these requests will be coming from (different ports from) a single IP address (due to NAT). Then again, there are also broken implementations out there that will badly misbehave. It would be useful to see if there was any way to identify what's going on with the culprit IPs. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
