Re: [ntp:questions] First attempt GPSD/PPS -NTP time server
Hi there root wrote: No GPS NMEA should not do that. The length of the sentence is almost fixed length, so the timing on it should vary by perhaps a few msec, as you found, certainly not by seconds. It sounds like you have troubles. You could try using minicom ( assuming you are on Linux) to look at the output on the serial port. PPS is tied to DCD. So online is off 90 % of the time. With the following circuit you can configure the GPS receiver; Garmin Minicom MaleFemale 9P 25P RXD-RXD 23 TXD-TXD 32 GND-GND 57 +-DCD18 | *-DTR4 20 | +-DSR66 +-CTS75 | +-RTS84 SH--SH The GPS sentence should certainly be able to pull you into the second range very easily. Anyway use some serial port terminal program to read what the gps is sending and how often. (Remember at 4800Bd, it takes about 2 msec to send each character. My Garmin was sending to much data, sending a NMEA sentence once per second. So I put '$PGRMO,,4CRLF' in a file and send it to the Garmin. Now it's at six lines per second; GPRMC, GPGGA, GPGSA and three GPGSV lines (plus one PGRMT per minute). Regards, Rob -- When the Iron Curtain fell, all of the West rejoiced that the East would become just as free as the West. It was never supposed to be the other way around. (Rick Falkvinge) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] First attempt GPSD/PPS -NTP time server
Hi there Rob van der Putten wrote: Cut My Garmin was sending to much data, sending a NMEA sentence once per second. Sorry, once per two seconds. Cut Regards, Rob -- When the Iron Curtain fell, all of the West rejoiced that the East would become just as free as the West. It was never supposed to be the other way around. (Rick Falkvinge) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] First attempt GPSD/PPS -NTP time server
Hi there Steve Kostecke wrote: There is no benefit to sending all of those NMEA sentences. Select one and turn the rest off. For just time GPRMC will do. Regards, Rob -- When the Iron Curtain fell, all of the West rejoiced that the East would become just as free as the West. It was never supposed to be the other way around. (Rick Falkvinge) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] First attempt GPSD/PPS -NTP time server
On 2008-01-29, Rob van der Putten [EMAIL PROTECTED] wrote: My Garmin was sending to much data, sending a NMEA sentence once per second. So I put '$PGRMO,,4CRLF' in a file and send it to the Garmin. Now it's at six lines per second; GPRMC, GPGGA, GPGSA and three GPGSV lines (plus one PGRMT per minute). There is no benefit to sending all of those NMEA sentences. Select one and turn the rest off. -- Steve Kostecke [EMAIL PROTECTED] NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
David, Cite: Judah Levine of NIST, personal communication. A few little mistakes on my part proved him right. Dave [EMAIL PROTECTED] wrote: In comp.protocols.time.ntp you write: Hi Dave, We can argue about the Hurst parameter, which can't be truly random-walk as I have assumed, but the approximation is valid up to lag times of at least a week. However, as I have been cautioned, these plots are really sensitive to spectral lines due to nonuniform sampling. I was very careful to avoid such things. Do you have a cite for that? Have you seen Vit Klemes take on tree ring data: http://iahs.info/perugia/2007IAHSKlemesTreeRings.pdf It might appeal to your sense of humour. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Brian Utterback wrote: Unruh wrote: David L. Mills [EMAIL PROTECTED] writes: Unruh, It would seem self evident from the equations that minimizing the delay variance truly does minimize the offset variance. Further evidence of that is in the raw versus filtered offset graphs in the architecture briefings. If nothing else, the filter reduces the variance by some 10 dB. More to the point, emphasis added, the wedge scattergrams show just I guess then I am confused because my data does not support that. While the delay variance IS reduced, the offset variance is not. The correleation between dely and offset IS reduced by a factor of 10, but the clock variance is reduced not at all. Here are the results from one day gathered brom one clock (I had ntp not only print out the peer-offset peer-delay as it does in the record_peer_stats , but also the p_offset and p_del, the offset and delays calculated for each packet. I alsy throw out the outliers ( for some reason the system would all of a sudden have packets with were 4ms round trip, rather than 160usec. These popcorn spikes are clearly bad. The difference between the variance as calculated from the peer-offset values, and the p_offset values was I do not know your network configuration at all, so I am just guessing, but My guess is that you are talking about a client connected on the same subnet with one or more servers, right? Connected by ethernet? In that case, you are talking about a situation where the error introduced by factors that increase in correlation with the round trip time is minimal at best. When they do kick in, you see what looks like huge jumps and filter them. A 4ms increase is just what you would expect when ethernet timers kick in. Now imagine a RTT of 60-70ms. A 9ms delay from a collision introduces a 4ms change in the delay value and a 2ms change in the offset, but with a delay might not perturb the delay value enough to make it obviously an outlyer. I can imagine an RTT of 60-70ms. What I have difficulty imagining is using such a source to synch with. Maybe I'm just lucky but I can usually find servers with an RTT of 20ms or less, usually less! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Telenet nieuwsgroepen mededeling: nieuwsserver adres aanpassen/Attention: modification de l'adresse du serveur de newsgroup
Beste klant, Telenet heeft een migratie gedaan van haar nieuwsservers. Wat betekent dit concreet voor jou als gebruiker? Er verandert niets aan de service, maar om verder gebruik te maken van de Telenet nieuwsgroepen service moet je bij de instellingen van je nieuwslezer het adres van de nieuwsserver veranderen van news.telenet.be of newsbin.telenet.be in newsgroups.telenet.be. Verder dien je de authenticatie op deze nieuwsserver uit te schakelen. Met vriendelijke groeten, Het Telenet team -- Cher client, Telenet a effectue une migration de ses serveurs de newsgroup. Pour continuer a utiliser les newsgroups de Telenet, modifiez dans la configuration de lecteur de nouvelles l'adresse du serveur de newsgroup: newsgroups.telenet.be a la place de news.telenet.be ou newsbin.telenet.be. Ceci ne necessite pas que vous vous identifiez pour acceder a ce serveur de newsgroup. Cordialement, L'equipe Telenet ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
