Re: [ntp:questions] Regarding Primary/Secondary NTP setup
Goran, Under normal running conditions, NTP exchanges a pair of 90-byte packets every 1024 seconds. That's traffic over the wire amounting to about 1.4 bits per second. Is that acceptable, or are you really insisting that the traffic must be zero bps? Paul ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Dave Hart daveh...@gmail.com wrote in message news:03463add-146a-457d-9869-9caddf6f8...@i18g2000prf.googlegroups.com... On Feb 17, 9:01 am, Maarten Wiltink maar...@kittensandcats.net wrote: My home network is on 192.168.27/24. I took the number from my street address. My brother (independently!) picked 53 for his network, by the same mechanism[0]. We have an OpenVPN tunnel between those networks. We have no routing problems. [0] And when they renumbered his house, he renumbered his network. Okay, I wouldn't have done that. I've taken the same approach a couple of times at different addresses with 192.168.address.0/24. I also have a VPN going with my brother. Sadly, his employer requires security software that requires he use 192.168.1.0/24 for his home network to be able to VPN in to work. As a workaround, I've sometimes subnetted a hotel 192.168.1.0/24 hotel address, claiming 192.168.1.2 and using netmask 192.168.1.252, so that when I VPN all but the first few addresses of my brother's network are visible. Scary. You _are_ me. (-: (Actually, it was my employer, not his, that had a spurious 192.168.0/24 requirement somewhere, so I guess that introduces a cross in the connection somewhere.) Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] handling falseticker
Catia, catia.lava...@bechtle.com wrote: Hallo, I have the following configuration Stratum 0 configuration: 1 x Stratum 0 (DCF Clock) -- 1 x Stratum 1 (let's give it the IP 10.1.1.1) 1 x Stratum 0 (GPS Clock) -- 1 x Stratum 1 (let's give it the IP 10.1.1.2) I do not have (for security policy) the possibility to give any other alternative (extern) time source to the Stratum 2 Servers. This means that my Stratum 2 Servers have only 2 servers. Obviously this configuration is not falseticker save. I have a monitoring active which warns me if the time offset between the 2 Stratum 1 server gets bigger than a fixed limit. In such a situation anyway the NTP daemon on the Stratum 2 servers would mark one of the 2 Stratum 1 servers as a falseticker and ignore the time coming from it. Since there are only 2 Stratum 1 server to choose from the voting decision do not really apply, in such a way that the decision that the NTP on the Stratum 2 servers take upon ops! there is a falseticker. Which one is falseticker? is rather casual (I guess). Say they mark the server 10.1.1.1 as falseticker. remote refid === *10.1.1.1 .GPS. x10.1.1.2 .DCF. 127.127.1.1.LOCL. At this point I will get a warning from my monitoring, I will check manually with an external source which time really is and have a look to the decision that NTP on the Stratum 2 Server took. Say I realize that the decision taken is wrong: the 10.1.1.1 is not the false ticker, the true false ticker is 10.1.1.2 What should I do? I mean is there a way to force NTP on the fly to change it's mind? I have in mind something like a command line saying force to trust server 10.1.1.1 (which simultaneously automatically will imply then ignore 10.1.1.2 since this means it is the true falseticker)? == to force the following switch remote refid === x10.1.1.1 .GPS. *10.1.1.2 .DCF. 127.127.1.1.LOCL. Sure I could reconfigure ntp.conf with a prefer on the 10.0.0.1 server, and restart the daemon (would it work? I guess so), but I do not really like it, I find it to permanent. thanks If both of your NTP servers provided a different time even though their GPS and DCF77 refclocks were synchronized then this would be a bug in the NTP server's software. In this case a client which polls both servers had no chance to find out which of the 2 upstream servers was a false ticker. The only way to resolve this automatically is to configure at least 1 more upstream server. If one of your NTP servers has lost synchronization with the incoming radio signal from GPS or DCF77 then the times received from both servers will start to drift apart slowly, depending on the accuracy of the oscillators. Depending on the configuration of the trust time of the refclocks in your NTP servers the root dispersion of the freewheeling server will start to increase, so NTP clients should be able to find out which of the servers provides better time. Alternatively you can configure the local clock on your NTP servers and fudge their stratum to 15. So if the GPS or DCF77 receiver has lost synchronization then (possibly after a trust time) the NTP server will select the local clock as system peer. If the local clock's stratum is 15 then the NTP server will be seen as stratum 16 on the network, which means not synchronized, so that NTP server will be discarded by the clients. Hope this helps. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP over redundant peer links, undetected loops
Maarten Wiltink wrote: Dave Hart daveh...@gmail.com wrote in message news:03463add-146a-457d-9869-9caddf6f8...@i18g2000prf.googlegroups.com... On Feb 17, 9:01 am, Maarten Wiltink maar...@kittensandcats.net wrote: My home network is on 192.168.27/24. I took the number from my street address. My brother (independently!) picked 53 for his network, by the same mechanism[0]. We have an OpenVPN tunnel between those networks. We have no routing problems. [0] And when they renumbered his house, he renumbered his network. Okay, I wouldn't have done that. I've taken the same approach a couple of times at different addresses with 192.168.address.0/24. I also have a VPN going with my brother. Sadly, his employer requires security software that requires he use 192.168.1.0/24 for his home network to be able to VPN in to work. As a workaround, I've sometimes subnetted a hotel 192.168.1.0/24 hotel address, claiming 192.168.1.2 and using netmask 192.168.1.252, so that when I VPN all but the first few addresses of my brother's network are visible. Scary. You _are_ me. (-: (Actually, it was my employer, not his, that had a spurious 192.168.0/24 requirement somewhere, so I guess that introduces a cross in the connection somewhere.) This is why I avoid the 192.168.*.* addresses everywhere. Everyone wants to use them. Only my DMZ uses them. Danny Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] handling falseticker
catia.lava...@bechtle.com wrote: Hello, what you describe is not the situation I have in mind. You describe a lost sync of one of the 2 Stratum 0. This is not a falseticker situation. This would lead to a lost sync or a sync to local host which will be transferred up down on the whole NTP tree, recognized by the clients and this NTP path will be ignored. Everything is clean everything is fine. And everything could be easily monitored (a lost sync is an error message!) What I describe is a falsetiker as for example: suppose that the DCF signal gives you the correct time, the GPS signal has a failure (it steps apart a bit but not soo much that NTP refuses to stay sync) and DOES give you a time BUT a wrong one. This is less easy to monitor since there no error! Both Stratum 1 will keep being sync with the respective Stratum 0 because they DO receive a time and this time is not s wrong to stop syncing (is not a huge jump ... say is a slow drift). The Stratum 2 will receive time from the Stratum 1. Will see that both are syncing with a Stratum 0 i.e. in principle they are both trustable but their time is too far apart to assume that both are correct. This means NTP has to decide which one is the wrong one. In this case NTP would decide which one gives the wrong time i.e. to be rejected as server with a voting criterion. The problem is that a voting criterion works only with up to 3 (well 4) servers. With 2 servers it does not work (no majority reach!). So NTP is forced to take anyway a decision but without enough elements at hand to know which is the right decision to take i.e. the decision it will take is not necessarily the correct one. Here my question. Say the decision taken is wrong. I realize it in some way (no matter how) and I want to correct it. I.e. I want to force NTP to switch from: remoterefid === *10.1.1.1 .GPS. x10.1.1.2 .DCF. 127.127.1.1.LOCL. to remoterefid === x10.1.1.1 .GPS. *10.1.1.2 .DCF. 127.127.1.1.LOCL. from the command line without having to change the ntp.conf file. Is it possible?? How?? You can use the ntpdc tool to change the configuration of a running NTP daemon on the fly. However, the NTP daemon accepts commands from ntpdc only if symmetric key authentication is enabled. To enable symmetric key authentication there must be a file which contains the keys, e.g. /etc/ntp.keys with the following line -- snip --- 1 M mysecret 2 M myothersecret 3 M onemoresecret -- snip --- The 1st column is the key ID, just a number to identify one of the keys in the file. The 2nd column is an abbreviation for the algorithm. 'M' is for MD5 and is what you should use. The 3rd column represents the passphrase for the key. In order to enable symmetric key authentication for the NTP daemon the file /etc/ntp.conf must contain the following lines: -- snip --- keys /etc/ntp.keys # path for keys file trustedkey 1 2 3 # define all trusted keys requestkey 2 # key (2) to use with ntpdc controlkey 3 # key (3) to use with ntpq -- snip --- The trustedkey line contains a summary of all key IDs from the ntp.keys file which shall be trusted. The requestkey specifies the key to be used with ntpdc. The controlkey specifies the key to be used with ntpq, though NTP bug #418 indicates this has never been implemented: http://bugs.ntp.org/418 If you have changed the config file you should restart the NTP daemon. Given the values from the example above you should be able to use ntpdc to ... ... remove a selected server association: ntpdc -c keyid 2 -c passwd myothersecret -c unconfig 10.1.1.2 ... add a selected server association: ntpdc -c keyid 2 -c passwd myothersecret -c addserver 10.1.1.2 If you don't add the keyid and passwd on the command line you will be prompted for it. Hope this helps. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Regarding Primary/Secondary NTP setup
On Tue, Feb 17, 2009 at 2:51 AM, Göran Törnqvist goran.tornqv...@cypoint.se wrote: Hi, I have 2 sites with similar setup, each with its own NTP server. Both sites are connected so each site´ clients will use the other site´s NTP server as secondary. The NTP primary/secondary will use 2 other stratum 1 servers to sync with. A requirement is that traffic to secondary server is only sent when primary is unreachable. My question is if simply configuring the client´s primary using server X.X.X.X prefer in ntp.conf will accomplish this? If I understand it right ntp needs to query all servers in the server list to compute which one is the most reliable? I guess this could be OK if this querying is done very rarely. Also, since there shouldn´t be any traffic between the sites, the primary and secondary will not sync with each other, is this a bad idea? A man with two watches never knows what time it really is or something like that. Two servers is considered the worst possible NTP configuration. You're better off with one server; three or four is really best. See: http://twiki.ntp.org/bin/view/Support/DesigningYourNTPNetwork NTP's bandwidth requirements are very low, and you can even reduce it further by adding a minpoll X directive at the expense of accuracy. How many NTP clients are there on each side? Even if there were 1000 clients at each site, your average traffic with all clients talking to two servers at each site would result in about 5.6 kbps average in both directions on the WAN link using default settings. This is about 0.3% of a T1 connection's bandwidth. Now, if the WAN link is very expensive (satellite?) or only intermittently connected, that will add to the complexity. If you are truly required to have absolutely zero traffic between the sites, you really are going to have to do some network-layer routing magic to prevent traffic from passing until you are in fail over mode. Such a configuration might require a load-balancer NAT device, or other network-layer clustering solution. -- RPM ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd on embedded risc
On 2009-02-18, Unruh unruh-s...@physics.ubc.ca wrote: cnm3...@gmail.com (Christopher Mire) writes: I have a small embedded linux machine. Moxa UC-7112 Plus that I want to use as NTP server. http://www.moxa.com/product/UC-7110-LX.htm Its has MOXA ART ARM9 32-bit 192 MHz processor CPU. Here are statistics I collected after using it a bit. This is using gpsd 2.33 to collect NMEA, PPS. a bit means what? Remember that ntpd takes 1 hour to cut the error by half. Thus unless you ran this for more than 10 hours, these offsets mean nothing. Poppycock. A snapshot is merely a snapshot regardless of when it is taken. Long term performance is what's important. It may be evaluated through the use of multiple snapshots (over a suitable period) or by summarizing the statistics files. [---=| TOFU protection by t-prot: 53 lines snipped |=---] -- http://www.netmeister.org/news/learn2quote.html -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] handling falseticker
Hello, what you describe is not the situation I have in mind. You describe a lost sync of one of the 2 Stratum 0. This is not a falseticker situation. This would lead to a lost sync or a sync to local host which will be transferred up down on the whole NTP tree, recognized by the clients and this NTP path will be ignored. Everything is clean everything is fine. And everything could be easily monitored (a lost sync is an error message!) What I describe is a falsetiker as for example: suppose that the DCF signal gives you the correct time, the GPS signal has a failure (it steps apart a bit but not soo much that NTP refuses to stay sync) and DOES give you a time BUT a wrong one. This is less easy to monitor since there no error! Both Stratum 1 will keep being sync with the respective Stratum 0 because they DO receive a time and this time is not s wrong to stop syncing (is not a huge jump ... say is a slow drift). The Stratum 2 will receive time from the Stratum 1. Will see that both are syncing with a Stratum 0 i.e. in principle they are both trustable but their time is too far apart to assume that both are correct. This means NTP has to decide which one is the wrong one. In this case NTP would decide which one gives the wrong time i.e. to be rejected as server with a voting criterion. The problem is that a voting criterion works only with up to 3 (well 4) servers. With 2 servers it does not work (no majority reach!). So NTP is forced to take anyway a decision but without enough elements at hand to know which is the right decision to take i.e. the decision it will take is not necessarily the correct one. Here my question. Say the decision taken is wrong. I realize it in some way (no matter how) and I want to correct it. I.e. I want to force NTP to switch from: remoterefid === *10.1.1.1 .GPS. x10.1.1.2 .DCF. 127.127.1.1.LOCL. to remoterefid === x10.1.1.1 .GPS. *10.1.1.2 .DCF. 127.127.1.1.LOCL. from the command line without having to change the ntp.conf file. Is it possible?? How?? Thanks. Catia Externe Mail : questions-bounces+catia.lavalle=bechtle@lists.ntp.org 18.02.200910:11 Gesendet von: questions-bounces+catia.lavalle=bechtle@lists.ntp.org An: questions@lists.ntp.org Kopie: Thema: Re: [ntp:questions] handling falseticker Catia, catia.lava...@bechtle.com wrote: Hallo, I have the following configuration Stratum 0 configuration: 1 x Stratum 0 (DCF Clock) -- 1 x Stratum 1 (let's give it the IP 10.1.1.1) 1 x Stratum 0 (GPS Clock) -- 1 x Stratum 1 (let's give it the IP 10.1.1.2) I do not have (for security policy) the possibility to give any other alternative (extern) time source to the Stratum 2 Servers. This means that my Stratum 2 Servers have only 2 servers. Obviously this configuration is not falseticker save. I have a monitoring active which warns me if the time offset between the 2 Stratum 1 server gets bigger than a fixed limit. In such a situation anyway the NTP daemon on the Stratum 2 servers would mark one of the 2 Stratum 1 servers as a falseticker and ignore the time coming from it. Since there are only 2 Stratum 1 server to choose from the voting decision do not really apply, in such a way that the decision that the NTP on the Stratum 2 servers take upon ops! there is a falseticker. Which one is falseticker? is rather casual (I guess). Say they mark the server 10.1.1.1 as falseticker. remote refid === *10.1.1.1 .GPS. x10.1.1.2 .DCF. 127.127.1.1.LOCL. At this point I will get a warning from my monitoring, I will check manually with an external source which time really is and have a look to the decision that NTP on the Stratum 2 Server took. Say I realize that the decision taken is wrong: the 10.1.1.1 is not the false ticker, the true false ticker is 10.1.1.2 What should I do? I mean is there a way to force NTP on the fly to change it's mind? I have in mind something like a command line saying force to trust server 10.1.1.1 (which simultaneously automatically will imply then ignore 10.1.1.2 since this means it is the true falseticker)? == to force the following switch remote refid === x10.1.1.1 .GPS. *10.1.1.2 .DCF. 127.127.1.1.LOCL. Sure I could reconfigure ntp.conf with a prefer on the 10.0.0.1 server, and restart the daemon (would it work? I guess so), but I do not really like it, I find it to permanent. thanks If both of your NTP servers provided a different time even though their GPS and DCF77 refclocks were synchronized then this would be a bug in the NTP server's software. In this case a client which polls both servers had no chance to find out which of the 2 upstream servers was a false ticker.
Re: [ntp:questions] ntpd on embedded risc
Unruh unruh-s...@physics.ubc.ca wrote: But a snapshot taken before the system has settled down to its long term behaviour is especially useless. The way ntp works is that intially it takes a while to settle down to its long term behaviour. With PPS control it usually settles down to usec offset but it takes of order of 10 hours to do so. Thus snapshots taken long before that are especially useless. If after 10 hours the system still has msec offsets from a PPS then there is something seriously wrong. He is not using a PPS in the sense that you are talking about. He uses the PPS support in gpsd which is written in user space and will settle to around 10us on a fast system that is not overloaded. On a slow embedded board it may be different, I have no experience with running gpsd on those. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Refclock not going sys.peer when there is a pps.peer
I recently added an ATOM refclock based on the PPS output of my TRUETIME 486-DC with the G2G antenna. The results are: # ntpq -c rv -c ass -p associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync, version=ntpd 4.2.5p...@1.1809-o Mon Feb 9 04:32:17 UTC 2009 (1), processor=i686, system=Linux/2.6.26.simonet, leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.373, refid=PPS, reftime=cd46d043.8c33 Wed, Feb 18 2009 10:21:55.547, clock=cd46d049.56564abc Wed, Feb 18 2009 10:22:01.337, peer=33855, tc=4, mintc=3, offset=0.063, frequency=-89.057, sys_jitter=0.002, clk_jitter=0.002, clk_wander=0.001 ind assid status conf reach auth conditionlast_event cnt === 1 33855 974a yes yes none pps.peersys_peer 4 2 33856 941b yes yes none candidate clock_alarm 1 3 33857 941d yes yes none candidate 1 4 33858 9324 yes yes none outlyer reachable 2 5 33859 9337 yes yes none outlyer raate_exceeded 3 6 33860 9344 yes yes none outlyer reachable 4 7 33861 933d yes yes none outlyer 3 remote refid st t when poll reach delay offset jitter == oPPS(1) .PPS. 0 l 6 16 3770.000 0.063 0.002 +TRUETIME(0) .TRUE. 0 l 52 64 3770.000 -6.287 0.053 +clepsydra.dec.c .GPS. 1 u 51 64 377 53.204 7.740 3.352 -clock.xmission. .GPS. 1 u 41 64 377 73.440 8.210 0.853 -bigben.cac.wash .USNO.1 u 32 64 377 40.9728.035 1.217 -131.107.13.100 .ACTS. 1 u 6 64 377 52.141 19.335 1.796 -clock.sjc.he.ne .CDMA.1 u 57 64 377 53.710 8.522 0.623 ntpq clockv 33856 associd=33856 status=00f0 , 15 events, clk_unspec, device=Kinemetrics/TrueTime Receiver, timecode=049:18:34:08 , poll=10574, noreply=0, badformat=0, baddata=0, fudgetime1=0.000, stratum=0, refid=TRUE, flags=0 ntpq Shouldn't the TRUETIME clock assume the sys.peer condition at some point? This configuration has been running for about a week. What is the next step? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd on embedded risc
On Feb 19, 11:32 am, Rob nom...@example.com wrote: Unruh unruh-s...@physics.ubc.ca wrote: But a snapshot taken before the system has settled down to its long term behaviour is especially useless. The way ntp works is that intially it takes a while to settle down to its long term behaviour. With PPS control it usually settles down to usec offset but it takes of order of 10 hours to do so. Thus snapshots taken long before that are especially useless. If after 10 hours the system still has msec offsets from a PPS then there is something seriously wrong. He is not using a PPS in the sense that you are talking about. He uses the PPS support in gpsd which is written in user space and will settle to around 10us on a fast system that is not overloaded. On a slow embedded board it may be different, I have no experience with running gpsd on those. The server is not running all the time, and it used on platform that once booted, which need accurate time within minutes. We already run these tools on a fast x86 machine, and it syncs very quickly and provides very good accuracy. We are trying to migrate to the MOXA board, but performance is much poorer. I was more curious about things I could configure so that NTP would be usable on this slower machine, even if it took longer to get stable. Should I look into increasing baud rate of serial, less polling interval, etc? The linux distro is very small, and provides practically no tools, I'm not even sure how loaded the processor becomes with gpsd and ntpd. Is there an effective way of checking that it is not too much for machine? Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd on embedded risc
cnm3...@gmail.com cnm3...@gmail.com wrote: practically no tools, I'm not even sure how loaded the processor becomes with gpsd and ntpd. Is there an effective way of checking that it is not too much for machine? Thanks. gpsd is not particularly efficient (i.e. it will use some cpu), but it is no problem on a PC. You can always try the command uptime to see the load average of the system, it should be well below 1.00 You can also run ps ax and see what times appear in the TIME column for gpsd and ntpd. Compare those with the uptime of the system, to see how much CPU each of them uses. You could also use top to see what is running. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd on embedded risc
cnm3...@gmail.com writes: On Feb 19, 11:32=A0am, Rob nom...@example.com wrote: Unruh unruh-s...@physics.ubc.ca wrote: But a snapshot taken before the system has settled down to its long ter= m behaviour is especially useless. The way ntp works is that intially it takes a while to settle down to its long term behaviour. With PPS contr= ol it usually settles down to usec offset but it takes of order of 10 hour= s to do so. Thus snapshots taken long before that are especially useless. If after 10 hours the system still has msec offsets from a PPS then there = is something seriously wrong. He is not using a PPS in the sense that you are talking about. He uses the PPS support in gpsd which is written in user space and will settle to around 10us on a fast system that is not overloaded. On a slow embedded board it may be different, I have no experience with running gpsd on those. The server is not running all the time, and it used on platform that once booted, which need accurate time within minutes. We already run these Then do not use ntp. Its behaviour is converging to the correct time is very very slow. It is a completely inappropriate tool for the requirement that you have. chrony is much better. tools on a fast x86 machine, and it syncs very quickly and provides very good accuracy. We are trying to migrate to the MOXA board, but performance is much poorer. I was more curious about things I could configure so that NTP would be usable on this slower machine, even if it took longer to get stable. Should I look into increasing baud rate of serial, less polling interval, etc? The linux distro is very small, It is the algorithm that is at fault, not the machine. (well, the machine may also be at fault, but the algorithm simply cannot supply the accuracy you wish at the speed you want it). and provides practically no tools, I'm not even sure how loaded the processor becomes with gpsd and ntpd. Is there an effective way of checking that it is not too much for machine? Thanks. ps top Anyway, it isnot too much. Far far slower machines can handle it. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd on embedded risc
Rob nom...@example.com writes: Unruh unruh-s...@physics.ubc.ca wrote: But a snapshot taken before the system has settled down to its long term behaviour is especially useless. The way ntp works is that intially it takes a while to settle down to its long term behaviour. With PPS control it usually settles down to usec offset but it takes of order of 10 hours to do so. Thus snapshots taken long before that are especially useless. If after 10 hours the system still has msec offsets from a PPS then there is something seriously wrong. He is not using a PPS in the sense that you are talking about. He uses the PPS support in gpsd which is written in user space and will settle to around 10us on a fast system that is not overloaded. On a slow embedded board it may be different, I have no experience with running gpsd on those. I will accept 10usec, which is way way better than 17msec. Again, if he was connected for 10 hours ( well lets say 7 hr if your long term accuracy is 10usec) and he has 17 msec offset something is very wrong. If he was connected on hour, it is to be expected. Thus, how long was he connected? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd on embedded risc
On Feb 19, 3:16 pm, Unruh unruh-s...@physics.ubc.ca wrote: cnm3...@gmail.com writes: On Feb 19, 11:32=A0am, Rob nom...@example.com wrote: Unruh unruh-s...@physics.ubc.ca wrote: But a snapshot taken before the system has settled down to its long ter= m behaviour is especially useless. The way ntp works is that intially it takes a while to settle down to its long term behaviour. With PPS contr= ol it usually settles down to usec offset but it takes of order of 10 hour= s to do so. Thus snapshots taken long before that are especially useless. If after 10 hours the system still has msec offsets from a PPS then there = is something seriously wrong. He is not using a PPS in the sense that you are talking about. He uses the PPS support in gpsd which is written in user space and will settle to around 10us on a fast system that is not overloaded. On a slow embedded board it may be different, I have no experience with running gpsd on those. The server is not running all the time, and it used on platform that once booted, which need accurate time within minutes. We already run these Then do not use ntp. Its behaviour is converging to the correct time is very very slow. It is a completely inappropriate tool for the requirement that you have. chrony is much better. tools on a fast x86 machine, and it syncs very quickly and provides very good accuracy. We are trying to migrate to the MOXA board, but performance is much poorer. I was more curious about things I could configure so that NTP would be usable on this slower machine, even if it took longer to get stable. Should I look into increasing baud rate of serial, less polling interval, etc? The linux distro is very small, It is the algorithm that is at fault, not the machine. (well, the machine may also be at fault, but the algorithm simply cannot supply the accuracy you wish at the speed you want it). and provides practically no tools, I'm not even sure how loaded the processor becomes with gpsd and ntpd. Is there an effective way of checking that it is not too much for machine? Thanks. ps top Anyway, it isnot too much. Far far slower machines can handle it. We have been using NTP for long time, and it always converged to sub millisecond accuracy very quickly. Of course we used burst and iburst options in conf file, but I had disabled those on MOXA board, out of worries about CPU usage. I would say our requirements are at least 100usec accuracy for time, and that it synchronize within 5 minutes. NTP on our fast x86 machine always satisifed this, but having trouble on MOXA board. I was not aware of other programs for this purpose. I'm guessing chrony can act as NTP server for other machines running NTP to get time from? Does it provide level of accuracy and convergence time required? The data was collected after about 30 minutes I believe. I guess I'm so used to super fast convergence, that 30 minutes seemed like long time. Thanks for tip on uptime/ ps ax will try. Doesn't have top program built in, may try compiling it if first method doesnt work out. Thanks for the help so far, much appreciated. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] like a kid with a new toy (PPS jitter)
On Feb 10, 12:58 pm, Chris givemeafckingacctyoudou...@gmail.com
wrote:
On Feb 8, 7:40 pm, Dave Hart daveh...@gmail.com wrote:
Well, a modified serial driver that would timestamp CD transitions
would be ideal and would give better results than I'm getting. That's
not really practical unless you can start with Microsoft's existing
serial.sys code (it may be in theDDK, I don't know).
Interesting, short-term I may look at that as a solution. I don't
necessarily need to feed a single pin to multiple computers. Only one
of the Windows machines is critical, I could sync off that if I needed
to.
While I only have Windows 2003DDKinstalled at the moment, they do
include a complete serial device driver source project.
I've only done very minor Windows driver programming, but I may try to
download the newestDDKand give it a whirl.
// This bit is the delta data carrier detect. It is used to indicate
// that the data carrier bit (in this register) has *changed*
// since this register was last read by the CPU.
//
#define SERIAL_MSR_DDCD 0x08
and
if (ModemStatus (SERIAL_MSR_DCTS |
SERIAL_MSR_DDSR |
SERIAL_MSR_TERI |
SERIAL_MSR_DDCD)) {
I think the change would/could be done in modmflow.c or isr.c, but I'd
really have to do some reading to get comfortable with driver
programming. I'm not really sure how'd I'd signal an event to the ATOM
driver (perhaps through DeviceIoCtrl?)-
Take a look at http://davehart.net/ntp/refclock/serialpps-20090219.zip
There's a .patch file you can use to build it yourself instead of
using the binary in there.
Cheers,
Dave Hart
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] handling falseticker
On 2009-02-17, catia.lava...@bechtle.com catia.lava...@bechtle.com wrote: I have the following configuration Stratum 0 configuration: 1 x Stratum 0 (DCF Clock) -- 1 x Stratum 1 (let's give it the IP 10.1.1.1) 1 x Stratum 0 (GPS Clock) -- 1 x Stratum 1 (let's give it the IP 10.1.1.2) I do not have (for security policy) the possibility to give any other alternative (extern) time source to the Stratum 2 Servers. This means that my Stratum 2 Servers have only 2 servers. Obviously this configuration is not falseticker save. If correct time is critical to your application you should consider investing in a third time server with a different ref-clock. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
