Re: [ntp:questions] Roof antenna, which one, would you bother?
On 2014-03-22, David Taylor wrote: > On 03/01/2014 10:54, Ralph Aichinger wrote: >> I am currently in the process of remodeling my house >> and a dedicated outdoor/roof mounted GPS antenna >> would be possible to mount without excessive cost. >> >> I probably would not see a huge difference for >> timing purposes, but what would your choice of >> an outdoor GPS antenna/receiver be? I am planning >> to put the NTP server (small Raspberry Pi, nothing >> fancy) into a rack maybe 10 metres of cable length away >> from the roof. Or would you move the NTP host itself >> to the attic and run Ethernet up? >> >> I suppose something like the Garmin GPS 17x (mast mount >> GPS with serial output and PPS, intended for the marine >> market) would work fine, also be robust enough and >> cheap on the used market. >> >> Would mounting just an antenna (active or passive) also >> make sense, or would cable loss be too high? >> >> What would *your* roof top setup be? Cost is of course >> an important consideration, on the other hand, 100 >> or 200 Euros for the GPS, antenna and mounting hardware >> is probably OK. I would prefer to do cabling jobs now, >> while I am in the process of doing a lot of "dirty" things. >> >> Or would you not bother at all, and just put some puck into >> the window (which probably works too)? Yup. At work I have a gps in an east facing window looking out at the sky through a large Fir tree just outside the window. Sure gps receiver with its very very cheap antenna. Works fine. Gives the right location to within 3m (in time that would be 10ns) and the time. Ie, before I put the antenna into an inaccessible place (when it draps out on you after a few years-- two of my Garmin 18 s died after three years) I would test more accessible locations. >> >> TIA >> /ralph > > I would try with the Raspberry Pi with a GPS with built-in antenna in > the attic, running an Ethernet/power lead up to the attic. There are > some examples here: > >http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html > > You can get a no-soldering GPS for the Raspberry Pi which includes the > u-blox 7Q receiver (TCXO and PPS) and an SMA socket for a puck or > outdoor antenna as described here: > >http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#no-soldering > > In my own setup, I have several of those magnetic puck antennas just > within a room on the top floor of a two storey building, and one Garmin > GPS 18x LVC sitting on the roof. Lightning protection is not an issue here. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Asymmetric Delay and NTP
>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. What are the columns of your A matrix, and why do you assume they are linearly related? My point is that y=Ax+b can be solved even if it is rank-deficient, and the solution may even be unique. See http://en.wikipedia.org/w/index.php?title=Moore%E2%80%93Penrose_pseudoinvers e&oldid=600094895, the section entitled "Obtaining all solutions of a linear system." Have you considered what might happen if some entity, such as the US Naval Observatory, broadcast the time every second, on the second. Obviously, this would eliminate the asymmetrical delay problem. (It is known that time distribution on a LAN can be made substantially more accurate by broadcasting the time from a local server, in lieu of waiting for clients to ask for it. Broadcast mode works well on a LAN, and there is a special IP address for it, as there may also be for time broadcast over the Internet. It is in the NTP RFC.) Other factors you might consider is that every second has a name, and seconds have constant time apart. The first second this year was named Jan. 1, 2014 00:00:01, then a second later came second named Jan. 1, 2014 00:00:02, etc. Since the distance between the Naval Observatory and any given receiver is constant (as long as the receiver is not mobile), and the speed of light (s) is constant, let the distance between the Observatory and the receiver (dist) be measured in light-seconds. Then every packet received from the Observatory is essentially just a repeated measure of Jan. 1, 2014 00:00:01 since every second afterwards is related to that one by an integral multiple. Let d = the time received by the receiver minus the name of the second broadcast by the Observatory. Then let d^ be the mean of all the d's received so far. d^ is related to the physical distance (dist) by some constant factor a since the speed of light and the physical distance between the receiver and the Observatory are constant. Hence, isn't a*d^ + the name of the second broadcast by the Observatory the best estimate of the correct time the packet was received, and d^ - d an estimate of the flight time error? What I am trying to say here is IF you could get the government to broadcast the time over the Internet (and that is a big IF since all routers may not propagate NTP broadcasts) then could you not use the fact that the seconds are a constant second apart to get rid of a lot of the uncertainty in your equation y=Ax+b? Charles Elliott -Original Message- From: questions-bounces+elliott.ch=verizon@lists.ntp.org [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of Joe Gwinn Sent: Friday, March 21, 2014 12:04 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Asymmetric Delay and NTP Magnus, In article <532b5ab9.4070...@rubidium.dyndns.org>, Magnus Danielson wrote: > Joe, > > On 19/03/14 11:55, Joe Gwinn wrote: > > In article <5328aaa6.70...@rubidium.dyndns.org>, Magnus Danielson > > wrote: > > > >> On 18/03/14 01:36, Joe Gwinn wrote: > >>> In article <5327757e.5040...@rubidium.dyndns.org>, Magnus > >>> Danielson wrote: > >>> > Is that formal enough for you? > >>> > >>> It may be. This I did know, and would seem to suffice, but I > >>> recall a triumphant comment from Dr. Mills in one of his documentation pieces. > >>> Which I cannot recall well enough to find. It may be the above > >>> analysis that was being referred to, or something else. > >> > >> I can't recall. The above I came up with myself some 10 years ago or so. > > > > > > When I awoke the day after writing the above, I saw two problems > > with the above analysis. > > > > First is that with added message-exchange volleys, one does not get > > added variables and equations, one instead gets repeats of the > > equations one already has. If there is no noise, the added volleys > > convey no new information. If there is noise, multiple volleys > > allows one to average random noise out. > > True. What does happen over time is: > 1) Clocks drift away from each other due to systematics and noises > 2) The path delay shifts, sometimes because of physical distance > shifts, but also due to shift of day and season. > > These require continuous tracking to handle Yes. > > Second is that what is proven is that a specific message-exchange > > protocol cannot work, not that there is no possible protocol that > > can work. > > The above analysis
[ntp:questions] Quality vs. Quantity
While this should be obvious, I always have to ask how and why... While considering that the number of requests to our time servers will grow over time since the client decides which server to sync with. 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. Any input would be appreciated. Thanks, Daniel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On Sat, Mar 22, 2014 at 8:54 PM, Daniel Quick wrote: > While considering that the number of requests to our time servers will > grow over time since the client decides which server to sync with. > What if the number of queries over time is decreasing? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
Joe, On 21/03/14 16:17, Joe Gwinn wrote: Magnus, Thus, another fairly severe environment. I have a personal war story from 1992: At a Air Traffic Control center in Canada, one 19" cabinet had the green (safety ground) and white (power neutral) cables transposed. This caused 2.3 Vrms at 180 Hz to appear between the VMEbus ground and the cabinet shell, with enough oomph to cause a small spark when oscilloscope probe grounding clip was connected to that VMEbus ground, this causing the system (and my heart) to crash. If left connected, the ground clip became warm. And how can ground generate a spark, even a small one? Fixing the grounds dropped the offset to around ten millivolts. The 180 Hz arose because the power supplies were single-phase capacitor-input, driven from the legs of three phase prime power. Power neutral isn't really neutral when it takes a lot of beating. Similarly, a grounding wire isn't doing much grounding as frequency goes up. That fails economically - might as well stick to IRIG. Indeed. Doing 1 us level might be possible, going lower than that will cause you more and more grey hairs one way or another. Well, now, this could be an advantage -- my hair is already gray, and more could be better. Well, you may have younger colleagues which fails to have this advantage. I knew you would make the comment. :) There is a truism in the standards world, that it take three major releases (versions) of a standard for it to achieve maturity. PTP is at version 2, so one more to go. I'd say it depends on for what application. The trouble is when the assumed applications increase at a quicker rate than the standard adapts to handle them. It does, but having the market grow faster than the standards cycle can be the mark of success. To some degree. Being perceived to be a solution isn't the same as it being a solution. By the way, development of the third revision of 1588 started in 2013. I joined what purported to be their reflector, but now that you mention it I haven't gotten any traffic -- Something must be wrong. I will need to enquire. They formally had their first session at the ISPCS in Lemgo. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Asymmetric Delay and NTP
Joe, On 21/03/14 17:04, Joe Gwinn wrote: Second is that what is proven is that a specific message-exchange protocol cannot work, not that there is no possible protocol that can work. The above analysis only assumes a way to measure some form of signal. The same equations is valid for TWTFTT as for NTP, PTP or whatever uses the two-way time-transfer. What will differ is they way they convey the information and the noise-sources they see. It's certainly true that the two-way time transfer (including bouncing-packet) approach works well, and is widely used, but all are sensitive to asymmetry, and the overarching question was if this limitation is fundamental and thus unavoidable. It is. Thus, you need to handle it one way or another. As discussed later, it appears that the limitation is fundamental. Yes, it truely is. Will see if I can find Dave's reference. I hit pay dirt yesterday, while searching for data on outliers in 1588 systems. Dave's reference may well be in the references of the following article. "Fundamental Limits on Synchronizing Clocks Over Networks", Nikolaos M. Freris, Scott R. Graham, and P. R. Kumar, IEEE Trans on Automatic Control, v.56, n.6, June 2011, pages 1352-1364. Sounds like an interesting article. Always interesting to see different peoples' view of fundamental limits. 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. 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. To achieve that, you would need to bring correct time to one node and then observe that offset. Once measured the system increases. As you do this for all nodes, then calibration can be performed and the system be fully resolved. 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. Yes. In closed networks, the biggest cause of asymmetry I've found is interference between NTP traffic and heavy background traffic in the operating system kernels of the hosts running application code. Another big hitter was background backups via NFS (Network File System). The network switches were not the problem. What greatly helps is to have a LAN for the heavy applications traffic, and a different LAN for NTP and the like, forcing different paths in the OS kernel to be taken. If you can get your NIC to hardware time-stamp your NTP, you will clean things up a lot. True, but these were never much available, and the rise of PTP may obviate the need. Today PTP has made it available also for NTP. Hardware-timestamped NTP also exists and is commercially available. Although, if one goes to the trouble to make a NIC PTP-capable, it wouldn't be so hard to have it recognize and timestamp passing NTP packets. The hard part would be figuring out how to transfer this timestamp data from collection in the NIC to point of use in the NTP daemon, and standardizing the answer. The Linux-kernel has such support. NTPD has already some support for such NICs included. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On 3/22/2014 8:54 PM, Daniel Quick wrote: > While this should be obvious, I always have to ask how and why... While considering that the number of requests to our time servers will grow over time since the client decides which server to sync with. > > 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. What do you mean by load-balancing? NTP cannot be load-balanced. NTP does a lookup and gets a specific address and continues to use it every poll interval. If the server is unavailable then it doesn't matter since it also queries other servers and decides based on a number of factors which is likely to give the most accurate and precise timestamp at that moment. That changes as traffic, network congestion, availability changes and NTP will dynamically choose a different source for time. If the DNS has a number of addresses associated with a fully qualified domain name then NTP can take advantage of that and use all of them if you use the pool configuration option. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
