Re: [ntp:questions] Asymmetric Delay and NTP
Magnus, In article 532fa47b.7060...@rubidium.dyndns.org, Magnus Danielson mag...@rubidium.dyndns.org wrote: Joe, On 23/03/14 23:20, Joe Gwinn wrote: Magnus, In article 532e45db.5000...@rubidium.dyndns.org, Magnus Danielson mag...@rubidium.dyndns.org wrote: Joe, On 21/03/14 17:04, Joe Gwinn wrote: [snip] It is interesting. I've now read it reasonably closely. The basic approach is to express each packet flight in a one-line equation (a row) in a linear-system matrix equation, where the system matrix (the A in the traditional y=Ax+b formulation, where b is zero in the absence of noise), where A is 4 columns wide by a variable number of rows long (one row to a packet flight), and show that one column of A can always be computed from the two other columns that describe who is added and subtracted from who. In other words, these three columns are linearly dependent on one another. The forth column contains measured data. This dependency means that A is always rank-deficient no matter how many packets (including infinity) and no matter the order, so the linear system cannot be solved. It is just another formulation of the same equations I provided. For each added link, one unknown and one measure is added. For each added node, one unknown is added. True, but there is more. Let's come back to that. As you do more measures, you will add information about variations the delays and time-differences between the nodes, but you will not disclose the basic offsets. Also true. The advantage of the matrix formulation is that one can then appeal to the vast body of knowledge about matrixes and linear systems. It's not that one cannot prove it without the matrixes, it's that the proof is immediate with them - less work. And the issue was to prove that no such system could work. As much as I like matrix formulation, it ain't giving you much more in this case, rather than a handy notation. The trouble is that beyond the properties of the noise, there is no information leakage about the static time-errors and asymmetries. You end up having free variables. Yes. You correctly noted the mathematical equivalence of the two approaches, and I agree. My point was that the matrix approach is less work to get to the desired proof because by formulation as a linear solution with matrixes, one immediately inherits lots of properties and proofs. The problem is that the unknown and the relationships builds up in an uneven rate, and the observations only relate to two unknowns. The only trustworthy fact we get is the sum of the delays, but no real hint about its distribution. If you do more observations along the same paths, you can do some statistics, but you won't get un-biased result without adding a prior knowledge one way or another. Formulate it as you wish, but as you add more observations, those will be reduced to by their linear properties to equations existing and noise. You need to add observations which does not fully reduce in order for your equation system to grow to such size that you can solve it. Yes, this is a good statement of the consequences of the proof. Show me how you achieve it, and I listen. I don't understand the challenge. There is no dispute. The no matter the order part comes from the property of linear systems that permuting the rows and/or columns has no effect, so long as one is self-consistent. So far, I have not come up with a refutation of this approach. Nor have the automatic control folk - this proof was first published in 2004 into a community that knows their linear systems, and one would think that someone would have published a critique by now. The key mathematical issue is if there are message exchange patterns that cannot be described by a matrix of the assumed pattern. If not, the proof is complete. If yes, more work is required. So far, I have not come up with a counter-example. It takes only one to refute the proof. It is only by cheating that you can overcome the limits of the system. Is GPS cheating? That's our usual answer, but GPS isn't always available or possible. If you are trying to solve it within a network, it is. You can convert your additional GPS observation into an a prior knowledge, and once you done enough of those, then you can solve it completely. The estimated variables better stay static thought, or you have to start over again. GPS is the usual answer, but isn't always available or useful. Recall that the original question was random asymmetry due to asymmetric background traffic in a PTP network. If the network is controllable, a lab experiment is to simply turn the background traffic off and see how much the clocks change with respect to one another. But this tells one how much trouble one is in, but does not solve the problem. The solution will be found in better choice
Re: [ntp:questions] Quality vs. Quantity
On Mon, Mar 24, 2014 at 12:26 AM, Danny Mayer ma...@ntp.org wrote: That's a misconception. While I trust Richard Schmidt in what he says, that's is not what you think he says. It's hard to misinterpret 590SG load balancers and : It is the load balancer's duty to assign each incoming NTP request to one of the available servers, balancing the load by round-robin, weighted round-robin, least active connections, or other algorithm. Each NTP server returns packets to the load balancer for forwarding back to the requestor. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
(I inadvertently sent this only to Terje Mathisen) On Sun, Mar 23, 2014 at 12:07 AM, Danny Mayer wrote: What do you mean by load-balancing? NTP cannot be load-balanced. Of course it can (at some cost). On Sun, Mar 23, 2014 at 3:43 AM, Terje Mathisen wrote: You really do NOT want load-balancing of ntp servers!!! Ideally the server would manage this but address based load balancing (presumably as practiced by USNO) solves some problems. DNS balancing (viz. time.nist.gov or pool.ntp.org) is pretty weak but some of that can be mitigated in the server. Still I'd rather have three IP addresses fronting 300 servers than three IP addresses fronting three servers assuming the goal is resilient remote service. But I might still question the assumptions of the OP (the question is unclear) since I expect the number of queries to central public infrastructure to decline over time as the number of clients decrease. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On 03/24/2014 03:53 PM, Paul wrote: On Mon, Mar 24, 2014 at 12:26 AM, Danny Mayer ma...@ntp.org wrote: That's a misconception. While I trust Richard Schmidt in what he says, that's is not what you think he says. It's hard to misinterpret 590SG load balancers and : It is the load balancer's duty to assign each incoming NTP request to one of the available servers, balancing the load by round-robin, weighted round-robin, least active connections, or other algorithm. Each NTP server returns packets to the load balancer for forwarding back to the requestor. But I wonder what an active connection is in this context, since NTP sits atop UDP. Do the load balancers track whether an association has been mobilised, and if so do they ensure that a particular client is always served by the same server, at least if the poll interval is reasonable? Jan ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On Mon, Mar 24, 2014 at 11:18 AM, Jan Ceuleers jan.ceule...@computer.orgwrote: But I wonder what an active connection is in this context, since NTP sits atop UDP. These are IP based not TCP/IP. Do the load balancers track whether an association has been mobilised They could although the packet inspection code on devices like this (I'm not familiar with the CAI boxes) tends toward HTTP not NTP. , and if so do they ensure that a particular client is always served by the same server, at least if the poll interval is reasonable? That seems unlikely. But we know that the major problems are congestion (which load balancing is fixing) and weak system clocks. Presumably a bit of care would cause the inside-NIST-errors to be swamped by the outside-NIST-errors. And in fact the point of the paper is using PTP with the end result that the intra-farm errors should (it's four years later maybe they are) be in the nano-seconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] USTiming.org and Certichron sites out for a week
On Saturday, February 22, 2014 9:19:51 AM UTC-8, Brian Inglis wrote: Anyone know why USTiming.org and Certichron sites have been down for the last week? Nothing relevant mentioned on Google or any lists. Wondered if they might have been blocked as a reflector of recent DDoS attacks? -- Take care. Thanks, Brian Inglis The Certichron DNS servers got a DDoS attack against them. We apologize - please use the native time server addresses until they are replaced later this week. If you need to contact us about these - try my tglas...@certichron.com or todd@perseustelecom address to get to me. or hostmas...@certichron.com to get to all of the support team. Again this WILL be resolved post haste. Todd Glassey - USTiming.ORG ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] USTiming.org and Certichron sites out for a week
On Mon, Mar 24, 2014 at 12:08 PM, toddglas...@gmail.com wrote: The Certichron DNS servers got a DDoS attack against them. We apologize - please use the native time server addresses until they are replaced later this week. Please tell us it was an NTP amplification attack. Is your web problem related to this as well? www.certichron.com Welcome to certichron.com Learn how you can get this domain ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On 23.03.2014 03:24, questions-requ...@lists.ntp.org digested: From: Daniel Quick daniel.qu...@gmail.com Do we want a Netspeed setting that assists with taking the load off some of the more heavily, higher-speed servers? or do we want to keep a setting where we serve fewer clients with the highest resolution of time given specific setup and let the client queries grow from there? I suppose this also takes into the smart dns load-balancing that goes on in the background. IMHO the answer to that question changes *a lot* for different kinds of clients. To take one extreme example, if we're talking about appliances which can possibly run for years without a reboot and decades without getting updates installed (but still shall be supported indefinitely), the appropriate precaution would IMHO be to avail yourself of a good-sized chunk of PI IP addresses and have the clients distributed over them DNS-round-robin-style right from day one. The option of having all those different addresses NATed (*) to a farm of servers whose numbers adapt to the actual load follows trivially. If those same appliances are manufactured in numbers you can control, and will mostly or forcibly-all receive and install updates you publish, on the other hand, you can plan for and maintain hardware- and/or firmware-generation-specific sub-platforms on the server side. Note that that also allows you to cleanly transition clients between incompatible server versions - made-up example, switch data *signing* cryptalgorithms - if and when required. Off the other end of the spectrum, dealing with very few software-based senior-sysadmin-shepherded clients that have very high quality requirements IMHO strongly suggests that you want to invest the extra work to set them up with cryptographic authentication and individual key(pair)s, thus making a who the $#§ set up the FQDN 'pool.evil-ntp-underground.ddos.me' to point to our server!? scenario a lot less probable. Then there's possibilities like regional anycasts, running a *pool* of only your own sites, whether you have to deal with restrictive/static/non-DNS-aware client-side firewall configurations (or can have your appliances run a P2P NTP network to take load off your actual *own* servers ;- ), ... Regards, J. Bern (*) Or, if you're afraid that the initialization of NAT with the first client - server packet may introduce a net asymmetric delay, set up each server with umpteen public IPs. -- *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] Quality vs. Quantity
On 03/24/2014 04:58 PM, Paul wrote: On Mon, Mar 24, 2014 at 11:18 AM, Jan Ceuleers jan.ceule...@computer.org mailto:jan.ceule...@computer.org wrote: But I wonder what an active connection is in this context, since NTP sits atop UDP. These are IP based not TCP/IP. So there's even less of a notion of connection. And in fact the point of the paper is using PTP with the end result that the intra-farm errors should (it's four years later maybe they are) be in the nano-seconds. Yes, that's true. The OP wanted to know about NTP clusters, so I guess there are two lessons here: - either do what NIST did and ensure that your NTP cluster servers are so closely synced with each other that they are indistinguishable by clients; - or ensure that your load balancer ensures an association between clients and servers which persists for long enough (given the poll interval, probably to be multiplied by a safe factor, e.g. 3). Jan ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On 2014-03-24 08:53, Paul wrote: On Mon, Mar 24, 2014 at 12:26 AM, Danny Mayer ma...@ntp.org wrote: That's a misconception. While I trust Richard Schmidt in what he says, that's is not what you think he says. It's hard to misinterpret 590SG load balancers and : It is the load balancer's duty to assign each incoming NTP request to one of the available servers, balancing the load by round-robin, weighted round-robin, least active connections, or other algorithm. Each NTP server returns packets to the load balancer for forwarding back to the requestor. I hope that description is inaccurate, because of the additional delay and jitter added by passing twice through the front end. I would expect the load balancer to only provide the IP addresses of the currently lowest loaded and highest quality servers closest to the client, as the NTP Pool does. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
Paul G wrote: (I inadvertently sent this only to Terje Mathisen) On Sun, Mar 23, 2014 at 12:07 AM, Danny Mayer wrote: What do you mean by load-balancing? NTP cannot be load-balanced. Of course it can (at some cost). Obviously. As I noted plain ntp client requests, without signatures or any other stateful features, can indeed be serviced by multiple servers as long as they are all keeping the exact same (within the network timing jitter limits) time. In a national lab I'd assume that those S1 servers are kept at the sub-us level. On Sun, Mar 23, 2014 at 3:43 AM, Terje Mathisen wrote: You really do NOT want load-balancing of ntp servers!!! Ideally the server would manage this but address based load balancing (presumably as practiced by USNO) solves some problems. DNS balancing (viz. time.nist.gov or pool.ntp.org) is pretty weak but some of that can be mitigated in the server. Still I'd rather have three IP addresses fronting 300 servers than three IP addresses fronting three servers assuming the goal is resilient remote service. Even better would be 300 IP addresses fronting those 300 servers, with some form of round-robin DNS and the use of the pool directive by the clients. But I might still question the assumptions of the OP (the question is unclear) since I expect the number of queries to central public infrastructure to decline over time as the number of clients decrease. Huh? I'd rather expect the current trends to continue, with more and more gear starting to use (often very bad subsets of) the ntp protocol for time sync. In an idea world we would have lots lots of S1 and S2 servers all around the world, and all the clients would use 'pool' to automatically detect the best servers to connect to. 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] Quality vs. Quantity
On Mon, Mar 24, 2014 at 1:42 PM, Terje Mathisen terje.mathi...@tmsw.no wrote: Huh? I'd rather expect the current trends to continue, with more and more gear starting to use (often very bad subsets of) the ntp protocol for time sync. The fastest growing device (and for many many people the only) segment is mobile. They don't use NTP pool* resources. Apple devices use Apple servers (slowly). I expect most mobile devices get time from the mobile network (I don't know about random other tablets). I have appliances that use NTP. Some point to specific places, some use pool, some use DHCP and some let you specify via a web page. I don't think the future is the past where a few thousand misconfigured SOHO routers escape into the wild and grind someone down. It may not be fair to exclude zillions of machines using bootleg copies of windows but I do. In an idea world we would have lots lots of S1 and S2 servers all around the world, and all the clients would use 'pool' to automatically detect the best servers to connect to. In my ideal world the GPS everyone is carrying around would be an SNTP server for that person. *I still don't really understand the original question but perhaps it was about pool.ntp.org. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On Mon, Mar 24, 2014 at 1:37 PM, Brian Inglis brian.ing...@shaw.ca wrote: I hope that description is inaccurate, because of the additional delay and jitter added by passing twice through the front end. It may not be the case now but that would be an enormous error on the part of the authors. Well designed load balancers run at wire speed (at least up to 1G) and shouldn't add any more jitter than any other switch. By the way the 590SG only has four ports. Uplink, Downlink, Mirror and (probably) Manage. It probably has less jitter than the router it's plugged into. I would expect the load balancer to only provide the IP addresses of the currently lowest loaded and highest quality servers closest to the client, as the NTP Pool does. That's not what IP load balancers do. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
