Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
In article 4f6d3e94.4080...@c3energy.com, timekeepingntpl...@c3energy.com says... Hi all, I just discovered an interesting thing about the Sure board's serial - USB converter. I went ahead and installed the driver. With this serial - USB converter, which is a Silicon Labs CP210x chipset, no matter which USB port I plug it into, it becomes COM6, which was the next one available. With the Prolific based devices, including the TU-S9 and the BU-353, each subsequent USB port I plug into becomes a new com port, so those devices became COM3, COM4, and COM5 respectively as I plugged them into succeeding USB ports. I can see pros and cons either way. With the Prolific way, if I move the device to a different port, I have to have a different setup in the ntp.conf file, although you could probably have multiple setups, and if nothing is attached to a given port, then it gets ignored. With the Silicon Labs way, I only have to have one set of configuration options in ntp.conf. However, what happens if I plug in another device with the same chipset? I'm assuming the next one will become COM7. But, now, if I unplug both and plug them back into the same ports, but in the opposite sequence, I'll bet the original 1st device will now be COM7 and the original 2nd device will be COM6. I can see how this would cause some problems. I have not tested yet whether this board's USB port has a built in driver in Linux. Sincerely, Ron Ron. To fix wandering com ports in Windows, take a look at:- https://fedorahosted.org/fldigi/wiki/Documentation/HOWTO/Windows_USBSeri al (or:- http://preview.tinyurl.com/8592zvp Goes to the same site above.) Hope that helps a bit. Maybe there are similar tweaks in Linux? Dave B. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
DaveB wrote: Ron. To fix wandering com ports in Windows, take a look at:- https://fedorahosted.org/fldigi/wiki/Documentation/HOWTO/Windows_USBSeri al The most irritating issue I found under linux is that most manufacturers of commodity stuff like serial USB adapters don't programm serial numbers into their devices. Having a bunch of serial lines to different physical devices mapped in random is a major bother. ( One solution is to attach them in fixed order to one hub. then attach the hub. ports on one hub always seem to have the same enumeration order ) uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On Fri, Mar 23, 2012 at 06:12:11PM +0100, Terje Mathisen wrote: Miroslav Lichvar wrote: On Fri, Mar 23, 2012 at 11:49:19AM +0100, Terje Mathisen wrote: But I think a much bigger problem with the clock filter and PLL combination is that it can't drop more than 7 samples. When the network is saturated, it's usually better to drop much more than. If the increase in delay is 1 second and the clock is good to 10 ppm, it could wait for days before accepting another sample. Oh but it can! Check out huff-puff! You can easily tell ntpd to coast past multi-hour periods of excessive delays/traffic. With huff-puff it doesn't really coast, it just shifts the offset in one direction by increase in the delay. This works well when the link is saturated in one direction, but under normal conditions it makes the timekeeping worse, so you need to consider if it's worth enabling. If you want to see why ntpd can't drop more samples you can block the NTP packets in firewall, e.g. in a cycle which allows 4 packets and drops 60. The PLL will be unstable, frequency will be jumping up and down, offset orders of magnitude higher. This is the reason why some other NTP implementations were created. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
In article sdp549-8mj@klein-habertwedt.de, u...@klein-habertwedt.de says... DaveB wrote: Ron. To fix wandering com ports in Windows, take a look at:- https://fedorahosted.org/fldigi/wiki/Documentation/HOWTO/Windows_USBSeri al The most irritating issue I found under linux is that most manufacturers of commodity stuff like serial USB adapters don't programm serial numbers into their devices. Having a bunch of serial lines to different physical devices mapped in random is a major bother. ( One solution is to attach them in fixed order to one hub. then attach the hub. ports on one hub always seem to have the same enumeration order ) uwe There is some sort of unique ID. As, if you do the trick to nail a Virtual COM port to say, COM4 while using one particular USBRS232 device. Remove it, and re-plug to check it comes back as the same port. But then connect an identical device, from the same maker etc, in that same USB socket, Windows (at least) will decide it's new hardware and you'll have to go round the loop again. There is a unique ID in there somewhere, that along with the hub(s) it's attached via, form a unique instance ID. In that respect, USB is a bit like a network, where there are unique MAC addresses (yes, I know they can be cloned by some devices) Just that it's not brought out in any UI for us to use. Cheers. Dave B. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Trimble Resolution SMT on Ubuntu 12.04
I use Trimble Resolution SMT to sync time for a Ubuntu 12.04 server (kernel 3.2.0). Trimble send NMEA to /dev/ttyUSB1(9600 8N1) on Ubuntu server PPS signal connect ACK pin on /dev/parport0 . Ubuntu load Linux-PPS module( PPS_parport clear_wait=0) to create PPS device /dev/pps0 I use verify the /dev/pps0 using rising edge by ppstest /dev/pps0 trying PPS source /dev/pps0 found PPS source /dev/pps0 ok, found 1 source(s), now start fetching data... source 0 - assert 1332775909.500413150, sequence: 249302 - clear 0.0, sequence: 0 source 0 - assert 1332775910.500456132, sequence: 249303 - clear 0.0, sequence: 0 source 0 - assert 1332775911.500499213, sequence: 249304 - clear 0.0, sequence: 0 --- To verify the NMEA message , I link /dev/ttyUSB1 to /dev/gps1 --- #cat /dev/gps1 $GPRMC,153343.000,A,4529.904930,N,07343.904831,W,0.241,325,260312,,,A*6F $GPGGA,153344.000,4529.905010,N,07343.904879,W,1,3,3.17,12.368,M,-32.087,M,,*5E --- I create the /etc/ntp.conf: - server 127.127.20.1 mode 17 prefer # NMEA RMC/GGA 9600bps fudge 127.127.20.1 time2 0.01 server 127.127.22.0 minpoll 4 maxpoll 4 # PPS ATOM fudge 127.127.22.0 flag2 0 flag3 1 driftfile /var/lib/ntp/ntp.drift -- after ntpd run 48hours, ntpq -p: remote refid st t when poll reach delay offset jitter == xGPS_NMEA(1) .GPS. 0 l 44 64 377 0.000 -214.54 25.464 xPPS(0) .PPS. 0 l 11 16 377 0.000 -174.60 4.981 I have no idea why I got this result . what do I miss for config? by the way , I compile ntpd from source , not using ntpd from Ubuntu. Thanks for your time to read my question. give me some light please. regards, geng ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
Even with multimedia timer on its smallest resolution, you will run into the 1 ms barrier under windows. To do better you need to enable interpolation, this simple operation will improve your jitter by at least 10x. Le 25/03/2012 23:06, Ron Frazier (NTP) a écrit : On 3/24/2012 12:46 PM, unruh wrote: On 2012-03-24, Ron Frazier (NTP)timekeepingntpl...@c3energy.com wrote: I now have the PPS circuit working on the Sure board. I have not soldered it yet. I just taped a jumper wire between the PPS test point at the edge of the board and the DCD pin 1 on the RS-232 port. The serial data is coming in through the Trendnet TU-S9 serial - USB converter, which is passing DCD. I'm getting + .5 / - 1.5 ms offsets. The PPS is nowhere to be seen on the statistics screen, but it is obviously working. I don't know why it's not more centered around zero, Peaked around zero in comparison with what? Remember that the serial to usb of dcd and then the decoding of that interrupt is going to institute delays. It should always be later than true time. I just meant that the offsets were shifted more toward the positive on the graph rather than being centered around zero. They seem to be centered around zero now. and maybe that will change. However, my total peak to peak range of offset variance is 2 ms, and that's coming through USB. If I can maintain that level of accuracy, and it's consistent with UTC, then I'm very happy. That's plenty good for my purposes. I still may try to run it through a real serial port on another machine just for kicks. You can get 1us, not 1ms that way. But if a factor of 1000 is irrelevant for you, then what you have is fine. I don't have to have 1 us. I just want the computer's clocks to be right and to be doing better than I can with internet servers. In that regard, any offsets better than 50 ms are good. I plan to test this GPS for a while and and make sure it's stable. Then, I want to set up every computer so it can use the GPS if it's attached. Then, I'll try the real serial thing on the PC that has a port. Eventually, I want to make probably that one a server for all the rest. I'll probably have to give the server a fixed IP address in my router since those can change when DHCP assigns them. Sincerely, Ron ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Multiple 'prefer' servers
On 3/21/2012 10:19, Markus Schöpflin wrote: Am 21.03.2012 04:20, schrieb A C: Out of curiosity, what does ntpd do when multiple servers are marked 'prefer'. http://www.eecis.udel.edu/~mills/ntp/html/prefer.html#prefer While the rules do not forbid it, it is usually not useful to designate more than one source as preferred; however, if more than one source is so designated, they are used in the order specified in the configuration file. If the first one becomes un selectable, the second one is considered and so forth. I just tested this and with 4.2.7p259 it doesn't follow the rule. In my case, I have five Internet servers listed first in the config file, then ATOM and then SHM. If I configure all the Internet servers and the SHM server as prefer, it actually selects the SHM first even though it's last in the config file. On the billboard, SHM is second (after ATOM) and the rest of the Internet servers are below that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Using ATOM with any system peer
Would it be possible to modify the ATOM driver such that it will be activated when a system peer is selected and avoid the need to use a prefered server? As has been mentioned in the past the prefer keyword disrupts the clock selection algorithm. I want ntpd to continue using clock selection but still have the ATOM working when something is a system peer. The reason I ask is I've discovered an interesting race condition last night. As an experiment I tried setting everything to prefer so that there would be some kind of selection process occurring. Granted it's just in order of the clocks but that's better than one prefer and nothing else ever being selected. If there is a glitch that drops the other clocks, it picks one clock and tries to synchronize again. Unforunately (and noted in another email I just sent) the SHM refclock is selected first even though it is last in the configuration file. Now the race begins. The SHM is fed from the GPS receiver, so the offset wanders around a bit. But because it's marked as one of several preferred peers, it gets selected anyway (even though it shouldn't by the multiple prefer rules). The wandering clock isn't stable enough to tame the system clock which, for the past four hours, has been performing clock steps of several tenths of seconds every few minutes. It never fully stabilizes and ntpd ends up resetting everything and starting over after each clock step. I have to kill and restart the process to allow the iburst process to tame the clock. If I could avoid the prefer entirely, then ntpd would settle on any server available, clean up the clock and then activate ATOM to control the ticking. If a glitch occurs, the clocks are chosen again in the normal process and then ATOM is reactivated. The serial port drivers aren't going to be fixed anytime soon to support double-opens required to use something like NMEA with PPS so I'd just like to relax the requirement that a peer be marked as preferred for ATOM to work and just accept any system peer that the clock selection algorithm chooses as the current peer. If everything is working like it should, then it shouldn't matter if the peer hops around because ATOM controls the ticks and the peers won't be far off from each other to number the seconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
On Mar 24, 10:30 am, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote: Here are my config lines: # COM5 57600 windows lines for testing gps selected as main source - gpgga 57600 baud server 127.127.22.5 minpoll 3 maxpoll 3 # PPS fudge 127.127.22.5 flag2 0 refid PPS # PPS standard polarity server 127.127.20.5 prefer minpoll 3 maxpoll 3 mode 66 # NMEA fudge 127.127.20.5 time2 0. refid GPS1 # use WITH PPS Also, why doesn't the PPS show up in my status screen anywhere? I know it's working, based on the graphs. Sincerely, Ron Ron: Here are my ntp.conf lines I use for my SureGPS running under FreeBSD plugged into Com Port 1 ( /dev/cuau0). I also create link (ln -s) from /dev/gps0 to cuau0. # # server 127.127.20.0 mode 18 minpoll 4 maxpoll 4 prefer fudge 127.127.20.0 flag1 1 flag3 1 refid PPS # # ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trimble Resolution SMT on Ubuntu 12.04
Hi Geng, I don't know if this will help or not, but the following things came to mind. I am running Windows at the moment, but Linux should be similar. I plan to try all this in Ubuntu eventually. When I was using NMEA only data, I had to have a bigger fudge factor, like this: fudge 127.127.20.5 time2 0.3710 refid GPS1 # use WITHOUT PPS However, when I started using PPS, I found that the fudge factor was messing things up, so now I use this: fudge 127.127.20.5 time2 0. refid GPS1 # use WITH PPS Note that I stuck the fudge factor in there for readability. However, its value is 0. The other thing that occurred is that your clock may be too far out from gps time to begin with. Try shutting down NTPD. Note, if you compiled NTP yourself, the startup and shutdown scripts may not be in the right places. I think the command is: sudo /etc/init.d ntp stop Then run this command to sync your clock with the NIST server in New York. If you're not in the US, substitute another server name. ntpdate -b nist1-ny.ustiming.org Now your clock should be very close to NIST or UTC. Now, restart NTPD. sudo /etc/init.d ntp start Wait a few minutes and run ntpq -p to see what's happening. Also, make sure NTPD is reading the correct config file and that you don't have two of them around or something. Finally, I'd recommend putting minpoll 4 maxpoll 4 on your NMEA line to match your PPS line. I'm using a value of 3 on mine, which polls every 8 seconds. Sincerely, Ron On 3/26/2012 12:06 PM, G wrote: I use Trimble Resolution SMT to sync time for a Ubuntu 12.04 server (kernel 3.2.0). Trimble send NMEA to /dev/ttyUSB1(9600 8N1) on Ubuntu server PPS signal connect ACK pin on /dev/parport0 . Ubuntu load Linux-PPS module( PPS_parport clear_wait=0) to create PPS device /dev/pps0 I use verify the /dev/pps0 using rising edge by ppstest /dev/pps0 trying PPS source /dev/pps0 found PPS source /dev/pps0 ok, found 1 source(s), now start fetching data... source 0 - assert 1332775909.500413150, sequence: 249302 - clear 0.0, sequence: 0 source 0 - assert 1332775910.500456132, sequence: 249303 - clear 0.0, sequence: 0 source 0 - assert 1332775911.500499213, sequence: 249304 - clear 0.0, sequence: 0 --- To verify the NMEA message , I link /dev/ttyUSB1 to /dev/gps1 --- #cat /dev/gps1 $GPRMC,153343.000,A,4529.904930,N,07343.904831,W,0.241,325,260312,,,A*6F $GPGGA,153344.000,4529.905010,N,07343.904879,W,1,3,3.17,12.368,M,-32.087,M,,*5E --- I create the /etc/ntp.conf: - server 127.127.20.1 mode 17 prefer # NMEA RMC/GGA 9600bps fudge 127.127.20.1 time2 0.01 server 127.127.22.0 minpoll 4 maxpoll 4 # PPS ATOM fudge 127.127.22.0 flag2 0 flag3 1 driftfile /var/lib/ntp/ntp.drift -- after ntpd run 48hours, ntpq -p: remote refid st t when poll reach delay offset jitter == xGPS_NMEA(1) .GPS.0 l 44 64 3770.000 -214.54 25.464 xPPS(0) .PPS.0 l 11 16 3770.000 -174.60 4.981 I have no idea why I got this result . what do I miss for config? by the way , I compile ntpd from source , not using ntpd from Ubuntu. Thanks for your time to read my question. give me some light please. regards, geng -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Using ATOM with any system peer
This has been on my mind for a while and it's also been a while since I thought hard about it or looked at the code. I think one of the things we need is for a PPS source to have a health status associated with it, as the original PPS sources were pretty much stand-alone devices that could be adjusted by a process outside of NTP to fine-tune the frequency. Now, we have some GPS devices (for example) that will emit PPS signals even when the device is not fully sync'd, and we have some PPS devices (Rb clocks) that may emit PPS but expect you to look at device status via an RS-232 connection to see how healthy or accurate that PPS signal is. I could be wrong, but I think there is value in understanding the context in which a wide variety of PPS sources operate so we can design a robust interface for them. Should we create a topic on the support wiki for this discussion? H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
On 3/26/2012 2:15 PM, Gom wrote: Even with multimedia timer on its smallest resolution, you will run into the 1 ms barrier under windows. To do better you need to enable interpolation, this simple operation will improve your jitter by at least 10x. Hi Gom, I'm trying various options of NTPD_USE_INTERP_DANGEROUS, flag3 on the 20 driver, and process priority to see what has any effect. Keep in mind though, I'm still running everything through a serial - usb converter so that probably puts a limit on things. Sincerely, Ron Le 25/03/2012 23:06, Ron Frazier (NTP) a écrit : On 3/24/2012 12:46 PM, unruh wrote: On 2012-03-24, Ron Frazier (NTP)timekeepingntpl...@c3energy.com wrote: I now have the PPS circuit working on the Sure board. I have not soldered it yet. I just taped a jumper wire between the PPS test point at the edge of the board and the DCD pin 1 on the RS-232 port. The serial data is coming in through the Trendnet TU-S9 serial - USB converter, which is passing DCD. I'm getting + .5 / - 1.5 ms offsets. The PPS is nowhere to be seen on the statistics screen, but it is obviously working. I don't know why it's not more centered around zero, Peaked around zero in comparison with what? Remember that the serial to usb of dcd and then the decoding of that interrupt is going to institute delays. It should always be later than true time. I just meant that the offsets were shifted more toward the positive on the graph rather than being centered around zero. They seem to be centered around zero now. and maybe that will change. However, my total peak to peak range of offset variance is 2 ms, and that's coming through USB. If I can maintain that level of accuracy, and it's consistent with UTC, then I'm very happy. That's plenty good for my purposes. I still may try to run it through a real serial port on another machine just for kicks. You can get 1us, not 1ms that way. But if a factor of 1000 is irrelevant for you, then what you have is fine. I don't have to have 1 us. I just want the computer's clocks to be right and to be doing better than I can with internet servers. In that regard, any offsets better than 50 ms are good. I plan to test this GPS for a while and and make sure it's stable. Then, I want to set up every computer so it can use the GPS if it's attached. Then, I'll try the real serial thing on the PC that has a port. Eventually, I want to make probably that one a server for all the rest. I'll probably have to give the server a fixed IP address in my router since those can change when DHCP assigns them. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
On 3/26/2012 5:00 AM, DaveB wrote: In article4f6d3e94.4080...@c3energy.com, timekeepingntpl...@c3energy.com says... Hi all, I just discovered an interesting thing about the Sure board's serial - USB converter. I went ahead and installed the driver. With this serial - USB converter, which is a Silicon Labs CP210x chipset, no matter which USB port I plug it into, it becomes COM6, which was the next one available. With the Prolific based devices, including the TU-S9 and the BU-353, each subsequent USB port I plug into becomes a new com port, so those devices became COM3, COM4, and COM5 respectively as I plugged them into succeeding USB ports. I can see pros and cons either way. With the Prolific way, if I move the device to a different port, I have to have a different setup in the ntp.conf file, although you could probably have multiple setups, and if nothing is attached to a given port, then it gets ignored. With the Silicon Labs way, I only have to have one set of configuration options in ntp.conf. However, what happens if I plug in another device with the same chipset? I'm assuming the next one will become COM7. But, now, if I unplug both and plug them back into the same ports, but in the opposite sequence, I'll bet the original 1st device will now be COM7 and the original 2nd device will be COM6. I can see how this would cause some problems. I have not tested yet whether this board's USB port has a built in driver in Linux. Sincerely, Ron Ron. To fix wandering com ports in Windows, take a look at:- https://fedorahosted.org/fldigi/wiki/Documentation/HOWTO/Windows_USBSeri al (or:- http://preview.tinyurl.com/8592zvp Goes to the same site above.) Hope that helps a bit. Maybe there are similar tweaks in Linux? Dave B. Hi Dave B, Thanks for sharing this. I'm not sure I'm going to tweak the ports, but at least I'll know how. It actually confuses me a bit. Here's a quote from the site: quote on -- When you later re-connect the *same* USBSerial adapter, to the *same* USB port on the PC, it will re-appear again at the Com Port you just assigned it to, i.e. It's a Sticky setting. But, if you have a different adapter (even the same make model) or connect the same one to a different USB port, you'll have to do all this again. -- quote off Here's what happened to me. When I got my BU-353 GPS, which uses a Prolific chip set internally, I plugged it into each USB port in turn, and here is what happened: Plugged into USB1 - was assigned to COM3 Plugged into USB2 - was assigned to COM4 Plugged into USB3 - was assigned to COM5 Then I tried my Trendnet TU-S9 serial - USB adapter, which uses the same chipset. From the above verbiage, I would expect to see that assigned to COM6, COM7, and COM8. But that is not what happened. Here is what actually happened. Plugged into USB1 - was assigned to COM3 Plugged into USB2 - was assigned to COM4 Plugged into USB3 - was assigned to COM5 This, in fact loaded the same driver as it did when I plugged in the BU-353. So, it appears that they're not reading any sort of serial number, since it didn't recognize that I'd plugged in a different adapter. To make matters even more confusing, if I plug the USB cord from the Sure board into each port in turn, I get this: Plugged into USB1 - was assigned to COM6 Plugged into USB2 - was assigned to COM6 Plugged into USB3 - was assigned to COM6 None of this is a big deal at the moment. However, if I did have two Sure boards, and I wanted to hook them up at the same time, I would definitely want them to appear on different COM ports; and, if I swap the cables, it would be preferable that each still appear on the same COM port it did before. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
Hi David, See below. On 3/24/2012 12:11 PM, David J Taylor wrote: Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message news:4f6dda72.30...@c3energy.com... [] Hi David, You appear to be up early. I'm curious to know what time this email says it arrived. If it says it arrived at about 1030, then that's my time. If it says it arrived at about 14:30, then that's your time. I am on UTC here, and the posting was made in the (very) early hours. Since I wrote that, it seems to have centered itself around zero. I now have a very nice + 1.2 ms / - 1.2 ms offset pattern. Since I've been struggling to get anything under 50 ms with other technology, this looks really sweet to me. http://dl.dropbox.com/u/9879631/Sure%20board%20first%20night%20pt1.jpg http://dl.dropbox.com/u/9879631/Sure%20board%20first%20night%20pt2.jpg Conversion of these images to jpeg reduced the clarity a bit, but you can still see what's happening. I vaguely recall that USB has a polling interval of ~1 millisecond. Additionally, unless you use interpolation, Windows timestamping introduces a further 1 millisecond quantisation in its timestamps of the USB data (that 0.977 ms jitter is the signature of plain Windows timestamps), so your +/- 2 milliseconds max seems to be of the correct order MICROSECONDS, did you say? I'm nowhere near that territory with everything going through a serial - USB converter. However, I'm quite happy with 1.2 ms under the circumstances. That millisecond polling is the limiting factor, go for a hardware serial port and the kernel-mode timestamping and you're an order or two better again. I am NOW assuming that my clock is more accurate than the internet clocks. I am NOW hoping that neither will appear to be drifting away and that nothing in the system will be having routine heart attacks. Fingers crossed. For the reasons mentioned above you could be up to a couple of milliseconds out in absolute terms. I notice there is a difference between my clock and the average internet clock reading. Hypothetically, even though mine is probably closer to UTC than those readings, if I wanted to shift my offset to match them, so NTP won't clockhop, how as long as the GPS is working, how would I do that? Here are my config lines: # COM5 57600 windows lines for testing gps selected as main source - gpgga 57600 baud server 127.127.22.5minpoll 3 maxpoll 3 # PPS fudge 127.127.22.5 flag2 0 refid PPS # PPS standard polarity server 127.127.20.5 prefer minpoll 3 maxpoll 3 mode 66 # NMEA fudge 127.127.20.5 time2 0. refid GPS1 # use WITH PPS Also, why doesn't the PPS show up in my status screen anywhere? I know it's working, based on the graphs. Sincerely, Ron Check the driver configuration. PPS requires the kernel-mode timestamping of the DCD line going active, and that's only available in Dave Hart's serial-pps driver/DLL. For the same PPS timesamps in other drivers would require e.g. USB providers to update their drivers as well, which isn't at all likely to happen. If you knew that the average delay between true start-of-second and your PC timestamping the USB/serial packet was 1.5 milliseconds, you could probably use something like: fudge 127.127.20.5 time2 0.0015 refid GPS1 Looking at your plot of peer offset, though, that might bring the best Internet server /nearer/ to zero offset. BTW: you may find that PNG is a better format for saving graphics - except for the lines which are very noisy and would increase the file size. PNG is lossless, and can produce quite small files of plots. That's one reason my program saves data in that format. I'm delighted with your results so far. Cheers, David That's a great tip about PNG files. I never knew anything about them. At this point, I don't know if I'll even try to sync the GPS with the internet servers, since I'm getting more accurate time from the GPS than I can from the internet. I may change my mind if NTPD ends up clock hopping too much once I release the internet servers to run as a backup. I'm looking forward to playing with the real serial port on my other machine a bit. I'm not quite finished testing the USB port on this laptop though. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
