Re: [ntp:questions] NTP shared memory driver
> Yes, until you start getting ntpd to accept data samples from your SHM > > socket nothing will be working there. > So is there a way (something like a very verbose mode) that I can see that NTPD is reading from the shared memory (and is having problems maybe)? Because in the log file of NTPD there's nothing helpful. Many thanks, Claudio ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
mike cook wrote: Le 11 sept. 2014 à 21:08, Paul a écrit : On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote: Did I miss something? On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote: My home LAN is connected to my school's network via a cable modem. If we make the (safe) assumption of a common cable ISP/FiOS in the Palo Alto area the path is asymmetric. Yup, AsymmetricDSL does have different up/down bit rates. What I really meant was that the difference would not explain his issue. ex: with a 12Mbps down rate and 1.3Mbps up rate, the ratio is around 40usec to 300usec transfer of a 48byte NTP packet. Hi My experience is different. Due to uplink pipe being very much less capable than downlink I had 10-100ms latencies if pipe was full. Solution for me was to limit my outgoing rates to 80-90% which actually increased upload speed by almost 2x. I've adjusted that filter since 2005 each time my adsl has been upgraded. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
David Woolley wrote: > On 11/09/14 22:11, Rob wrote: >> mike cook wrote: >>> >>> Le 11 sept. 2014 à 21:08, Paul a écrit : >>> On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote: > Did I miss something? On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote: > My home LAN is connected to my school's network via a cable modem. If we make the (safe) assumption of a common cable ISP/FiOS in the Palo Alto area the path is asymmetric. >>> >>>Yup, AsymmetricDSL does have different up/down bit rates. What I really >>> meant was that the difference would not explain his issue. >>>ex: with a 12Mbps down rate and 1.3Mbps up rate, the ratio is around >>> 40usec to 300usec transfer of a 48byte NTP packet. >> >> Bitrate is not the only modem parameter. >> > > The baud rate is 4kHz (approx). That means that the absolute minimum > packet time is 125 microseconds. As packets probably don't align with > signalling units, there is a good chance that you will need to add > another 125 microseconds. There is also going to be a delay of, on > average, 63 microseconds waiting for the start of a signalling unit. The poster had no DSL, he mentioned a cable modem. In a cable modem there is another issue: the subscribers share the same uplink channel in an alternating fashion, while the downlink channel is used only by the cable headend. To avoid collisions, there will usually be some user timeslot allocation by the headend. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On 11/09/14 22:11, Rob wrote: mike cook wrote: Le 11 sept. 2014 à 21:08, Paul a écrit : On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote: Did I miss something? On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote: My home LAN is connected to my school's network via a cable modem. If we make the (safe) assumption of a common cable ISP/FiOS in the Palo Alto area the path is asymmetric. Yup, AsymmetricDSL does have different up/down bit rates. What I really meant was that the difference would not explain his issue. ex: with a 12Mbps down rate and 1.3Mbps up rate, the ratio is around 40usec to 300usec transfer of a 48byte NTP packet. Bitrate is not the only modem parameter. The baud rate is 4kHz (approx). That means that the absolute minimum packet time is 125 microseconds. As packets probably don't align with signalling units, there is a good chance that you will need to add another 125 microseconds. There is also going to be a delay of, on average, 63 microseconds waiting for the start of a signalling unit. To this you need to allow for any expansion due to FEC coding, and the likely use of interleaving, which, to be effective, would need to spread adjacent bits over quite a lot of signalling units. I can't find a figure at the moment, but my guess is that it pushes the minimum delay into the milliseconds range. (Gamers tend to turn off interleaving, if they can, as they want low latency at all costs. Businesses are most likely to want it on.) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
There are a bunch of issues here, and I don't think there is a simple answer. For starters, there is static asymmetry and dynamic asymmetry. One of the core issues is that NTP is frequently multihop, and the routing for at least some of these connections can spontaneously change. Declaring an asymmetry correction for an interface will affect all connections over that interface. Sometimes that's OK, sometimes not. Declaring an asymmetry correction for a given remote server hardcodes assumptions that almost certainly will change over time. The trick is that we don't know how many hops there are between "here" and "there", and the number and location of these hops can change. Precision Time Protocol looks closer at these issues, and PTP is designed to work on point-to-point links. So if one can use a local good reference time and use those timestamps to compare with remote good reference times, one can have a better chance to identify some of the static asymmetry issues. Dealing with the dynamic ones is harder... The soution seems to depend on having multiple sources of good time, and having access to these good time sources via different "paths". -- Harlan Stenn http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP shared memory driver
cloudd...@gmail.com writes: > My configuration file il se following: > > # > driftfile /var/log/ntp.drift# path for drift file > logfile /var/log/ntp.log# alternate log file > > # shared memory configuration > server 127.127.28.0 minpoll 4 maxpoll 4 prefer > fudge 127.127.28.0 time1 0.420 refid SHM1 stratum 0 true > > server 127.127.28.1 minpoll 4 maxpoll 4 > fudge 127.127.28.1 time1 0.420 refid SHM2 stratum 0 true stratum 0 is too "good". I think you want 1, maybe 2. What do you think the "true" at the end of your fudge lines is doing? > Querying the ntp gives me: > > emh2@tutnix:/etc$ ntpq -p > remote refid st t when poll reach delay offset jitte > r > = > = > SHM(0) .SHM1. 0 l- 1600.0000.000 0.00 > 0 > SHM(1) .SHM2. 0 l- 1600.0000.000 0.00 > 0 > > Seems that nothing is working. Yes, until you start getting ntpd to accept data samples from your SHM socket nothing will be working there. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
mike cook wrote: > > Le 11 sept. 2014 à 18:48, Rob a écrit : > >> Paul wrote: >>> As an aside has anyone tried shaping traffic to make the >>> upstream/downstream latencies similar? It would seem more efficient >>> to apply network solutions to network problems if possible. >> >> That does not work. The asymmetry is not caused by traffic but by >> modem parameters. > > Did I miss something? The OP did not offer any evidence that there was path > asymmetry, just that there was an unexplained offset between two GPS sync'd > servers. An offset between two GPS synced servers by definition means path asymmetry. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
mike cook wrote: > > Le 11 sept. 2014 à 21:08, Paul a écrit : > >> On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote: >>> Did I miss something? >> >> On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote: >>> My home LAN is connected to my school's network via a cable modem. >> >> If we make the (safe) assumption of a common cable ISP/FiOS in the >> Palo Alto area the path is asymmetric. > > Yup, AsymmetricDSL does have different up/down bit rates. What I really > meant was that the difference would not explain his issue. > ex: with a 12Mbps down rate and 1.3Mbps up rate, the ratio is around 40usec > to 300usec transfer of a 48byte NTP packet. Bitrate is not the only modem parameter. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Paul wrote: > On Thu, Sep 11, 2014 at 2:29 PM, William Unruh wrote: >> I doubt that NAT would add much assymetry > > NAT is symmetric. Otherwise it wouldn't work. But I don't see how > that's part of anything at hand. I never claimed it is part of the asymmetry, I only mentioned it because usually you use a private IP range on a LAN, so when you are both on a LAN and on Internet you either have two different IP addresses (as I do) or you have NAT between an external address and your LAN range. The NAT is not causing asymmetry but it makes it more difficult to separate the internal from the external traffic. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
The offset may be a function of distance. Try this experiment: Set up your ntp.conf file to have three servers (all examples assume you are located in Eastern USA): 1. A relatively unused stratum 1 or 2 server as close to you as possible. 2. A relatively unused stratum 1 or 2 server about 1,000 miles away (e.g., ntp.melancthon.net) 3. A relatively unused stratum 1 or 2 server more than 2,000 miles away (e.g., ntp1.tp.pl, ntp2.tp.pl, time.coi.pw.edu.pl, ntp.certum.pl). On my computer, the offset is proportional to distance: Remote Refid StratumTypeWhenPoll Reach Delay OffsetJitter BR-350P GPS 0 Local clock 7 16 017 0.000-17.6532.345 FreeNAStime-c.nist.gov 2 Unicast server 16 16 017 0.238 0.0080.037 nist1-pa.ustiming.org ACTS 1 Unicast server 15 16 017 28.844 0.135 3.158 2a01:1102:0:b::2ATOM1 Unicast server 16 16 017 120.732 -5.145 2.151 2a01:1100:1::2 ATOM1 Unicast server 15 16 017 128.756 -3.931 4.635 213.222.200.99 PPS 1Unicast server 13 16 017 110.727 -0.968 4.119 ntp.coi.pw.edu.pl OCX0 1Unicast server 14 16 017 122.100 -4.253 0.584 serenity.melancthon.net india.colorado.edu 2 Unicast server 35 32 003 53.520 2.019 3.556 Charles Elliott > -Original Message- > From: questions-bounces+elliott.ch=comcast@lists.ntp.org > [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On > Behalf Of mike cook > Sent: Thursday, September 11, 2014 2:08 PM > To: Questions List > Subject: Re: [ntp:questions] Compensating for asymmetric delay on a > per-peer/server basis? > > > Le 11 sept. 2014 à 18:48, Rob a écrit : > > > Paul wrote: > >> As an aside has anyone tried shaping traffic to make the > >> upstream/downstream latencies similar? It would seem more efficient > >> to apply network solutions to network problems if possible. > > > > That does not work. The asymmetry is not caused by traffic but by > > modem parameters. > > Did I miss something? The OP did not offer any evidence that there > was path asymmetry, just that there was an unexplained offset between > two GPS sync'd servers. It is often not possible to identify the origin > of such an offset, but it would help if the suggested feature was > implemented to take care of these corner cases. I saw that Dr Mills was > in agreement back in 2005 but that the implementation is complex. If > anyone wants a subject for an MSc project, this could be it. > > > > > ___ > > 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 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Le 11 sept. 2014 à 21:08, Paul a écrit : > On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote: >> Did I miss something? > > On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote: >> My home LAN is connected to my school's network via a cable modem. > > If we make the (safe) assumption of a common cable ISP/FiOS in the > Palo Alto area the path is asymmetric. Yup, AsymmetricDSL does have different up/down bit rates. What I really meant was that the difference would not explain his issue. ex: with a 12Mbps down rate and 1.3Mbps up rate, the ratio is around 40usec to 300usec transfer of a 48byte NTP packet. > ___ > 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] Compensating for asymmetric delay on a per-peer/server basis?
On Thu, Sep 11, 2014 at 2:08 PM, mike cook wrote: > Did I miss something? On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales wrote: > My home LAN is connected to my school's network via a cable modem. If we make the (safe) assumption of a common cable ISP/FiOS in the Palo Alto area the path is asymmetric. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
> Did I miss something? The OP did not offer any evidence that there was > path asymmetry, just that there was an unexplained offset between two > GPS sync'd servers. The asymmetry in this case is being caused by the characteristics of the cable modem that connects my residence with the campus network and the rest of the Internet. I've observed this consistently for several years, at various times of day. I'm convinced that it is not being caused by traffic congestion -- or, at least, that any traffic congestion factor is small compared to a pretty constant offset of 2 - 3 msec. > The asymmetry is caused by asymmetric latency which is caused (for > our purposes) by asymmetric line speeds. Traffic shaping can change > various things (depending on where you do it) including effective line > speed (packets/s not bits/s). Perhaps shaping UDP is too hard. I would certainly be open to doing experimentation in this regard. I have essentially full control over two Linux boxes (one on either side of the cable modem). However, up till now at least, I don't have any experience at all with traffic shaping; suggested steps are welcome. In the absence of a solution from the traffic-shaping domain, I would like to be able to use the "fudge" command in conjunction with a peer or server (currently, "fudge" works only with a reference clock). It seems to me that the "time1" parameter would do what I want -- if it could be specified for a peer or server, which currently it cannot. Again, I'm running version 4.2.6p5 right now. Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Thu, Sep 11, 2014 at 2:29 PM, William Unruh wrote: > I doubt that NAT would add much assymetry NAT is symmetric. Otherwise it wouldn't work. But I don't see how that's part of anything at hand. And yes the A in ADSL stands for Asymmetric. If you see the word "home" in reference to a link in the US it's almost certainly asymmetric modulo some special cases (ISDN, T1, Google Fiber etc.). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On 2014-09-11, mike cook wrote: > > Le 11 sept. 2014 ? 18:48, Rob a ?crit : > >> Paul wrote: >>> As an aside has anyone tried shaping traffic to make the >>> upstream/downstream latencies similar? It would seem more efficient >>> to apply network solutions to network problems if possible. >> >> That does not work. The asymmetry is not caused by traffic but by >> modem parameters. > > Did I miss something? The OP did not offer any evidence that there was path > asymmetry, just that there was an unexplained offset between two GPS sync'd > servers. It is often not possible to identify the origin of such an offset, > but it would help if the suggested feature was implemented to take care of > these corner cases. I saw that Dr Mills was in agreement back in 2005 but > that the implementation is complex. If anyone wants a subject for an MSc > project, this could be it. No idea why a fudge parameter would be complicated. If you wanted to use ntpd itself to figure out the assymmetry, that could well be complicated. But if it is a fixed offset, I cannot see how that would be complicated and it ihas already been implimented in the refclock case. > >> >> ___ >> 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] Compensating for asymmetric delay on a per-peer/server basis?
On 2014-09-11, Rob wrote: > Martin Burnicki wrote: >> This is also what Rob has mentioned in another post of this thread, and >> I agree with Rob that a one approach could be to specify (and configure >> for ntpd) the systematic error due to asymmetry of your internet connection. >> >> However, this can also be pretty tricky if you have several NTP nodes on >> your home network, if all nodes and the inet router are connected to the >> same switch. >> >> For different nodes on you home net there is no asymmetry (thus no time >> error), but for each of them who contacts also an external server there >> is. And often a specific machine contacts the other internal devices as >> well as the external ones via the same own LAN interface. >> >> So for your internal operation this means: >> >> - If you specify a fudge time for a specific interface this may be OK >> for external servers but yield an error for internal servers, i.e. >> exactly the other way round as without compensation. >> >> - You had indeed to specify a fudge time for servers of which you know >> they are outside on the internet, e.g. other pool servers >> >> >> On the other hand, if your local NTP server shall be accessible both for >> external pool clients, and local clients, how should you know where a >> specific request comes from? Based on the IP address? Only if the local >> network and the internet interface are connected via different interfaces? >> >> So even though it would be good to be able to specify some compensation >> values, there should be different ways to do it, and putting all >> together in a way that there is no error is tricky. > > Well, in my own system I have a different IP address for the internet > than I have for my local network. In the bug report I asked for a > fudge time1 that could be specified per local IP addres. This would > work OK in my case. When you use the same address on a LAN and on > internet it is more difficult. I guess this only happens in cases > where there is a NAT router that translates requests from internet to > a local address. Not a configuration I would recommend when being > in the pool anyway. Nope. You could have a local network in which each computer has its own public IP addess, but the connection to that subnetwork is assymetric. I doubt that NAT would add much assymetry. An adsl connection might well since they advertise very different rates up from down. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Min & max poll no longer needed for SHM/GPSD driver?
It has been pointed out to me that this page: http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver28.html says: "The gpsd man page suggests setting minpoll and maxpoll to 4. That was an attempt to reduce jitter. The SHM driver was fixed (ntp-4.2.5p138) to collect data each second rather than once per polling interval so that suggestion is no longer reasonable" So what should minpoll and maxpoll be set to for the GPSD shared memory driver? Or should they be omitted? I'm confused Thanks! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Le 11 sept. 2014 à 18:48, Rob a écrit : > Paul wrote: >> As an aside has anyone tried shaping traffic to make the >> upstream/downstream latencies similar? It would seem more efficient >> to apply network solutions to network problems if possible. > > That does not work. The asymmetry is not caused by traffic but by > modem parameters. Did I miss something? The OP did not offer any evidence that there was path asymmetry, just that there was an unexplained offset between two GPS sync'd servers. It is often not possible to identify the origin of such an offset, but it would help if the suggested feature was implemented to take care of these corner cases. I saw that Dr Mills was in agreement back in 2005 but that the implementation is complex. If anyone wants a subject for an MSc project, this could be it. > > ___ > 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] Compensating for asymmetric delay on a per-peer/server basis?
On Thu, Sep 11, 2014 at 12:48 PM, Rob wrote: > That does not work. The asymmetry is not caused by traffic but by > modem parameters. The asymmetry is caused by asymmetric latency which is caused (for our purposes) by asymmetric line speeds. Traffic shaping can change various things (depending on where you do it) including effective line speed (packets/s not bits/s). Perhaps shaping UDP is too hard. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Paul wrote: > As an aside has anyone tried shaping traffic to make the > upstream/downstream latencies similar? It would seem more efficient > to apply network solutions to network problems if possible. That does not work. The asymmetry is not caused by traffic but by modem parameters. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Paul wrote: > Not to suggest that someone is doing something unreasonable but again > why does time derived from the back-up clock need to be as accurate as > the local clock (say .5ms versus 2ms)? If there's a legitimate need > then trying to solve the problem with the wrong tool will only lead to > frustration and complaints that NTP is buggy. One possible explanation is that people don't want their clock to suddenly track the changed offset in such cases. If only because ntpd will think that the frequency offset it has calculated over a long time period is suddenly wrong, and will change it to reflect a sudden time offset in a short time interval. It will then slew to the correct time, overshoot, and when the correct reference comes back online this will repeat in the other direction. This problem can partly be mitigated by ensuring that the offset between your local clock and the external references is as small as possible. (with some tweaking I can get these well below .5ms, often below .1ms) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Tue, Sep 9, 2014 at 6:58 PM, Harlan Stenn wrote: > The issue is that the huff-n-puff filter will work in the case where a > symmetrical delay becomes asymmetric, and it will "tolerate" or > "accommodate" an asymmetric delay (caused by a large download, for > example) for some period of time. I was overly casual. If you follow the breadcrumbs you find that there is no general solution to the problem. On Thu, Sep 11, 2014 at 9:35 AM, Martin Burnicki wrote: > The case mentioned by the original poster is just one possible reason. Not to suggest that someone is doing something unreasonable but again why does time derived from the back-up clock need to be as accurate as the local clock (say .5ms versus 2ms)? If there's a legitimate need then trying to solve the problem with the wrong tool will only lead to frustration and complaints that NTP is buggy. If I *needed* highly available and accurate time at home I'd get a constellation of stable oscillators to drive time rather than hoping a remote clock or set of clocks was going to solve my problem. As an aside has anyone tried shaping traffic to make the upstream/downstream latencies similar? It would seem more efficient to apply network solutions to network problems if possible. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On 2014-09-11, Martin Burnicki wrote: > William Unruh wrote: >> Not if you have gps reference at both ends, though why you would not use >> the gps as the timesource then I do not know. > > The case mentioned by the original poster is just one possible reason. > > If you have a GPS controlled NTP server at home, and a fast internet > connection, and you are willing to contribute to the pool, then usually > external clients querying your server will see a systematic offset/error > depending on the ratio of the upload/download speed for your home > connection. Agreed. There are two (at least) issues. One is making sure that the clock on your local machine is accurate-- ie as close to UTC as possible. The other is that the time you deliver to some remote machine is as accurate as poosible (ie that the average of the timeout-timein on the remote machine is as close to utc as possible. That of course is a confluence of factors partly in your control or determination (ie assymmetric delay on your own particular connection) and way outside your control (assymetric connection of the remote machine's connection, or assymetry on the network between you and them.) I think that ntpd should allow you to solve the first problem-- making sure your local machine's time be as close to accurate as possible-- but I agree that the second problem really is beyond ntpd's capability. However not being able even to accomplish the first is a in my mind a bug. > > If you had a chance to measure this from an external node using another > GPS controlled NTP server you could try to compensate this, and thus > provide better accuracy to the clients coming from the pool. > > This is also what Rob has mentioned in another post of this thread, and > I agree with Rob that a one approach could be to specify (and configure > for ntpd) the systematic error due to asymmetry of your internet connection. > > However, this can also be pretty tricky if you have several NTP nodes on > your home network, if all nodes and the inet router are connected to the > same switch. > > For different nodes on you home net there is no asymmetry (thus no time > error), but for each of them who contacts also an external server there > is. And often a specific machine contacts the other internal devices as > well as the external ones via the same own LAN interface. > > So for your internal operation this means: > > - If you specify a fudge time for a specific interface this may be OK > for external servers but yield an error for internal servers, i.e. > exactly the other way round as without compensation. > > - You had indeed to specify a fudge time for servers of which you know > they are outside on the internet, e.g. other pool servers > > > On the other hand, if your local NTP server shall be accessible both for > external pool clients, and local clients, how should you know where a > specific request comes from? Based on the IP address? Only if the local > network and the internet interface are connected via different interfaces? > > So even though it would be good to be able to specify some compensation > values, there should be different ways to do it, and putting all > together in a way that there is no error is tricky. > > > Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Martin Burnicki wrote: > This is also what Rob has mentioned in another post of this thread, and > I agree with Rob that a one approach could be to specify (and configure > for ntpd) the systematic error due to asymmetry of your internet connection. > > However, this can also be pretty tricky if you have several NTP nodes on > your home network, if all nodes and the inet router are connected to the > same switch. > > For different nodes on you home net there is no asymmetry (thus no time > error), but for each of them who contacts also an external server there > is. And often a specific machine contacts the other internal devices as > well as the external ones via the same own LAN interface. > > So for your internal operation this means: > > - If you specify a fudge time for a specific interface this may be OK > for external servers but yield an error for internal servers, i.e. > exactly the other way round as without compensation. > > - You had indeed to specify a fudge time for servers of which you know > they are outside on the internet, e.g. other pool servers > > > On the other hand, if your local NTP server shall be accessible both for > external pool clients, and local clients, how should you know where a > specific request comes from? Based on the IP address? Only if the local > network and the internet interface are connected via different interfaces? > > So even though it would be good to be able to specify some compensation > values, there should be different ways to do it, and putting all > together in a way that there is no error is tricky. Well, in my own system I have a different IP address for the internet than I have for my local network. In the bug report I asked for a fudge time1 that could be specified per local IP addres. This would work OK in my case. When you use the same address on a LAN and on internet it is more difficult. I guess this only happens in cases where there is a NAT router that translates requests from internet to a local address. Not a configuration I would recommend when being in the pool anyway. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
Rob wrote: Ok you are right. In fact I filed bug #2598 myself for a similar situation... In my case I wanted to compensate for the delay asymmetry for external users using my GPS reference via my ADSL line. So I would like to apply such a fudge command to a network interface, not to a peer server. I forgot that it is not even possible to apply it to a server, what you would like to do. I think the only thing you can do is apply an offset to your GPS and live with the fact that you are always 2ms off. At least then you don't have a time wander when you switch to your backup and the external users of your system get the correct time. That is what I did as a workaround until someone fixes this in ntpd. Please see my reply to Bill Unruh. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
William Unruh wrote: Not if you have gps reference at both ends, though why you would not use the gps as the timesource then I do not know. The case mentioned by the original poster is just one possible reason. If you have a GPS controlled NTP server at home, and a fast internet connection, and you are willing to contribute to the pool, then usually external clients querying your server will see a systematic offset/error depending on the ratio of the upload/download speed for your home connection. If you had a chance to measure this from an external node using another GPS controlled NTP server you could try to compensate this, and thus provide better accuracy to the clients coming from the pool. This is also what Rob has mentioned in another post of this thread, and I agree with Rob that a one approach could be to specify (and configure for ntpd) the systematic error due to asymmetry of your internet connection. However, this can also be pretty tricky if you have several NTP nodes on your home network, if all nodes and the inet router are connected to the same switch. For different nodes on you home net there is no asymmetry (thus no time error), but for each of them who contacts also an external server there is. And often a specific machine contacts the other internal devices as well as the external ones via the same own LAN interface. So for your internal operation this means: - If you specify a fudge time for a specific interface this may be OK for external servers but yield an error for internal servers, i.e. exactly the other way round as without compensation. - You had indeed to specify a fudge time for servers of which you know they are outside on the internet, e.g. other pool servers On the other hand, if your local NTP server shall be accessible both for external pool clients, and local clients, how should you know where a specific request comes from? Based on the IP address? Only if the local network and the internet interface are connected via different interfaces? So even though it would be good to be able to specify some compensation values, there should be different ways to do it, and putting all together in a way that there is no error is tricky. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP shared memory driver
Claudio Persico wrote: Just to understand: when I run ntpq -p, I think that a star (*) symbol should appear in the shared memory segment that NTPD has choose for keeping the time. This is *only* if ntpd accepts this time source as "system peer". Does the fact that in my output of ntpq I can't see any star means that no one is filling the memory with good values or that NTPD has having some troubles with shared memory segments? How about just running "ntpq -p" and showing us the output? Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP shared memory driver
Claudio Persico wrote: > Just to understand: > > when I run ntpq -p, I think that a star (*) symbol should appear in the > shared memory segment that NTPD has choose for keeping the time. Before that, you first have to see values appear within the other fields on the line. > Does the fact that in my output of ntpq I can't see any star means that no > one is filling the memory with good values or that NTPD has having some > troubles with shared memory segments? You can't tell that from that output. You can try looking in the syslog and/or ntpd log. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP shared memory driver
Just to understand: when I run ntpq -p, I think that a star (*) symbol should appear in the shared memory segment that NTPD has choose for keeping the time. Does the fact that in my output of ntpq I can't see any star means that no one is filling the memory with good values or that NTPD has having some troubles with shared memory segments? Thanks, Claudio ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP shared memory driver
cloudd...@gmail.com wrote: > I've written a simple application for now that writes in the shared memory > segment the information about time following the approach shown here: > http://www.opensource.apple.com/source/ntp/ntp-86/util/sht.c > > Can someone please help me? > > Thanks in advance, > Claudio Try with "gpsd", an existing program that does exactly this (and more). The sources of that program also show you how to do it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] NTP shared memory driver
Hi to all. I'm trying to setup an NTP server. I have an external device that is connected to a GPS signal and sends to my device the time. My device runs an application that receives this time and has to fill-in the shared memory of NTP, thus allowing NTP to adjust system time and to distribute the time to other clients connected. In my device I'm trying to setup NTP in a way in which he can read the time only from the shared memory. My configuration file il se following: # driftfile /var/log/ntp.drift# path for drift file logfile /var/log/ntp.log# alternate log file # shared memory configuration server 127.127.28.0 minpoll 4 maxpoll 4 prefer fudge 127.127.28.0 time1 0.420 refid SHM1 stratum 0 true server 127.127.28.1 minpoll 4 maxpoll 4 fudge 127.127.28.1 time1 0.420 refid SHM2 stratum 0 true NTP is running: emh2@tutnix:/var/log$ ps -fea | grep ntp emh2 9709 3167 0 10:24 pts/000:00:00 grep --color=auto ntp ntp 23280 2013 0 09:59 ?00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 117:126 -c /etc/ntp.conf and I have shared memory segment: emh2@tutnix:/etc$ sudo ipcs -m -- Shared Memory Segments keyshmid owner perms bytes nattch status 0x4e545030 5406720root 60080 1 0x4e545031 5439489root 60080 1 Querying the ntp gives me: emh2@tutnix:/etc$ ntpq -p remote refid st t when poll reach delay offset jitter == SHM(0) .SHM1. 0 l- 1600.0000.000 0.000 SHM(1) .SHM2. 0 l- 1600.0000.000 0.000 Seems that nothing is working. I've written a simple application for now that writes in the shared memory segment the information about time following the approach shown here: http://www.opensource.apple.com/source/ntp/ntp-86/util/sht.c Can someone please help me? Thanks in advance, Claudio ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
