Re: [ntp:questions] Assistance with PPS on Windows
It appears all I needed to do was swap the TX and CD pins to get it to start polling and synced to PPS. Thanks! Great! Now, a behavioral question. Will PPS be selected as the peer if and only if the peer marked preferred is also synced? What if I want PPS to act as a supplement to whichever of the stratum 1+ peers NTP sees available and decides to sync to? PPS will be the only stratum 0 reference source available to this system, but if the preferred peer goes down I would expect PPS to continue to correct the jitter of whichever other peer NTP decides to sync to (that doesn't seem to be the case). My understanding is that if you have the ATOM driver present and working (server 127.127.22.1 with serialpps.sys), that is used to refine whatever server NTP marks with a * in the ntpq -p display - the system peer. The ATOM driver itself will be marked with an o character. Also, it appears that while the preferred peer continues to be synced and polled every 64 seconds, the PPS peer seems to toggle from being a PPS peer to being rejected nearly every poll (of 16 seconds). Is this because the polling rate is different between the PPS source and the other sources, or is my serial cable too jittery? The PPS source claims to have an offset of +/- 10 ms and a jitter of between 2-3 ms depending on the poll. Thanks, Ken On a FreeBSD system, the PPS offset shows 0, and the jitter is currently 0.004 (4 microseconds). On the Windows systems here, PPS offset is typically less than 0.030 (30 microseconds), and the jitter less than 0.050 (50 microseconds). If you have a Garmin GPS 18x LVC with firmware later than 3.20, it's offset of the serial data from the PPS can exceed one second, which confuses NTP about which second the PPS actually was! In such circumstances, you can stop the serial data being used with a noselect modifier: server 127.127.20.1 minpoll 4 noselect Even without the kernel-mode serialpps.sys driver, the offset should be far less than 10 milliseconds, and the jitter far less than 2-3 milliseconds. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] reftime xmt in server reply valid?
Hi, RFC 5905 has in section 5.1.1.: /* * Verify valid root distance. */ if (r-rootdelay / 2 + r-rootdisp = MAXDISP || p-reftime r-xmt) return; /* invalid header values */ But it seems that ntpd (at least 4.2.6p3 and 4.2.7p162) doesn't have the reftime xmt check, only the distance check, is that correct? Thanks, -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
Assuming the Delay, Offset, and Jitter column units are msec, after letting it run overnight and half of the next day I still see PPS with 0 delay, 4.559 msec offset, and 3.123 msec jitter. The PPS source is the Meinberg TCR511PCI card, as seen here: http://www.meinberg.de/english/products/tcr511pci.htm The card itself is accepting the unmodulated IRIG B signal from the Arbiter 1093C clock, and shows itself as locked and synced with 100% signal. I suppose there could be a few reasons why PPS is so bad: 1) The cable used to move the IRIG signal from the clock to the Meinberg card acts as both the input (of the IRIG signal into the card's serial port) as well as the output (of the PPS signal into COM1 of the computer). We cut into the middle of the cable and made a tap with another RJ-45 endpoint which we plugged into the COM1 port. The sheer ugliness of the cable itself might be the cause. 2) The Meinberg card also outputs the standard Meinberg ASCII timecode over the serial cable...so there are technically three different signals travelling over this cut-into cable: IRIG B, PPS, and Meinberg's ASCII timecodes. The pins must be different, otherwise the card wouldn't be able to lock onto the IRIG B signal, right? 3) The system is normally under pretty heavy load, being only a single core system (with hyperthreading) and it averages 60-100% CPU usage most of the time. The problem is that the card only has one serial port and needs to accept unmodulated IRIG B as well as output PPS...our solution was to cut into the cable and tap another line out of it, so we can also connect it to the COM1 port. However, that means the IRIG signal is reaching both the Meinberg card as well as the PPS driver, potentially causing interference. Thoughts? I realize Windows isn't the best system for time accuracy, but I just want to see how close/stable it can get. Thanks, Ken On Wed, May 4, 2011 at 11:50 PM, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: It appears all I needed to do was swap the TX and CD pins to get it to start polling and synced to PPS. Thanks! Great! Now, a behavioral question. Will PPS be selected as the peer if and only if the peer marked preferred is also synced? What if I want PPS to act as a supplement to whichever of the stratum 1+ peers NTP sees available and decides to sync to? PPS will be the only stratum 0 reference source available to this system, but if the preferred peer goes down I would expect PPS to continue to correct the jitter of whichever other peer NTP decides to sync to (that doesn't seem to be the case). My understanding is that if you have the ATOM driver present and working (server 127.127.22.1 with serialpps.sys), that is used to refine whatever server NTP marks with a * in the ntpq -p display - the system peer. The ATOM driver itself will be marked with an o character. Also, it appears that while the preferred peer continues to be synced and polled every 64 seconds, the PPS peer seems to toggle from being a PPS peer to being rejected nearly every poll (of 16 seconds). Is this because the polling rate is different between the PPS source and the other sources, or is my serial cable too jittery? The PPS source claims to have an offset of +/- 10 ms and a jitter of between 2-3 ms depending on the poll. Thanks, Ken On a FreeBSD system, the PPS offset shows 0, and the jitter is currently 0.004 (4 microseconds). On the Windows systems here, PPS offset is typically less than 0.030 (30 microseconds), and the jitter less than 0.050 (50 microseconds). If you have a Garmin GPS 18x LVC with firmware later than 3.20, it's offset of the serial data from the PPS can exceed one second, which confuses NTP about which second the PPS actually was! In such circumstances, you can stop the serial data being used with a noselect modifier: server 127.127.20.1 minpoll 4 noselect Even without the kernel-mode serialpps.sys driver, the offset should be far less than 10 milliseconds, and the jitter far less than 2-3 milliseconds. Cheers, David ___ 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] Assistance with PPS on Windows
The most simple explanation is that the PPS signal out of the clock is just about as poor as NTP is reporting it to be. In other words everything is working fine. Nothing is wrong with your cable or with NTP or with Windows.Until some tests show otherwise I think it is best to assume the PPS signal going into the PC is close to how NTP is describing it. If you need better buy a GPS. You can get setup with one that does works at the nanosecond level for under $100. On Thu, May 5, 2011 at 9:32 AM, Ken Link kl...@numberzero.org wrote: Assuming the Delay, Offset, and Jitter column units are msec, after letting it run overnight and half of the next day I still see PPS with 0 delay, 4.559 msec offset, and 3.123 msec jitter. The PPS source is the Meinberg TCR511PCI card, as seen here: http://www.meinberg.de/english/products/tcr511pci.htm -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
On 2011-05-05, Chris Albertson albertson.ch...@gmail.com wrote: The most simple explanation is that the PPS signal out of the clock is just about as poor as NTP is reporting it to be. In other words everything is working fine. Nothing is wrong with your cable or with NTP or with Windows.Until some tests show otherwise I think it is best to assume the PPS signal going into the PC is close to how NTP is describing it. If you need better buy a GPS. You can get setup with one that does works at the nanosecond level for under $100. Uh, no. There is no way of getting the signal into the computer with nanosecond accuracy. 1usec is about it. The interrupt service routines, if you use a specialised driver for some interrupt driven card, will take about 1usec to service the interrupt. Thus while the card may deliver a pulse whose leading edge is within say 50ns of the correct time that is irrelevant if the computer itself cannot respond fast enough. But I agree, with a GPS you can get usec accuracy in the time delivered for less than $100. On Thu, May 5, 2011 at 9:32 AM, Ken Link kl...@numberzero.org wrote: Assuming the Delay, Offset, and Jitter column units are msec, after letting it run overnight and half of the next day I still see PPS with 0 delay, 4.559 msec offset, and 3.123 msec jitter. The PPS source is the Meinberg TCR511PCI card, as seen here: http://www.meinberg.de/english/products/tcr511pci.htm ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
On Thu, May 5, 2011 at 11:46 AM, unruh un...@wormhole.physics.ubc.ca wrote: If you need better buy a GPS. You can get setup with one that does works at the nanosecond level for under $100. Uh, no. There is no way of getting the signal into the computer with nanosecond accuracy. 1usec is about it. You are right. While A $60 GPS can produce a PPS with 1 sigma error on the order of a hand full of nanoseconds, the computer's interrupt handing has about 1 or 2 uSec resolution. So nanoseconds are wasted on an NTP server. But there are other things one can do with a PPS signal. For example you can discipline a local frequency standard. As long as you are installing a gps, may as well get one that works at this level as long as the cost is still reasonable. You can pay a lot more for a GPS that is literally 1,000 times worse. I have an older Motorola unit I paid $25 on ebay and it does about 50 nanoseconds one sigma. An interesting question is, If the computer's time resolution is 1 uSecond, how good must the GPS' PPS signal be so that the majority (90%) of the error is in the computer and not GPS. Off hand I think you want the GPS to be about one order of magnitude better or on order of 100 ns. But I've not done the math. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows time question.
In article ippj86$ldg$1...@dont-email.me, david- tay...@blueyonder.co.uk.invalid says... How critical is your time need? If it's within minutes, then the PC's clock is likely good enough. If it's in the UK or Europe, I would be surprised if pool servers did not get you well within the second perhaps within 100msec - particularly if you set the servers based on the country you're in. I suspect that if you need closer than tens of milliseconds, carrying round a GPS 18x LVC (which I jokingly suggested) may actually be necessary. NTP was designed when connections were nothing like as good as they are now, and is supposedly robust in those circumstances. It is designed for 24-hours operation, though. 73, David Not that accurate, within a second for what I need when traveling for work. But I often as not find the last choice of server(s) problematical, for some odd reason. Many hotel internet seems to be tunneled somewhere else, before it gets out to the wider www, with all the hidden latency and filtering etc. I did try synching with the office server via VPN, but that didn't work either. When I can get a vpn (one of three choices) up and working that is. Many hotels prevent vpn usage too! I guess, I could dive into the laptop, and find out why it's cmos clock keeps drifting as much as it does. Cheers. DaveB. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows time question.
In article slrnis0nra.4on.un...@wormhole.physics.ubc.ca, un...@wormhole.physics.ubc.ca says... On 2011-05-03, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: As the OP who started this (long and sometimes ammusing) thread... I do carry a GPS receiver with me, but sadly not PPS capable, I use it for location determination/tracking/navigating etc. Maybe I should include a GPS18 or 16 in the already bulging Laptop bag I lug arround. Even better if there were on on a USB stick, and you had a handy USB extension lead! Unfortunately , AFAIK, usb is terrible for delivering a PPS-- ie no interrupt lines-- the problem with having only two data lines (one beign signal ground) . How critical is your time need? If it's within minutes, then the PC's clock is likely good enough. If it's in the UK or Europe, I would be surprised if pool servers did not get you well within the second - perhaps within 100msec - particularly if you set the servers based on the country you're in. I suspect that if you need closer than tens of milliseconds, carrying round a GPS 18x LVC (which I jokingly suggested) may actually be necessary. NTP was designed when connections were nothing like as good as they are now, and is supposedly robust in those circumstances. It is designed for 24-hours operation, though. 73, David Two data line's, plus ground and 5V power. The data lines form a bidirectional diferential data bus, with a protocol more like a network than anything else. For low speed devices, there are bitbanged firmware routines about for the likes of the Atmel single chip devices, if it interests you. http://www.obdev.at/products/vusb/index.html I digress... DaveB ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
unruh wrote: Uh, no. There is no way of getting the signal into the computer with No pure sw way, no. nanosecond accuracy. 1usec is about it. The interrupt service routines, if you use a specialised driver for some interrupt driven card, will take about 1usec to service the interrupt. Thus while the card may deliver a pulse whose leading edge is within say 50ns of the correct time that is irrelevant if the computer itself cannot respond fast enough. But I agree, with a GPS you can get usec accuracy in the time delivered for less than $100. Add some extra hw, in the form of a very good crystal (surplus Rb) and a hw counter which starts to run on the PPS signal, so that the sw can query it to determine how much interrupt latency we got this time, and you get a FreeBSD box down in the dual-digit nanoseconds. Google phk! 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] Assistance with PPS on Windows
On 5/5/2011 3:59 PM, Chris Albertson wrote: On Thu, May 5, 2011 at 11:46 AM, unruhun...@wormhole.physics.ubc.ca wrote: If you need better buy a GPS. You can get setup with one that does works at the nanosecond level for under $100. Uh, no. There is no way of getting the signal into the computer with nanosecond accuracy. 1usec is about it. You are right. While A $60 GPS can produce a PPS with 1 sigma error on the order of a hand full of nanoseconds, the computer's interrupt handing has about 1 or 2 uSec resolution. So nanoseconds are wasted on an NTP server. But there are other things one can do with a PPS signal. For example you can discipline a local frequency standard. As long as you are installing a gps, may as well get one that works at this level as long as the cost is still reasonable. You can pay a lot more for a GPS that is literally 1,000 times worse. I have an older Motorola unit I paid $25 on ebay and it does about 50 nanoseconds one sigma. An interesting question is, If the computer's time resolution is 1 uSecond, how good must the GPS' PPS signal be so that the majority (90%) of the error is in the computer and not GPS. Off hand I think you want the GPS to be about one order of magnitude better or on order of 100 ns. But I've not done the math. My Motorola GPS claims +/- 50 NS on one of the edges of the PPS signal. I don't recall *which* edge. Getting the time into the computer takes X microseconds where X depends on the hardware and software. Windows' clock ticks every 17 milliseconds or something like that. Other operating systems also take a toll! If you *really* care about the nanoseconds, you don't feed them to the computer! If you must, please don't step in what comes out the other end! ;-) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
On Thu, May 5, 2011 at 1:13 PM, Terje Mathisen terje.mathisen at tmsw.no@ntp.org wrote: unruh wrote: Add some extra hw, in the form of a very good crystal (surplus Rb) and a hw counter which starts to run on the PPS signal, so that the sw can query it to determine how much interrupt latency we got this time, and you get a FreeBSD box down in the dual-digit nanoseconds. yes, FreeBSD and now Linux do run on a nanosecond clock and it's not at all hard to measure interrupt latency once per second. If you don't like designing you own electronics use the pictic. (Google pictic) it can measure the time from PPS to the interrupt being serviced to much better then a nanosecond. Costs about $50 to build and a PCBs are available.But this level of precision is not needed by most users. Some do. My goal is to to learn about the ionosphere by measuring how radio waves reflect off of it. Even though I have some of this equipment I'm still astonished that measurement at the sub-nanosecond level is both possible and affordable on a hobbyist budget. Not to long ago this was only possible in large university or government labs. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
On Thu, May 5, 2011 at 1:45 PM, Richard B. Gilbert rgilber...@comcast.net wrote: Getting the time into the computer takes X microseconds where X depends on the hardware and software. Windows' clock ticks every 17 milliseconds or something like that. Other operating systems also take a toll! The way it is typically done, that is to get sub-nanosecond measurements into a computer, is to do the actual measurement outside of the computer using some flavor of time interval counter and then send the data back to the computer over a serial line. In the simple case here of NTP. the PPS signal from the GPS gates a hardware clock to start. then later the interrupt enable line on the CPU chip stops the clock and some very long time later, perhaps milliseconds later the CPU reads the time from the hardware counter. People were reliable measuring nanoseconds this way 10 years ago. It works because we don't need to care how bad or unpredictable the computer's interrupt processing is because we measure it. Now days one can buy a time interval counter that can get down to about 250 picoseconds on ebay for $250.This is a 4U tall chuck of rack mounted gear made by HP in the 1980's. the new stuff is better. I read about one lab here at work using the term femtoseconds for the first time lately and he had graphs in those units on a computer. That's not me. My work uses uSeconds at most. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows time question.
Not that accurate, within a second for what I need when traveling for work. But I often as not find the last choice of server(s) problematical, for some odd reason. Many hotel internet seems to be tunneled somewhere else, before it gets out to the wider www, with all the hidden latency and filtering etc. I did try synching with the office server via VPN, but that didn't work either. When I can get a vpn (one of three choices) up and working that is. Many hotels prevent vpn usage too! I guess, I could dive into the laptop, and find out why it's cmos clock keeps drifting as much as it does. Cheers. DaveB. I would try first using an accurate server (home or work) directly, and see how your PC performs. That sets a best-case limit, and over hotel Wi-Fi it will be worse. I'm surprised it's as bad as more than a second out - but I'll have my portable with me this weekend and if the hotel has Wi-Fi I'll see what I get if I have the chance. 73, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
Richard B. Gilbert rgilber...@comcast.net wrote in message news:ojmdnuvxob4wkv7qnz2dnuvz_vydn...@giganews.com... [] Getting the time into the computer takes X microseconds where X depends on the hardware and software. Windows' clock ticks every 17 milliseconds or something like that. Other operating systems also take a toll! Recent version of Windows tend to run at ~1KHz, and you can set that for Windows XP as well. If you *really* care about the nanoseconds, you don't feed them to the computer! If you must, please don't step in what comes out the other end! ;-) Indeed! Windows with a serial PPS source can achieve offsets well under 250 microseconds - see: http://www.satsignal.eu/mrtg/feenix_ntp_2.html Ken is reporting offsets of nearly 5 milliseconds, so there's something else going on. I wonder what the spec of that PPS signal is, and how all the other stuff is multiplexed onto that cable? Worth a look with the 'scope, methinks. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
Ken Link wrote: The PPS source is the Meinberg TCR511PCI card, ... ... The pins must be different, otherwise the card wouldn't be able to lock onto the IRIG B signal, right? http://www.meinberg.de/download/docs/manuals/english/tcr511pci.pdf See: TCR511PCI IRIG Code controlled Radio Clock MANUAL 4.5 Pin assignments of the D-Sub-connector, Page 9 -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
unruh wrote: Uh, no. There is no way of getting the signal into the computer with nanosecond accuracy. 1usec is about it. The interrupt service routines, if you use a specialised driver for some interrupt driven card, will take about 1usec to service the interrupt. IIRC some BSD variants were claiming to get ~150ns? -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows time question.
David J Taylor wrote: I'm surprised it's as bad as more than a second out - but I'll have my portable with me this weekend and if the hotel has Wi-Fi I'll see what I get if I have the chance. I've been to some hotels in po-dunk (whatever the colloquial slang is) Europe; Wi-Fi via Sat to ISP to internet, over utilized, high latency, really low bandwidth, ... I've had colleagues in the middle of the South American jungle on similar corporate setups at base camps for new oil refineries. High bandwidth things like Adobe Flash Video will hog all their bandwidth, causing a lynch mob to hunt for the offender. Nothing like trickling Megs of firmware / software updates over something that makes analog dial-up modems look good sometimes. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
BlackLists wrote: unruh wrote: Uh, no. There is no way of getting the signal into the computer with nanosecond accuracy. 1usec is about it. The interrupt service routines, if you use a specialised driver for some interrupt driven card, will take about 1usec to service the interrupt. IIRC some BSD variants were claiming to get ~150ns? I can't locate the NanoKernel PPS doc (at least not finding the content I remember). I'm sure if I were to waste ^W spend enough time searching, I would eventually run over it again. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
On 2011-05-05, E-Mail Sent to this address will be added to the BlackLists Null@BlackList.Anitech-Systems.invalid wrote: unruh wrote: Uh, no. There is no way of getting the signal into the computer with nanosecond accuracy. 1usec is about it. The interrupt service routines, if you use a specialised driver for some interrupt driven card, will take about 1usec to service the interrupt. IIRC some BSD variants were claiming to get ~150ns? I do not believe that you can service an interrupt, and read a system clock that quickly. If you have specialised hardware on the PC (as someone suggested, a card with a counter on it which is switched on when the signal comes in) perhaps. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
On 2011-05-05, Chris Albertson albertson.ch...@gmail.com wrote: On Thu, May 5, 2011 at 1:13 PM, Terje Mathisen terje.mathisen at tmsw.no@ntp.org wrote: unruh wrote: Add some extra hw, in the form of a very good crystal (surplus Rb) and a hw counter which starts to run on the PPS signal, so that the sw can query it to determine how much interrupt latency we got this time, and you get a FreeBSD box down in the dual-digit nanoseconds. yes, FreeBSD and now Linux do run on a nanosecond clock and it's not at all hard to measure interrupt latency once per second. If you don't like designing you own electronics use the pictic. (Google pictic) it can measure the time from PPS to the interrupt being serviced to much better then a nanosecond. Costs about $50 to We are talking about synchronizing the PC clock to GPS to a certain accuracy. Not measuring time intervals between inputs to a certain accuracy. The interupt being serviced is the problem. The time it takes for an interrupt service routine to get the interrupt, and to read the system clock is certainly longer that 1ns as as far as I can see is closer to 1us. But if it is possible, I would love to hear about it. build and a PCBs are available.But this level of precision is not needed by most users. Some do. My goal is to to learn about the ionosphere by measuring how radio waves reflect off of it. Even though I have some of this equipment I'm still astonished that measurement at the sub-nanosecond level is both possible and affordable on a hobbyist budget. Not to long ago this was only possible in large university or government labs. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] general questions regarding ntpd on QNX
Hello! I’m usingntpd to synchronize some devices on QNX from one on QNX, synced from TSIP. With some simple app based on libntpq I query ntpd and get somesome status/offsets information. I need offsets to become about millisecondvery fast after start: tos mindist1.000 tinkerpanic 0 stepout 60 disableauth server127.127.22.0 maxpoll 4 fudge127.127.22.0 refid PPS0 server 127.127.8.0mode 10 prefer maxpoll 4 fudge127.127.8.0 refid TSIP time1 0.08 server10.1.1.11 prefer iburst maxpoll 4 broadcastclient * When I loose one ntp source, status become “sync_unspec” immediately, but when I loose PPS/ TSIP it may take 30 minutes to reset it to “sync_unspec”. However they become “unreachable” just fine after 2 minutes when I plug out antenna. So is it an error? * Time get’s slewed very slowly. It may take 2-3 hours to remove PPS offset of 20ms. Is it a good situation? Can I speed it up to 5 minutes or so? * When I use broadcast scheme offsets and jitters on ntp sources may become 10ms. Are there any differences with polling? * Can maxpoll decrease or increase slew time or accuracy? Thanks,Nickolay Orekhov ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Assistance with PPS on Windows
On Thu, May 5, 2011 at 6:16 PM, unruh un...@wormhole.physics.ubc.ca wrote: We are talking about synchronizing the PC clock to GPS to a certain accuracy. Not measuring time intervals between inputs to a certain accuracy. The interupt being serviced is the problem. The time it takes for an interrupt service routine to get the interrupt, and to read the system clock is certainly longer that 1ns as as far as I can see is closer to 1us. We don't really care how long it take to process the pulse with an interrupt. what we care about is the uncertaintain in the llength of this process. It is ALWAY took EXACTLY 10 us then we's have error much under a few ns. But not even this maters, see below But if it is possible, I would love to hear about it. The entire process is moved outside the computer. Use a good qualty hardware counter and the GPS' pulse cause the count to be transferred to a hardware buffer. the computer only needs to poll the buffer a few times per second and the result is sub-nanosecond timing. Yes it might take time even for hardware gates to switch but as long as this remains constant (clocked logic) we are OK. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] POSIX leap seconds versus the current NTP behaviour
Dave, Yes, that would be me. Long time no talk. POSIX time is also UTC, so that is in accord. Moreover, POSIX seconds since an epoch timestamps and NTP seconds since an epoch timestamps are UTC in exactly the same way, in that they represent a UTC timescale where all days are exactly 86400 seconds long, so NTP and POSIX seconds timestamps are precisely a constant apart (i.e. 1970-1900) at all times except, as I read it, when a leap second is inserted (that is, the second starting at 23:59:60.00 UTC) when they diverge by an additional second. They come back into alignment at 00:00:00. So we're not talking about the difference between POSIX and UTC time, we're instead talking about the difference between POSIX and NTP time at the point where both the latter timescales are going to have a discontinuity that UTC just doesn't have, and hence where neither timescale appears to be able claim superior UTCness; they're just different. And while the implementation of leap seconds may be much different than the code I wrote a long time ago the basic action which is taken is still the one I chose (or maybe it was already chosen in the fuzzball code and I just wrote code which did the same thing): it moves the NTP timescale back a second just after 23:59:60 UTC, while POSIX moves it back just before 00:00:00 UTC. I think these seem like equally fine choices, I was mostly wondering if there were reasons why they weren't equally fine choices that I was missing. While this may be trivia I guess it does inadvertently creep up on the more fundamental issue I've recently been thinking about: In a situation where ntpd and the kernel don't necessarily need to be in perfect agreement about the time, so that kernel timekeeping policy could be chosen for the benefit of the kernel and its time consumers, rather than ntpd, what would be done differently? E.g. if those time-consuming applications really want the POSIX version of the time is there a reason why this isn't a good choice? As for where this is coming from, I have a PCI-X board which allows the computer it is plugged into to read an adjacent GPS receiver's time with a precision of about 3 ns, and with an undetermined fixed-size sampling offset error that may (arguably) be as low as +/-6 ns with respect to the PPS signal at the computer's end of the coax from the receiver. In looking at how to transfer this time to the system clock, and now having a time source capable of measuring things with this precision, I discovered that the time delivered by a current NetBSD kernel (whose code seems to have been directly cloned from FreeBSD at some point) jitters by on the order of hundreds of nanoseconds or more even when it is free-running without adjustment, even using the 0.4 ns precision CPU cycle counter as the hardware time source. When I looked at why this was I came to the conclusion it was likely because the manipulations being done at hardclock() interrupt time were unavoidably incorporating (at least I couldn't figure out how to avoid it) the clock interrupt latency variations into the system time. The best way to fix that seemed to be to remove all clock-diddling code from hardclock(), which took the ntp code with it, and to replace that with procedures that were continuous with respect to a non-interrupting counter clock. This, in turn, constrains how the clock can be adjusted (though not the ultimate precision of an adjustment, which can be excellent; only how you get there is constrained), leaving no good way to add support for the ntp timex adjustment interface back in. To avoid being stuck with nothing better than adjtime() I had to design a new system call interface that wasn't the ntp one, but I wanted to do it in a way which wouldn't change anything from ntpd's point of view. To truncate a very long story, here's what I arrived at: What the ntp code in the kernel does is arithmetic, nothing more. The same arithmetic can be done, taking care to accumulate the results very precisely, without actually adjusting the system's clock. While this leaves the system with an unadjusted clock, it does allow ntpd to reliably convert the unadjusted system clock timestamps into the timestamps ntpd would have gotten if the adjustments had actually been done. The math can be done with sub-nanosecond precision at not a lot of additional cost (I do it with a 64-bit multiply and two adds), and all the computing can be done in user space without any loss of precision since it will arrive at the same numbers no matter where it does the math. This leaves one with the quite useless result that the system's clock is never adjusted, but otherwise leaves ntpd entirely as it was, seeing the world exactly as it would have had the adjustments been done, both internally and on-the-wire, with just an extra chunk of code operating where the system call interface would be to maintain the fiction. Of course I do want to
Re: [ntp:questions] Windows time question.
I've been to some hotels in po-dunk (whatever the colloquial slang is) Europe; Wi-Fi via Sat to ISP to internet, over utilized, high latency, really low bandwidth, ... I've had colleagues in the middle of the South American jungle on similar corporate setups at base camps for new oil refineries. High bandwidth things like Adobe Flash Video will hog all their bandwidth, causing a lynch mob to hunt for the offender. Nothing like trickling Megs of firmware / software updates over something that makes analog dial-up modems look good sometimes. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. Very interesting. How well did NTP work in those circumstances? I had the impression that NTP was designed to handle such links rather well. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
