Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
unruh wrote: No I would not. That is not what ntpd does. It really does throw away 7 of the samples and never uses them. The whole question is what is the best statistic to use. I do not believe that the "shortest roundtrip time" is that best statistic. If you could convince me it is, I would be more than happy to have ntp use it. In _some_ scenarios, keeping only the minimum rttsample is indeed the best approach: I have been working for a couple of years on the new cell phone network in Norway (we've replaced everything, including every single base station!). Even if GSM and related cell phone standards does not require the same absolute timing precision as some of those used in the US, there is still a requirement for a _very_ stable frequency base in order to do transparent handover from one base station to the next, and the relative offset determines the maximum doppler that can be handled. In order to be considered OK, we can't accept more than 50 ppb frequency offset. Handling this with up to 50 ms sawtooth variation (with periods up to several hours) in the one-way latency means that the vendor require sampling periods of up to 10+ hours, with multiple packets/second and then keeping a single packet at the end. Of course, the main requirement is to start with a _very_ stable time base, in this case double-oven OCXOs with daily drift rates in the fractional ppb range! IF the roundtrip times were to vary by factors of 2 from one instance to the next, I might be persuaded that it was the best statistic. But it does not in almost all cases where ntpd is used. It varies by a few percent ( with maybe an occasional blip with larger delays.) I have huge reams of data to support my statement. So do I, and I would have agreed with you a month ago, but I have gotten actual measurement data from the base station vendor showing really _huge_ packet-to-packet jitter values. Terje - "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] PSYCHO PC clock is advancing at 2 HR per second
On Fri, Mar 23, 2012 at 11:49:19AM +0100, Terje Mathisen wrote: > unruh wrote: > >No I would not. That is not what ntpd does. It really does throw away 7 > >of the samples and never uses them. The whole question is what is the > >best statistic to use. I do not believe that the "shortest roundtrip > >time" is that best statistic. If you could convince me it is, I would be > >more than happy to have ntp use it. > > In _some_ scenarios, keeping only the minimum rttsample is indeed > the best approach: Yes, it depends on the network jitter and clock stability. But ntpd doesn't try to estimate the stability and uses a fixed dispersion rate and Allan intercept in the filter algorithm (15 ppm and 1024 sec by default). By tweaking the constants you can change the ratio of dropped samples. 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. > In order to be considered OK, we can't accept more than 50 ppb > frequency offset. > > Handling this with up to 50 ms sawtooth variation (with periods up > to several hours) in the one-way latency means that the vendor > require sampling periods of up to 10+ hours, with multiple > packets/second and then keeping a single packet at the end. That seems excessive. Do they set the frequency directly just from the last two samples? With PLL or similar, increasing the time constant accordingly might be a better approach. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
On Fri, 23 Mar 2012, unruh wrote: On 2012-03-22, Karel Sandler wrote: On Thu, 22 Mar 2012, unruh wrote: In addition, it should be noted that in the case of serial PPS the system time may lag behind UTC by tens of microseconds. tens of microseconds? Where does this come from? The interrupt processing time is not that long. I took these numbers from http://www.cesnet.cz/doc/techzpravy/2007/ntp-server/. Measurement of these delays is described in some articles listed in references. Well, if correct that is hugely different from the latency on a parallel port. As I said I tested that. I wrote a driver which grabbed a timestamp, wrote to one of the output pins of a parallel port which was connected to the ACK pin on that parallel port. The interupt service routine which serviced the ACK interrupt immediately timestamped the interrupt. (ie the second instruction grabbed a timestamp. The first checked the ack pin to make sure this was a parallel interrupt) the delay between those two timestamps (usec precision) was 1-2us. Far from 8-50 us that they claim. I have not done the equivalent (Parallel port pin to serial port DCD interrupt) but I would be very surprized if it is that much worse. Note that the fluctuations are not that much worse. I have run a GPS via the serial port DCD and find offsets that fluctuate around the 1us standard deviation (using the nanosecond timer in Linux) with occasional excursions. While this does not measure the latency, it does measure the fluctuations in the latency and then are less than 1us. (Note that in the reference in the paper you quote, the fluctuations in the latency are much large than this-- normally about 2us, but sizable tails out to 30us.) I suspect that the methodology is bad-- ie, is most of the delay in switching on the RTS pin rather than in the interupt latency? I did not participate in these measurements and I can not comment on their methodology. High delays correspond to measurements at high load, but it seems that the lower limit is not negligible. Especially compared to offset fluctuations, which can be an order of magnitude smaller. On my site I can watch more than half a dozen stratum-1 servers with delays below 2ms. All show each other more or less stable differences that probably can not be entirely attributed to asymmetries of the network. Our stratum-1 server uses GPS170PCI card with its own clock and a number of useable outputs. One option is to use the PPS output (accuracy garanted better than 250ns) connected to the DCD pin of the serial port. Fluctuations of the offset were below 2us with occasional blips. Now I use another option. Blips are gone, offsets fluctuate just below 1us standard deviatiation and, to my surprise, new option shifted the offset by 32us. System driven by PPS had time delay. Unfortunately the resolution of SHM refclock is limited to 1us, but that is another matter. In any case, the relationship of the system time to UTC and calibration of stratum-1 server is an interesting problem. Karel Sandler ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
On Mar 23, 9:49 am, Karel Sandler wrote: > On Fri, 23 Mar 2012, unruh wrote: > > On 2012-03-22, Karel Sandler wrote: > >> On Thu, 22 Mar 2012, unruh wrote: > > In addition, it should be noted that in the case of serial PPS > the system time may lag behind UTC by tens of microseconds. > > >>> tens of microseconds? Where does this come from? The interrupt > >>> processing time is not that long. > > >> I took these numbers from > >>http://www.cesnet.cz/doc/techzpravy/2007/ntp-server/. > >> Measurement of these delays is described in some articles listed in > >> references. > > > Well, if correct that is hugely different from the latency on a parallel > > port. > > As I said I tested that. I wrote a driver which grabbed a timestamp, > > wrote to one of the output pins of a parallel port which was connected > > to the ACK pin on that parallel port. The interupt service routine which > > serviced the ACK interrupt immediately timestamped the interrupt. (ie > > the second instruction grabbed a timestamp. The first checked the ack > > pin to make sure this was a parallel interrupt) the delay between those > > two timestamps (usec precision) was 1-2us. Far from 8-50 us that they > > claim. > > > I have not done the equivalent (Parallel port pin to serial port DCD > > interrupt) but I would be very surprized if it is that much worse. > > > Note that the fluctuations are not that much worse. I have run a GPS via > > the serial port DCD and find offsets that fluctuate around the 1us > > standard deviation (using the nanosecond timer in Linux) with occasional > > excursions. While this does not measure the latency, it does measure the > > fluctuations in the latency and then are less than 1us. (Note that in > > the reference in the paper you quote, the fluctuations in the latency > > are much large than this-- normally about 2us, but sizable tails out to > > 30us.) > > > I suspect that the methodology is bad-- ie, is most of the delay in > > switching on the RTS pin rather than in the interupt latency? > > I did not participate in these measurements and I can not comment on their > methodology. High delays correspond to measurements at high load, but it > seems that the lower limit is not negligible. Especially compared to > offset fluctuations, which can be an order of magnitude smaller. > > On my site I can watch more than half a dozen stratum-1 servers with > delays below 2ms. All show each other more or less stable differences that > probably can not be entirely attributed to asymmetries of the network. > > Our stratum-1 server uses GPS170PCI card with its own clock and a number > of useable outputs. One option is to use the PPS output (accuracy garanted > better than 250ns) connected to the DCD pin of the serial port. > Fluctuations of the offset were below 2us with occasional blips. Now I use > another option. Blips are gone, offsets fluctuate just below 1us standard > deviatiation and, to my surprise, new option shifted the offset by 32us. > System driven by PPS had time delay. Unfortunately the resolution of > SHM refclock is limited to 1us, but that is another matter. > > In any case, the relationship of the system time to UTC and calibration of > stratum-1 server is an interesting problem. > > Karel Sandler Karel: How much is that GPS170PCI card? ___ 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
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. In order to be considered OK, we can't accept more than 50 ppb frequency offset. Handling this with up to 50 ms sawtooth variation (with periods up to several hours) in the one-way latency means that the vendor require sampling periods of up to 10+ hours, with multiple packets/second and then keeping a single packet at the end. That seems excessive. Do they set the frequency directly just from the last two samples? With PLL or similar, increasing the time constant accordingly might be a better approach. They keep the best sample from each of four periods, each period can be up to 10+ hours, then they do a second set of validity checks on the four surviving samples, before the final curve fitting to determine the actual drift rate. Terje -- - "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] Any chance of getting bugs 2164 and 1577 moving?
On 2012-03-23, Karel Sandler wrote: > On Fri, 23 Mar 2012, unruh wrote: > >> On 2012-03-22, Karel Sandler wrote: >>> On Thu, 22 Mar 2012, unruh wrote: >>> > In addition, it should be noted that in the case of serial PPS > the system time may lag behind UTC by tens of microseconds. tens of microseconds? Where does this come from? The interrupt processing time is not that long. >>> >>> I took these numbers from >>> http://www.cesnet.cz/doc/techzpravy/2007/ntp-server/. >>> Measurement of these delays is described in some articles listed in >>> references. >> >> Well, if correct that is hugely different from the latency on a parallel >> port. >> As I said I tested that. I wrote a driver which grabbed a timestamp, >> wrote to one of the output pins of a parallel port which was connected >> to the ACK pin on that parallel port. The interupt service routine which >> serviced the ACK interrupt immediately timestamped the interrupt. (ie >> the second instruction grabbed a timestamp. The first checked the ack >> pin to make sure this was a parallel interrupt) the delay between those >> two timestamps (usec precision) was 1-2us. Far from 8-50 us that they >> claim. >> >> I have not done the equivalent (Parallel port pin to serial port DCD >> interrupt) but I would be very surprized if it is that much worse. >> >> Note that the fluctuations are not that much worse. I have run a GPS via >> the serial port DCD and find offsets that fluctuate around the 1us >> standard deviation (using the nanosecond timer in Linux) with occasional >> excursions. While this does not measure the latency, it does measure the >> fluctuations in the latency and then are less than 1us. (Note that in >> the reference in the paper you quote, the fluctuations in the latency >> are much large than this-- normally about 2us, but sizable tails out to >> 30us.) >> >> I suspect that the methodology is bad-- ie, is most of the delay in >> switching on the RTS pin rather than in the interupt latency? > > I did not participate in these measurements and I can not comment on their > methodology. High delays correspond to measurements at high load, but it > seems that the lower limit is not negligible. Especially compared to > offset fluctuations, which can be an order of magnitude smaller. > > On my site I can watch more than half a dozen stratum-1 servers with > delays below 2ms. All show each other more or less stable differences that > probably can not be entirely attributed to asymmetries of the network. > > Our stratum-1 server uses GPS170PCI card with its own clock and a number > of useable outputs. One option is to use the PPS output (accuracy garanted > better than 250ns) connected to the DCD pin of the serial port. > Fluctuations of the offset were below 2us with occasional blips. Now I use > another option. Blips are gone, offsets fluctuate just below 1us standard And what is that "another option". How do uyou know it shifted the offset? What did you use as the standard. Note that as I said, measuring the offset on a parallel port I got at most 2us. I would be surprised if the serial port were that much worse. > deviatiation and, to my surprise, new option shifted the offset by 32us. > System driven by PPS had time delay. Unfortunately the resolution of > SHM refclock is limited to 1us, but that is another matter. > > In any case, the relationship of the system time to UTC and calibration of > stratum-1 server is an interesting problem. Agreed. And measurements, not theory , are needed. > > Karel Sandler ___ 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 2012-03-23, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > unruh wrote: >> No I would not. That is not what ntpd does. It really does throw away 7 >> of the samples and never uses them. The whole question is what is the >> best statistic to use. I do not believe that the "shortest roundtrip >> time" is that best statistic. If you could convince me it is, I would be >> more than happy to have ntp use it. > > In _some_ scenarios, keeping only the minimum rttsample is indeed the > best approach: > > I have been working for a couple of years on the new cell phone network > in Norway (we've replaced everything, including every single base station!). > > Even if GSM and related cell phone standards does not require the same > absolute timing precision as some of those used in the US, there is > still a requirement for a _very_ stable frequency base in order to do > transparent handover from one base station to the next, and the relative > offset determines the maximum doppler that can be handled. > > In order to be considered OK, we can't accept more than 50 ppb frequency > offset. > > Handling this with up to 50 ms sawtooth variation (with periods up to > several hours) in the one-way latency means that the vendor require > sampling periods of up to 10+ hours, with multiple packets/second and > then keeping a single packet at the end. > > Of course, the main requirement is to start with a _very_ stable time > base, in this case double-oven OCXOs with daily drift rates in the > fractional ppb range! >> >> IF the roundtrip times were to vary by factors of 2 from one instance to >> the next, I might be persuaded that it was the best statistic. But it >> does not in almost all cases where ntpd is used. It varies by a few >> percent ( with maybe an occasional blip with larger delays.) I have huge >> reams of data to support my statement. > > So do I, and I would have agreed with you a month ago, but I have gotten > actual measurement data from the base station vendor showing really > _huge_ packet-to-packet jitter values. In your case, I might well be persuaded that throwing away data is the best way of handling the errors. But it would still leave me uncomfortable. Data is precious. It is unrepeatable (in the case of timing). My prejudice would be that surely there is some way of extracting more from the data than simply that one least delay packet. For example, for ntpd if the delay is in either one path or the other, then instead of using the mean as the best estimate of the remote clock time, one could assume that the increase in travel time is in only one path, and by looking at the offset get a pretty good idea of which one it is in (see the offset vs travel plots in Mill's book, where you can get these wings in which the change in travel time is due to only one of the paths.) That is infomation you could use to better the time estimates. It of course makes for a much more complex clock filter than the simple "throw away everything but the shortest roundtrip". Recall that with 8 data points, you reduce the statistical error by about a factor of 3 over 1. If the variation in roundtrip is less than about 3, then the advantage of the greater number of points can outweigh the increased noise due to round trip variation. > > Terje > - > "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] Any chance of getting bugs 2164 and 1577 moving?
On 3/22/2012 5:54 PM, David Lord wrote: unruh wrote: On 2012-03-22, David J Taylor wrote: "unruh" wrote in message news:xLHar.38386$iq1.34...@newsfe18.iad... [] Measure what? Why do you think that ntp reporting the offset with an extra three decimal points would allow you to measure anything? What in your mind would you expect to see in that output that would allow you to "measure" something that would tell you that the -19 was wrong? Remember ntpd DID measure something in order to determine that -19. What do you think the extra decimal places would give you? Most likely I would be looking at a histogram of the reported offsets, and see whether it was gaussian, flat, or whatever, and how wide. I might learn something from that. No. Not if it is just noise. Others have reported precisions better than -19, and also have a need for greater reporting precision. That is a valid issue. I have servers currently with precision= of 18, 19, 20 but not scanned back in history more than today. The value varies, with temperature and system load which causes local temperature variations. The precision values vary and are just way points. With precision 20. I don't really need an extra decimal place but in a previous life was used to throwing away two results from five or more if from a greater number of samples. My standard pc hardware can't do any better. David There seems to be an impression out there that I'm trying to show something is wrong - I'm not. I suggested an enhancement so that the precision of ntpq matched that of the loopstats. That's all. precision is not accuracy. In science we teach students not to report unwarranted precision-- the precision should reflect the accuracy of the measurements. We keep getting measurements to the mm and reported precision to angstoms because that was what the calculator spit out. I am not averse to reporting with a precion maybe up to a factor of 10 better than the accuracy, but any more is just silly and misleading (as you are demonstrating in believing that a greater precision would convey some extra information. David I remember this one from thirty or more years ago: "Measure with micrometer, mark with chalk, cut with axe!" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
On Fri, 23 Mar 2012, unruh wrote: On 2012-03-23, Karel Sandler wrote: On Fri, 23 Mar 2012, unruh wrote: On 2012-03-22, Karel Sandler wrote: On Thu, 22 Mar 2012, unruh wrote: In addition, it should be noted that in the case of serial PPS the system time may lag behind UTC by tens of microseconds. tens of microseconds? Where does this come from? The interrupt processing time is not that long. I took these numbers from http://www.cesnet.cz/doc/techzpravy/2007/ntp-server/. Measurement of these delays is described in some articles listed in references. Well, if correct that is hugely different from the latency on a parallel port. As I said I tested that. I wrote a driver which grabbed a timestamp, wrote to one of the output pins of a parallel port which was connected to the ACK pin on that parallel port. The interupt service routine which serviced the ACK interrupt immediately timestamped the interrupt. (ie the second instruction grabbed a timestamp. The first checked the ack pin to make sure this was a parallel interrupt) the delay between those two timestamps (usec precision) was 1-2us. Far from 8-50 us that they claim. I have not done the equivalent (Parallel port pin to serial port DCD interrupt) but I would be very surprized if it is that much worse. Note that the fluctuations are not that much worse. I have run a GPS via the serial port DCD and find offsets that fluctuate around the 1us standard deviation (using the nanosecond timer in Linux) with occasional excursions. While this does not measure the latency, it does measure the fluctuations in the latency and then are less than 1us. (Note that in the reference in the paper you quote, the fluctuations in the latency are much large than this-- normally about 2us, but sizable tails out to 30us.) I suspect that the methodology is bad-- ie, is most of the delay in switching on the RTS pin rather than in the interupt latency? I did not participate in these measurements and I can not comment on their methodology. High delays correspond to measurements at high load, but it seems that the lower limit is not negligible. Especially compared to offset fluctuations, which can be an order of magnitude smaller. On my site I can watch more than half a dozen stratum-1 servers with delays below 2ms. All show each other more or less stable differences that probably can not be entirely attributed to asymmetries of the network. Our stratum-1 server uses GPS170PCI card with its own clock and a number of useable outputs. One option is to use the PPS output (accuracy garanted better than 250ns) connected to the DCD pin of the serial port. Fluctuations of the offset were below 2us with occasional blips. Now I use another option. Blips are gone, offsets fluctuate just below 1us standard And what is that "another option". How do uyou know it shifted the offset? What did you use as the standard. Note that as I said, measuring the offset on a parallel port I got at most 2us. I would be surprised if the serial port were that much worse. deviatiation and, to my surprise, new option shifted the offset by 32us. System driven by PPS had time delay. Unfortunately the resolution of SHM refclock is limited to 1us, but that is another matter. In any case, the relationship of the system time to UTC and calibration of stratum-1 server is an interesting problem. Agreed. And measurements, not theory , are needed. Now I use SHM refclock. Any difference between GPS clock and system time is read and passed using Meinberg daemon. The value of the shift was verified in two ways. Three nearest stratum-1 servers have jitter below 30us. One day floating average of their offsets now lies between zero and 3us. Move by 30us was quite distinct. Moreover, the card enable the use of three refclocks simultaneously. Differences between PARSE, PPS and SHM refclocks were stable and clearly visible. If time permits, I'll try the parallel port. Karel Sandler ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
On Fri, 23 Mar 2012, Alby VA wrote: How much is that GPS170PCI card? I do not know the current price. I'm guessing well over 1000 euros. Karel Sandler ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] YEA! My Sure Electronics GPS just arrived.
Hi all, YEA! My Sure Electronics GPS just arrived. I ordered on 03/05/12 and it arrived on 03/23/12, so it took 18 days. My configuration is: GPS USB port --> PC 2nd USB port - for power only GPS serial port --> Trendnet TU-S9 (Prolific based) serial - USB adapter --> PC 1st USB port (same as I had the BU-353 on) GPS antenna port --> included antenna Using Terje's NMEA-MTK program, I sent the commands to the unit to engage WAAS, send only GPGGA, and change the baud rate to 57600 as follows. You can get help from the program as follows: nmea-mtk /? The board was already at 9600 baud transmitting several sentences. I sent this command to enable WAAS and set for GPGGA sentences only (the default action): nmea-mtk -p \\.\COM5 I verified that it's working with SirfDemo. This is OK as long as I don't send any commands from SirfDemo and use it for display only. I set the SirfDemo data source for COM5 at 9600 baud, connected to the GPS, and observed the NMEA data sentences. Then I disconnected SirfDemo. I sent this to change baud rate to 57600: nmea-mtk -p \\.\COM5 -c PMTK251,57600 I verified that it's working with this command. Now I have to send the new baud rate in the command so nmea-mtk will read the port and match the baud rate of the GPS. This reads out NMEA data for 10 seconds. nmea-mtk -p \\.\COM5 -b 57600 -t 10 I also verified that it's working with SirfDemo after settings its baud rate for the data source to 57600. At the moment, I'm using NMEA only through the serial port of the GPS. I haven't tried NMEA through the GPS's USB port, but I assume it would be similar, since, either way, I'm going though a serial - USB converter. The Sure board uses a CP2102 usb to uart chipset, whatever that is, but I never loaded the driver for it. Since my external TU-s9 adapter uses the same Prolific driver that the BU-353 GPS did, I'm just using that. I am currently testing in Windows. Preliminary graphs indicate I'm getting a variance of + / - 25 ms from my PC's clock to the GPS polling it every 8 sec. That's a bit disappointing, since I was getting + / - 10 ms from the BU-353 going through it's internal serial - USB converter. I'm going to monitor it for about a week and see how stable it is relative to the internet servers. Also, I'm hoping it doesn't have periodic heart attacks like the BU-353 did. I am testing indoors, as before. I have a question for someone with experience with the board. If I unplug the board, will it retain it's programming, or will it lose it? If it retains it, how long will it keep the data? If it loses it, how can I prevent that? 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] Any chance of getting bugs 2164 and 1577 moving?
On 2012-03-23, Karel Sandler wrote: > On Fri, 23 Mar 2012, unruh wrote: > >> On 2012-03-23, Karel Sandler wrote: >>> On Fri, 23 Mar 2012, unruh wrote: >>> On 2012-03-22, Karel Sandler wrote: > On Thu, 22 Mar 2012, unruh wrote: > >>> In addition, it should be noted that in the case of serial PPS >>> the system time may lag behind UTC by tens of microseconds. >> >> tens of microseconds? Where does this come from? The interrupt >> processing time is not that long. > > I took these numbers from > http://www.cesnet.cz/doc/techzpravy/2007/ntp-server/. > Measurement of these delays is described in some articles listed in > references. Well, if correct that is hugely different from the latency on a parallel port. As I said I tested that. I wrote a driver which grabbed a timestamp, wrote to one of the output pins of a parallel port which was connected to the ACK pin on that parallel port. The interupt service routine which serviced the ACK interrupt immediately timestamped the interrupt. (ie the second instruction grabbed a timestamp. The first checked the ack pin to make sure this was a parallel interrupt) the delay between those two timestamps (usec precision) was 1-2us. Far from 8-50 us that they claim. I have not done the equivalent (Parallel port pin to serial port DCD interrupt) but I would be very surprized if it is that much worse. Note that the fluctuations are not that much worse. I have run a GPS via the serial port DCD and find offsets that fluctuate around the 1us standard deviation (using the nanosecond timer in Linux) with occasional excursions. While this does not measure the latency, it does measure the fluctuations in the latency and then are less than 1us. (Note that in the reference in the paper you quote, the fluctuations in the latency are much large than this-- normally about 2us, but sizable tails out to 30us.) I suspect that the methodology is bad-- ie, is most of the delay in switching on the RTS pin rather than in the interupt latency? >>> >>> I did not participate in these measurements and I can not comment on their >>> methodology. High delays correspond to measurements at high load, but it >>> seems that the lower limit is not negligible. Especially compared to >>> offset fluctuations, which can be an order of magnitude smaller. >>> >>> On my site I can watch more than half a dozen stratum-1 servers with >>> delays below 2ms. All show each other more or less stable differences that >>> probably can not be entirely attributed to asymmetries of the network. >>> >>> Our stratum-1 server uses GPS170PCI card with its own clock and a number >>> of useable outputs. One option is to use the PPS output (accuracy garanted >>> better than 250ns) connected to the DCD pin of the serial port. >>> Fluctuations of the offset were below 2us with occasional blips. Now I use >>> another option. Blips are gone, offsets fluctuate just below 1us standard >> >> And what is that "another option". How do uyou know it shifted the >> offset? What did you use as the standard. Note that as I said, measuring >> the offset on a parallel port I got at most 2us. >> >> I would be surprised if the serial port were that much worse. >> >> >>> deviatiation and, to my surprise, new option shifted the offset by 32us. >>> System driven by PPS had time delay. Unfortunately the resolution of >>> SHM refclock is limited to 1us, but that is another matter. >>> >>> In any case, the relationship of the system time to UTC and calibration of >>> stratum-1 server is an interesting problem. >> >> Agreed. And measurements, not theory , are needed. > > Now I use SHM refclock. Any difference between GPS clock and system time > is read and passed using Meinberg daemon. But how is the time gotten into the shm. You still need some daemon to wait for the pulse from the GPS timestamp it and then install that timestamp into the shared memory segment. That is not necessarily either worse of better than any other method. In all cases the crucial issue is how fast after the pulse from the GPS hits the computer can that pulse be timestamped with the computer's time. > > The value of the shift was verified in two ways. Three nearest stratum-1 > servers have jitter below 30us. One day floating average of their offsets > now lies between zero and 3us. Move by 30us was quite distinct. Moreover, > the card enable the use of three refclocks simultaneously. Differences > between PARSE, PPS and SHM refclocks were stable and clearly visible. Not sure what you mean. If those were serviced by different daemons, then, an interupt shuts off other interrupts, and each daemon would have to wait for the previous one to finish before starting up itself. Ie, what you could be seeing is simply that the new one is first in the chain and is thus grabbing the interrupt first.
[ntp:questions] UK ANN: NOTIFICATION OF GPS JAMMING EXERCISES SALISBURY PLAIN, WILTSHIRE, 7TH MAY 2012
NOTIFICATION OF GPS JAMMING EXERCISES SALISBURY PLAIN, WILTSHIRE, 7TH MAY 2012 Dates: Between the 7th of May and the 11th of May 2012 (Inclusive). Times: : 0700 - 2000 GMT. Location of MULTIPLE jammers: Land based within 5km of N51° 12', W001° 58.5'. Frequency: A 24 MHz band centred around 1575.42MHz (GPS L1) Total Power: Up to 10 Watts EIRP. It is stressed that, as in previous exercises, Safety of Life operations will at all times take precedence over exercise activities. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
Hi all, YEA! My Sure Electronics GPS just arrived. I ordered on 03/05/12 and it arrived on 03/23/12, so it took 18 days. [] I have a question for someone with experience with the board. If I unplug the board, will it retain it's programming, or will it lose it? If it retains it, how long will it keep the data? If it loses it, how can I prevent that? Sincerely, Ron Good news, Ron. I did see one report here that the board /may/ not retain its programming, that's why I've made my NTP configuration work with the default settings. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
Sorry, just realised what you meant by "programming"-- change in baud rate, sentence delivery, etc. I use the default ( and use the PPS from the Sure for the actual timing via either the serial port (with pps_ldisc on linux) or with the parallel port and a special program I wrote to handle the parallel interrupt (mostly stolen from Linux Device Drivers by Rubini and Corbet) So I have no idea whether it retains the new baud rate, etc or for how long. On 2012-03-23, unruh wrote: > On 2012-03-23, Ron Frazier (NTP) wrote: >> Hi all, >> >> YEA! My Sure Electronics GPS just arrived. I ordered on 03/05/12 and >> it arrived on 03/23/12, so it took 18 days. > > Yes, you pay for the cheapness by slowness. Note that you want to keep > eyes on the antenna. If you find your sure blue light stop flashing you > probably have a defective antenna. > >> >> My configuration is: >> >> GPS USB port --> PC 2nd USB port - for power only >> GPS serial port --> Trendnet TU-S9 (Prolific based) serial - USB adapter >> --> PC 1st USB port (same as I had the BU-353 on) >> GPS antenna port --> included antenna >> >> Using Terje's NMEA-MTK program, I sent the commands to the unit to >> engage WAAS, send only GPGGA, and change the baud rate to 57600 as follows. >> >> You can get help from the program as follows: >> >> nmea-mtk /? >> >> The board was already at 9600 baud transmitting several sentences. >> >> I sent this command to enable WAAS and set for GPGGA sentences only (the >> default action): >> >> nmea-mtk -p \\.\COM5 >> >> I verified that it's working with SirfDemo. This is OK as long as I >> don't send any commands from SirfDemo and use it for display only. I >> set the SirfDemo data source for COM5 at 9600 baud, connected to the >> GPS, and observed the NMEA data sentences. Then I disconnected SirfDemo. >> >> I sent this to change baud rate to 57600: >> >> nmea-mtk -p \\.\COM5 -c PMTK251,57600 >> >> I verified that it's working with this command. Now I have to send the >> new baud rate in the command so nmea-mtk will read the port and match >> the baud rate of the GPS. This reads out NMEA data for 10 seconds. >> >> nmea-mtk -p \\.\COM5 -b 57600 -t 10 >> >> I also verified that it's working with SirfDemo after settings its baud >> rate for the data source to 57600. >> >> At the moment, I'm using NMEA only through the serial port of the GPS. >> I haven't tried NMEA through the GPS's USB port, but I assume it would >> be similar, since, either way, I'm going though a serial - USB > > Why would you do that when the Sure board already sends USB nmea data on > the usb port. > >> converter. The Sure board uses a CP2102 usb to uart chipset, whatever >> that is, but I never loaded the driver for it. Since my external TU-s9 >> adapter uses the same Prolific driver that the BU-353 GPS did, I'm just >> using that. I am currently testing in Windows. >> >> Preliminary graphs indicate I'm getting a variance of + / - 25 ms from >> my PC's clock to the GPS polling it every 8 sec. That's a bit >> disappointing, since I was getting + / - 10 ms from the BU-353 going >> through it's internal serial - USB converter. I'm going to monitor it >> for about a week and see how stable it is relative to the internet >> servers. Also, I'm hoping it doesn't have periodic heart attacks like >> the BU-353 did. I am testing indoors, as before. >> >> I have a question for someone with experience with the board. If I >> unplug the board, will it retain it's programming, or will it lose it? >> If it retains it, how long will it keep the data? If it loses it, how >> can I prevent that? > > It keeps its programming forever. It keeps its current solution for I > think about an hour using the onboard capacitor. But it does not take > very long to aquire a new solution and start delivering the time to far > higher accuracy than you need (something like a couple of minutes) > . > > > > >> >> Sincerely, >> >> Ron >> >> ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
On 2012-03-23, Ron Frazier (NTP) wrote: > Hi all, > > YEA! My Sure Electronics GPS just arrived. I ordered on 03/05/12 and > it arrived on 03/23/12, so it took 18 days. Yes, you pay for the cheapness by slowness. Note that you want to keep eyes on the antenna. If you find your sure blue light stop flashing you probably have a defective antenna. > > My configuration is: > > GPS USB port --> PC 2nd USB port - for power only > GPS serial port --> Trendnet TU-S9 (Prolific based) serial - USB adapter > --> PC 1st USB port (same as I had the BU-353 on) > GPS antenna port --> included antenna > > Using Terje's NMEA-MTK program, I sent the commands to the unit to > engage WAAS, send only GPGGA, and change the baud rate to 57600 as follows. > > You can get help from the program as follows: > > nmea-mtk /? > > The board was already at 9600 baud transmitting several sentences. > > I sent this command to enable WAAS and set for GPGGA sentences only (the > default action): > > nmea-mtk -p \\.\COM5 > > I verified that it's working with SirfDemo. This is OK as long as I > don't send any commands from SirfDemo and use it for display only. I > set the SirfDemo data source for COM5 at 9600 baud, connected to the > GPS, and observed the NMEA data sentences. Then I disconnected SirfDemo. > > I sent this to change baud rate to 57600: > > nmea-mtk -p \\.\COM5 -c PMTK251,57600 > > I verified that it's working with this command. Now I have to send the > new baud rate in the command so nmea-mtk will read the port and match > the baud rate of the GPS. This reads out NMEA data for 10 seconds. > > nmea-mtk -p \\.\COM5 -b 57600 -t 10 > > I also verified that it's working with SirfDemo after settings its baud > rate for the data source to 57600. > > At the moment, I'm using NMEA only through the serial port of the GPS. > I haven't tried NMEA through the GPS's USB port, but I assume it would > be similar, since, either way, I'm going though a serial - USB Why would you do that when the Sure board already sends USB nmea data on the usb port. > converter. The Sure board uses a CP2102 usb to uart chipset, whatever > that is, but I never loaded the driver for it. Since my external TU-s9 > adapter uses the same Prolific driver that the BU-353 GPS did, I'm just > using that. I am currently testing in Windows. > > Preliminary graphs indicate I'm getting a variance of + / - 25 ms from > my PC's clock to the GPS polling it every 8 sec. That's a bit > disappointing, since I was getting + / - 10 ms from the BU-353 going > through it's internal serial - USB converter. I'm going to monitor it > for about a week and see how stable it is relative to the internet > servers. Also, I'm hoping it doesn't have periodic heart attacks like > the BU-353 did. I am testing indoors, as before. > > I have a question for someone with experience with the board. If I > unplug the board, will it retain it's programming, or will it lose it? > If it retains it, how long will it keep the data? If it loses it, how > can I prevent that? It keeps its programming forever. It keeps its current solution for I think about an hour using the onboard capacitor. But it does not take very long to aquire a new solution and start delivering the time to far higher accuracy than you need (something like a couple of minutes) . > > Sincerely, > > Ron > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] peerstat update frequency
How often should an individual peer write an entry to the peerstat log? Is it supposed to occur every time the peer is polled or only once every certain number of polls? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peerstat update frequency
On Sat, Mar 24, 2012 at 00:01, A C wrote: > How often should an individual peer write an entry to the peerstat log? Is > it supposed to occur every time the peer is polled or only once every > certain number of polls? I presume every response is logged, which may be slightly less often than every poll interval in case of lost traffic. Are you seeing something else? Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peerstat update frequency
On 3/23/2012 17:07, Dave Hart wrote: On Sat, Mar 24, 2012 at 00:01, A C wrote: How often should an individual peer write an entry to the peerstat log? Is it supposed to occur every time the peer is polled or only once every certain number of polls? I presume every response is logged, which may be slightly less often than every poll interval in case of lost traffic. Are you seeing something else? Yeah, in my case the peerstats updates every poll for the refclocks but on Internet servers it's updating only once every 4-8 polls. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peerstat update frequency
On Sat, Mar 24, 2012 at 00:13, A C wrote: > On 3/23/2012 17:07, Dave Hart wrote: >> I presume every response is logged, which may be slightly less often >> than every poll interval in case of lost traffic. Are you seeing >> something else? > > Yeah, in my case the peerstats updates every poll for the refclocks but on > Internet servers it's updating only once every 4-8 polls. A quick look at ntp_proto.c clock_filter() confirms it's similar to loopstats -- a new entry is logged only when the result changes. If the most recent response is not the minimum delay of the last 8 polls, the results are unchanged. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
On Fri, 23 Mar 2012, unruh wrote: On 2012-03-23, Karel Sandler wrote: On Fri, 23 Mar 2012, unruh wrote: On 2012-03-23, Karel Sandler wrote: On Fri, 23 Mar 2012, unruh wrote: On 2012-03-22, Karel Sandler wrote: On Thu, 22 Mar 2012, unruh wrote: In addition, it should be noted that in the case of serial PPS the system time may lag behind UTC by tens of microseconds. tens of microseconds? Where does this come from? The interrupt processing time is not that long. I took these numbers from http://www.cesnet.cz/doc/techzpravy/2007/ntp-server/. Measurement of these delays is described in some articles listed in references. Well, if correct that is hugely different from the latency on a parallel port. As I said I tested that. I wrote a driver which grabbed a timestamp, wrote to one of the output pins of a parallel port which was connected to the ACK pin on that parallel port. The interupt service routine which serviced the ACK interrupt immediately timestamped the interrupt. (ie the second instruction grabbed a timestamp. The first checked the ack pin to make sure this was a parallel interrupt) the delay between those two timestamps (usec precision) was 1-2us. Far from 8-50 us that they claim. I have not done the equivalent (Parallel port pin to serial port DCD interrupt) but I would be very surprized if it is that much worse. Note that the fluctuations are not that much worse. I have run a GPS via the serial port DCD and find offsets that fluctuate around the 1us standard deviation (using the nanosecond timer in Linux) with occasional excursions. While this does not measure the latency, it does measure the fluctuations in the latency and then are less than 1us. (Note that in the reference in the paper you quote, the fluctuations in the latency are much large than this-- normally about 2us, but sizable tails out to 30us.) I suspect that the methodology is bad-- ie, is most of the delay in switching on the RTS pin rather than in the interupt latency? I did not participate in these measurements and I can not comment on their methodology. High delays correspond to measurements at high load, but it seems that the lower limit is not negligible. Especially compared to offset fluctuations, which can be an order of magnitude smaller. On my site I can watch more than half a dozen stratum-1 servers with delays below 2ms. All show each other more or less stable differences that probably can not be entirely attributed to asymmetries of the network. Our stratum-1 server uses GPS170PCI card with its own clock and a number of useable outputs. One option is to use the PPS output (accuracy garanted better than 250ns) connected to the DCD pin of the serial port. Fluctuations of the offset were below 2us with occasional blips. Now I use another option. Blips are gone, offsets fluctuate just below 1us standard And what is that "another option". How do uyou know it shifted the offset? What did you use as the standard. Note that as I said, measuring the offset on a parallel port I got at most 2us. I would be surprised if the serial port were that much worse. deviatiation and, to my surprise, new option shifted the offset by 32us. System driven by PPS had time delay. Unfortunately the resolution of SHM refclock is limited to 1us, but that is another matter. In any case, the relationship of the system time to UTC and calibration of stratum-1 server is an interesting problem. Agreed. And measurements, not theory , are needed. Now I use SHM refclock. Any difference between GPS clock and system time is read and passed using Meinberg daemon. But how is the time gotten into the shm. You still need some daemon to wait for the pulse from the GPS timestamp it and then install that timestamp into the shared memory segment. That is not necessarily either worse of better than any other method. In all cases the crucial issue is how fast after the pulse from the GPS hits the computer can that pulse be timestamped with the computer's time. GPS card has TCXO and its own clock controlled by GPS. The card can provide an accurate time regardless of the server that supplies the power. Any direct communication with the hosting server uses PCI bus and kernel module. I'm afraid, but I can not provide depth information. I am not a specialist in these matters. The value of the shift was verified in two ways. Three nearest stratum-1 servers have jitter below 30us. One day floating average of their offsets now lies between zero and 3us. Move by 30us was quite distinct. Moreover, the card enable the use of three refclocks simultaneously. Differences between PARSE, PPS and SHM refclocks were stable and clearly visible. Not sure what you mean. If those were serviced by different daemons, then, an interupt shuts off other interrupts, and each daemon would have to wait for the previous one to finish before starting up itself. Ie, what you could be seeing is simply that the new one is first in the chain and is thus g
Re: [ntp:questions] peerstat update frequency
On 3/23/2012 17:25, Dave Hart wrote: On Sat, Mar 24, 2012 at 00:13, A C wrote: On 3/23/2012 17:07, Dave Hart wrote: I presume every response is logged, which may be slightly less often than every poll interval in case of lost traffic. Are you seeing something else? Yeah, in my case the peerstats updates every poll for the refclocks but on Internet servers it's updating only once every 4-8 polls. A quick look at ntp_proto.c clock_filter() confirms it's similar to loopstats -- a new entry is logged only when the result changes. If the most recent response is not the minimum delay of the last 8 polls, the results are unchanged. Cheers, Dave Hart The thing is that according to ntpq, the data has changed (offset, jitter and delay) after a poll. But that isn't reflected in the peerstats file if peerstats is looking for changes. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
On Fri, Mar 23, 2012 at 4:39 PM, unruh wrote: > Sorry, just realised what you meant by "programming"-- change in baud > rate, sentence delivery, etc. I use the default ( and use the PPS from > the Sure for the actual timing via either the serial port (with > pps_ldisc on linux) or with the parallel port and a special program I > wrote to handle the parallel interrupt The Linux PPS code now handles parallel port. You don't have to write your own. Also I think the PPS API was a way to add other physical devices so there is no need for an ad-hoc solution. Maybe you need to upgrade to latest kernel to get this. Oh, if the Sure GPS does loose the programming (It would be simple to test) you can fit it by placing a battery across the power supply. I used a coin ell holder salvaged from a dead PC for one GPS I have and AA cells work too. But I bet the sure is new enough to use eprom or flash. Chris Albertson Redondo Beach, California ___ 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/23/2012 7:31 PM, unruh wrote: On 2012-03-23, Ron Frazier (NTP) wrote: Hi all, YEA! My Sure Electronics GPS just arrived. I ordered on 03/05/12 and it arrived on 03/23/12, so it took 18 days. Yes, you pay for the cheapness by slowness. Note that you want to keep eyes on the antenna. If you find your sure blue light stop flashing you probably have a defective antenna. My configuration is: GPS USB port --> PC 2nd USB port - for power only GPS serial port --> Trendnet TU-S9 (Prolific based) serial - USB adapter --> PC 1st USB port (same as I had the BU-353 on) GPS antenna port --> included antenna Using Terje's NMEA-MTK program, I sent the commands to the unit to engage WAAS, send only GPGGA, and change the baud rate to 57600 as follows. You can get help from the program as follows: nmea-mtk /? The board was already at 9600 baud transmitting several sentences. I sent this command to enable WAAS and set for GPGGA sentences only (the default action): nmea-mtk -p \\.\COM5 I verified that it's working with SirfDemo. This is OK as long as I don't send any commands from SirfDemo and use it for display only. I set the SirfDemo data source for COM5 at 9600 baud, connected to the GPS, and observed the NMEA data sentences. Then I disconnected SirfDemo. I sent this to change baud rate to 57600: nmea-mtk -p \\.\COM5 -c PMTK251,57600 I verified that it's working with this command. Now I have to send the new baud rate in the command so nmea-mtk will read the port and match the baud rate of the GPS. This reads out NMEA data for 10 seconds. nmea-mtk -p \\.\COM5 -b 57600 -t 10 I also verified that it's working with SirfDemo after settings its baud rate for the data source to 57600. At the moment, I'm using NMEA only through the serial port of the GPS. I haven't tried NMEA through the GPS's USB port, but I assume it would be similar, since, either way, I'm going though a serial - USB Why would you do that when the Sure board already sends USB nmea data on the usb port. As far as I know, the only way I can get PPS into the PC is with the serial port through the DCD pin, which I have to wire up. So, I just decided to connect right up to the serial port. However, if that PPS signal is shipped through the board's USB interface, that would be great. Anyone know if that's the case? converter. The Sure board uses a CP2102 usb to uart chipset, whatever that is, but I never loaded the driver for it. Since my external TU-s9 adapter uses the same Prolific driver that the BU-353 GPS did, I'm just using that. I am currently testing in Windows. Preliminary graphs indicate I'm getting a variance of + / - 25 ms from my PC's clock to the GPS polling it every 8 sec. That's a bit disappointing, since I was getting + / - 10 ms from the BU-353 going through it's internal serial - USB converter. I'm going to monitor it for about a week and see how stable it is relative to the internet servers. Also, I'm hoping it doesn't have periodic heart attacks like the BU-353 did. I am testing indoors, as before. I have a question for someone with experience with the board. If I unplug the board, will it retain it's programming, or will it lose it? If it retains it, how long will it keep the data? If it loses it, how can I prevent that? It keeps its programming forever. It keeps its current solution for I think about an hour using the onboard capacitor. But it does not take very long to aquire a new solution and start delivering the time to far higher accuracy than you need (something like a couple of minutes) . Sincerely, Ron ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- (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 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 -- (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 2012-03-24, Chris Albertson wrote: > On Fri, Mar 23, 2012 at 4:39 PM, unruh wrote: >> Sorry, just realised what you meant by "programming"-- change in baud >> rate, sentence delivery, etc. I use the default ( and use the PPS from >> the Sure for the actual timing via either the serial port (with >> pps_ldisc on linux) or with the parallel port and a special program I >> wrote to handle the parallel interrupt > > The Linux PPS code now handles parallel port. You don't have to > write your own. Also I think the PPS API was a way to add other > physical devices so there is no need for an ad-hoc solution. Maybe > you need to upgrade to latest kernel to get this. I wrote it about 6 years ago. I know it and how it works. I do not know how the pps_parallel works. > > Oh, if the Sure GPS does loose the programming (It would be simple to > test) you can fit it by placing a battery across the power supply. I > used a coin ell holder salvaged from a dead PC for one GPS I have and > AA cells work too. But I bet the sure is new enough to use eprom or > flash. > > > Chris Albertson > Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peerstat update frequency
On 2012-03-24, A C wrote: > How often should an individual peer write an entry to the peerstat log? > Is it supposed to occur every time the peer is polled or only once > every certain number of polls? Every time it is polled. (ntpd writes to the file, the peer does not do so.) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ANN UK: MSF 60KHz interruption - Mon Mar 26 - Fri Apr 06
Folks, I have received notice that the MSF 60 KHz signal from Anthorn, Cumbria, UK will be off-air 08:00 UTC Mon 2012-Mar-26 to 20:00 2012-Apr-06. The service may be off-air continuously during the period, but will be restored overnight and at the weekend whenever possible. Cheers, David -- SatSignal software - quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peerstat update frequency
On 3/23/2012 20:48, unruh wrote: On 2012-03-24, A C wrote: How often should an individual peer write an entry to the peerstat log? Is it supposed to occur every time the peer is polled or only once every certain number of polls? Every time it is polled. (ntpd writes to the file, the peer does not do so.) Well that is precisely what is not happening. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] YEA! My Sure Electronics GPS just arrived.
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, 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. 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
