"rotor...@yahoo.com" <rotord...@gmail.com> writes: >On Oct 7, 6:19=A0am, Terje Mathisen <terje.mathi...@tmsw.no> wrote:
>> > I still have to allow for the general case, where for N servers, >> > N-1 go offline while the last returns bad inputs to the system. >> >> No, you do not! >I am told that I do. And if you were told that you have to defend against the moon exploding and half of it hitting the earth, would you post asking for advice on how to do so? Note that as others have said, if you are worried that the ntp servers are out of your control, set up 5 servers across the country, controlled by you, using GPS signals to discipline those machines, and use those as some/all of your external ntp sources. That way you do not have to worry about whether some outsider is incompetent. You only have to worry about your own incompetence. Since I have no idea what your organisation is, I do not know whether I would bet on your competence over outsider's competence. The requirements you are being handed are simply getting silly, and no advice we can give you will make them less silly. >Look at it this way: We produce a system (in the form of a >cluster) that works today, but that can drift away from UTC since >it currently doesn't accept any external time reference. That >drift isn't a huge issue, but over the multi-year lifespan of the >hardware, can be significant. No, given the requirements you are imposing on the external source your system does NOT work. You do not have protection against multiple failures of your clusters. You se some N clocks on your internal clusters as the time sources. What happpens if N of them fail. This HIGHLY likely, since on of the failure modes is a fire in the cluster room. The likelihood of N external systems failing is far far less. But for your own cluster " Look we have run it for a year and it has worked fine" is a good argument. For external servers apparently it is not. >If we allow the use of external NTP servers, we now have opened >up what was a closed system, and must prevent that new input >source from causing instability. It is a fundamental security Agreed. But you do not have to prevent it absolutely. You have to prevent it to the extent that the probability of it introducing instability is less than the probability that your system will go unstable on its own. You have to do a comparitive analysis. It sounds to me like at present it is "Our own systems have been fine ( we discount that one system that never worked properly) for the past year, so our assumption is our own system has zero probability of failure. The big world outside is a scary place so the probabilityof failure there is 1% ( ior soem other made up number). Thus the outside world is far more likely to be a problem. >requirement that you guard against broken or even malicious >input. (Think SQL injection, etc.) An alternate approach would be IF it is malicious input you need to guard against, then that is a different matter. Use authentication. >to make our cluster software resilient to intra-node time variations, >but it was deemed simpler to use NTP to have the cluster accept >an external UTC source. Clearly, simpler doesn't equal simple here. >> If you insist that you have to do this, and cannot have any independent >> internal ref clocks, then you are simply trolling, since your (always >> subtly changing) requirements change each time we suggest something. >My requirements haven't changed at all, and I don't think there's >anything >I've added as a clarification that has contradicted earlier >statements. If >they have, one or the other was in error. >I think what I've come to realize from all this is that while the NTP >protocol >can be used, the current reference implementation probably will not >meet >our requirements. I thought that may be the case, since our highest No. You have no requirements, or rather what you think they are are based on magical thinking, and not science. >priority requirement for a consistent cluster time across all nodes >rather >than any fidelity to UTC is somewhat orthogonal to those of the ntpd >reference implementation. (and of ntp in general perhaps) No, the ntp reference implimentation is based on the idea that if N machines are all synced to UTC, then they are all synced to each other as well. Ie, the best way to synchronize a bunch of systems to each other is to sync them to a common reference. You believe that if you sync them to a subset of your own machines that is better than syncing them to a standard. UTC has a huge army of people ( literally an army) to ensure that that standard is maintained and accurate and is not subverted, even in the case of a nuclear war. You have 5 people who are not really sure about time standards trying to devise a system that will maybe be proof against someone leaving teh bathroom tap running ( but probably is not). Whom would I trust to keep my computers synched? >And while a hardware time source would cleanly solve the issue, >it isn't feasible to retrofit that to thousands of existing >installations. >Even if it were $500, there is the expense of getting it installed >into >thousands of commercial data centers. Which would be a logistical >nightmare, given issues of leased spaces, being deep inside >skyscrapers, etc. It isn't always as simple as sticking a GPS antenna >to a window. So, set up 10 places around the world which ARE synched to UTC or GPS ( for a cost of say $5000) and use those as your external ntp servers for your thousands of commercial data centers. Those 10 will have clocks which are within microseconds of utc. >As to trolling, as I mentioned previously, I'm willing to hire >someone with the the right level of expertise as a consultant. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
