Re: [ntp:questions] NTP architecture recommendation
Richard B. Gilbert wrote: > > I don't think that a 14 channel receiver would be useful! There simply > are not that many satellites! The last I knew, there were 27 NavStar > (GPS) satellites in orbit. Of these, about seven are usually above the > horizon at any one time. Totally wrong: Here in Norway (60N), I usually have 10+ regular sats visible at all times, with 12 quite often. In addition there are two or three possible transmitters of EGNOS (i.e Euro WAAS) corrections, so having more than 12 channels would have been good. In fact, my 76 CSx often have problems with EGNOS because it doesn't have any free channels which can be dedicated to this. Terje -- - <[EMAIL PROTECTED]> "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Client taking a long time to sync after clock changed
Hello all, We have a small isolated NTP subnet with two stratum 1 servers. As part of a test we reset the clock on one workstation backwards two minutes. ntpq immediately showed the offset (and claimed it was still synchronized to one of the servers) but it took about 14 minutes until it was suddenly corrected with one step. We're using ntp 4.1 built for win32. Here is the clients ntp.conf: -- disable auth tinker panic 0 server sn-a maxpoll 4 minpoll 4 burst server sn-b maxpoll 4 minpoll 4 burst -- I added the maxpoll and burst options in an attempt to get this time down. It was similar before I changed it. Does this seem normal? Is there some way I can reduce this time? Note, I realize this isn't a particularly valid test, hopefully no one is going around changing the system time (or has permission to do so) but it got written into the test procedures... Thanks ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Client taking a long time to sync after clock changed
Well, my original message hasn't made it through moderation yet, but I found a solution to my 'problem'. I used "tinker stepout" to decrease the required time between clock steps. By setting it very low (10 seconds) I can get the sync time down to a couple of minutes, which should be fine. I suspect this is one of those Bad Ideas, but it seems to be working for me. I also changed burst to iburst since it doesn't seem to have any effect other than increasing network traffic. The client re-syncs pretty quickly with iburst since the server goes unreachable then reachable after the clock change. One more question: is there a way to change the time it takes to declare a server unreachable? In other words, can I declare it unreachable after just a couple of missed polls instead of 8? These machines are all on a local network with not much traffic, so in reality if they miss more than one poll the server is probably really gone, or has stepped, or something. Thanks On 8/21/07, Merit Wilkinson <[EMAIL PROTECTED]> wrote: > Hello all, > We have a small isolated NTP subnet with two stratum 1 servers. As > part of a test we reset the clock on one workstation backwards two > minutes. ntpq immediately showed the offset (and claimed it was still > synchronized to one of the servers) but it took about 14 minutes until > it was suddenly corrected with one step. > We're using ntp 4.1 built for win32. Here is the clients ntp.conf: > -- > disable auth > tinker panic 0 > > server sn-a maxpoll 4 minpoll 4 burst > server sn-b maxpoll 4 minpoll 4 burst > -- > I added the maxpoll and burst options in an attempt to get this time > down. It was similar before I changed it. > > Does this seem normal? Is there some way I can reduce this time? > > Note, I realize this isn't a particularly valid test, hopefully no one > is going around changing the system time (or has permission to do so) > but it got written into the test procedures... > > Thanks > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Client taking a long time to sync after clockchanged
> Well, my original message hasn't made it through moderation yet, but I > found a solution to my 'problem'. I used "tinker stepout" to decrease > the required time between clock steps. By setting it very low (10 > seconds) I can get the sync time down to a couple of minutes, which > should be fine. I suspect this is one of those Bad Ideas, but it > seems to be working for me. You have to realize that NTP works on the premise of gradual changes. Once your computer time is synced, in theory there shouldn't be anything that would cause it jump by 2 minutes, so NTP would make sure the time change wasn't a problem on the network or NTP server side before bumping the client back in sync. If NTP started making drastic assumptions every time a server was not reachable or their time varied greatly from the local clock then the whole system would not work. It's kind of like the old saying "Measure twice, cut once..." > I also changed burst to iburst since it doesn't seem to have any > effect other than increasing network traffic. The client re-syncs > pretty quickly with iburst since the server goes unreachable then > reachable after the clock change. burst is used when the server is reachable. iburst is used when the server is unreachable (typically initial sync, or after you have lost contact for a while). http://www.ece.udel.edu/~mills/ntp/html/confopt.html > One more question: is there a way to change the time it takes to > declare a server unreachable? In other words, can I declare it > unreachable after just a couple of missed polls instead of 8? These > machines are all on a local network with not much traffic, so in > reality if they miss more than one poll the server is probably really > gone, or has stepped, or something. Well, you already have your minpoll set as low as it will go. Your computer's time shouldn't wander off *that* much while the server is unreachable and as long as the other sources are okay then NTP should be happy. P.S. Only 2 servers is not a good choice. Which one is right? Nobody knows... If you had 3 then you could determine that much better, typically the recommended is 4 though. So you might want to add a couple more, even if the other servers are a lower stratum that are having to be synced over the internet. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Peerstats and Rawstats Info
Hi Vivien, Can you post ur ntp.conf here? Thanks. Kevin Lam ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp.conf
Thank you very much. I still don't see any file generated. Here's my ntp.conf: driftfile "C:\Program Files\NTP\etc\ntp.drift" server 192.168.1.2 prefer minpoll 4 maxpoll 4 enable stats statistics clockstats peerstats loopstats rawstats sysstats statsdir "C:\Program Files\NTP\etc\" filegen clockstats file clockstats.txt type day enable filegen peerstats file peerstats.txt type day enable filegen loopstats file loopstats.txt type day enable filegen rawstats file rawstats.txt type day enable filegen sysstats file sysstats.txt type day enable In one of the post, Dennis mentioned to check if ntpd has write access to its statsdir. How do I check it? Thanks. Oh, and how long will it take to generate the files?? Maybe I just didn't wait long enough?? Thanks Kevin ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Peerstats and Rawstats Info
Hi Viven, How long did it take you to generate the files?? I'm working on the similar things as u. But I couldn't generate any files. Alright, Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp.conf
Aggie wrote: > Thank you very much. I still don't see any file generated. > > Here's my ntp.conf: > driftfile "C:\Program Files\NTP\etc\ntp.drift" > > server 192.168.1.2 prefer minpoll 4 maxpoll 4 > > enable stats > statistics clockstats peerstats loopstats rawstats sysstats > statsdir "C:\Program Files\NTP\etc\" > > filegen clockstats file clockstats.txt type day enable > filegen peerstats file peerstats.txt type day enable > filegen loopstats file loopstats.txt type day enable > filegen rawstats file rawstats.txt type day enable > filegen sysstats file sysstats.txt type day enable > > In one of the post, Dennis mentioned to check if ntpd has write access > to its statsdir. How do I check it? Thanks. > > Oh, and how long will it take to generate the files?? Maybe I just > didn't wait long enough?? Thanks > > Kevin > On Windows XP right click on the statsdir (C:\Program Files\NTP\etc\) and select "Properties". Under the "General" tab, there are a couple of check boxes next to "Attributes:", one that says "Read-only" and one that says "Hidden". Make sure the "Read-only" one is unchecked. According to the documentation, sysstats is updated hourly, loopstats is updated every time the local clock is updated, peerstats is updated I'm assuming when NTP's peer is polled (documentation is a little vague), and rawstats is updated when an NTP message is received from a peer or clock driver. An hour or two is probably a sufficient time for stats to be generated. You won't generate any clockstats though, unless you are using a clock driver. That is, if I understand the documentation properly. -- Dennis Hilberg Jr NTP Server Information: http://saturn.dennishilberg.com/ntp.php ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Peerstats and Rawstats Info
On Aug 22, 1:45 pm, Aggie <[EMAIL PROTECTED]> wrote: > Hi Viven, >I'm working on the > similar things as u. But I couldn't generate any files. Alright, > Thanks. Hi Aggie, Here is my ntp.conf file. # NTP Network Time Protocol # Configuration File created by Windows Binary Distribution Installer Rev.: 1.18 mbg # please check http://www.ntp.org for additional documentation and background information # Use drift file driftfile "C:\NTP\etc\ntp.drift" enable stats statsdir "C:\NTP\" filegen peerstats file peerstats.txt type none enable filegen rawstats file rawstats.txt type none enable statistics peerstats rawstats # your local system clock, could be used as a backup # (this is only useful if you need to distribute time no matter how good or bad it is) #server 127.127.1.0 # but it should operate at a high stratum level to let the clients know and force them to # use any other timesource they may have. #fudge 127.127.1.0 stratum 12 # Use specific NTP servers server 150.187.28.58 # End of generated ntp.conf --- Please edit this to suite your needs > How long did it take you to generate the files?? I don't really but i can say that the ntpd run for like 6sec and after the files are generated. Hope it helps you, Vivien ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Unresolved Symbol
In article <[EMAIL PROTECTED]> Harlan Stenn <[EMAIL PROTECTED]> writes: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Per >Hedeland) writes: > >>> if ((pOpts->pzCurOpt != NULL) && (*pOpts->pzCurOpt != NUL)) > >Per> However I do think the use of NUL is unwise, having a plain '\0' there >Per> instead would avoid an initial potentially confusing >Per> misreading/misunderstanding (not incidentally, it is only the libopt >Per> code that uses NUL, the "proper" ntp code uses '\0' everywhere). > >I think this is a personal preference thing. Certainly if you don't expect others to (need to) read your code. >I wrote tons of code using NUL for '\0' (the former is MUCH easier for me to >type as I have carpal tunnel problems) and I also used NIL instead of >NULL, as I find that much easier to read. That's fine for you - but if others will need to read and understand your code, it's a pretty objective fact that it helps if you stick to the standard idioms of the language in question. For C, that includes neither NUL nor NIL (the presence of a #define for NULL is even part of the language standard requirements IIRC - though of course there is no requirement to use it). --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Peerstats and Rawstats Info
Thanks Vivian!! It works now. I don't know why mine didn't work before. Thanks a lot. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
