Toshikazu,
I'm taking a wild guess, but generally anything "stratum 16" means
"unsynchronized" or some other similar issue. So if a client
synchronized to a server that was already stratum 15, then the client
would become stratum 16, and maybe that causes some other issues
(either in ntpd or other
> Forgive me for my lack of knowledge in this area,
> but does the above command and output still show the vulnerability?
> If so, is the fix (as NTP Bug 3118 explains) to add
> "restrict default noquery" to the ntp.conf file?
> If this is the fix, then all queries are shutoff, correct?
Philip,
> For server-entries in ntp.conf, how does ntpd (4.2.8p13) time refreshing
> of hostnames?
As far as I know, for regular server entries once it's done the
initial lookup on startup, that's it...
I believe for pool entries it will do a lookup to grab new IPs if a
pool server goes silent. Maybe tha
You never mentioned what your "clients" are going to be using? Are
they running NTP too and will be able to choose multiple sources, or
are they basically SNTP clients requesting time from only one server?
As someone else said, using 'peer' really isn't useful or necessary
*unless* your connection
>From what was posted on the pool forum:
TORIX support said the problem was due to a software update.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Disclaimer: This is all in theory, you will have to test it out
first-hand to see what the actual results are
You could fudge Node A so it's local clock is a stratum 10 when there
is no other valid source. Seeing as how that would be the only clock
for Node B, it should sync to that:
ntp.conf
> As a follow-up to this, I could not get ntp to compile on
> macOS Mojave, but I could get OpenNTP to compile and run.
If you don't use crypto with NTPD I believe there is a flag to disable
it. I wonder if it would still run into compile issues then?
__
It's been quite a few years since I've had to dig around the refclock
code, but IIRC the NMEA code simply uses the PPS code, so either
method should yield the same results.
Probably the only noticeable difference might be the refid showing
"PPS" vs "GPS"?
Jason
___
> Yes, the main reason behind the requirement is probably the traceability
> to UTC of the stratum 0 used by the server : NIST servers are traceable
> to UTC, which is (formally) not the case for a server with a GNSS
> as stratum 0.
>
> In case NIST servers are hard to reach, a metrologically defen
> Yes, this is a common PITA. FINRA and/or SEC getting onto you?
> They are still "defining" the regulation, but the current idea is rather
> silly.
> Many of the NIST servers are run out of the University of Colorado and
> are single home with CenturyLink. Congestion and/or other network
> issues
Have you checked for possible packet loss somewhere between you & the
NIST servers? That's the usual problem.
Are you querying at an excessive rate? That's another possibility.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listi
> The last paragraph in section III.A describes Fig.2:
>
> - Is phase-lock loop a software component?
In this instance for NTP, yes.
> - I think that VCO means a component commonly found in every computer.
> Is my understanding correct?
In this instance for NTP, yes. You can assume they mean a
Argh, didn't realize I only replied directly to you in my previous
email. This one should go to the list too.
Anyhow, I dug through the source and found what I think is the
relevant information.
It's in ntp_monitor.c near the bottom.
(note, near the top there is: int mon_age = 3000;)
/*
* If we
I'm trying to tweak my ntp configuration so it will drop packets as
appropriate instead of using my firewall & hashlimit... (For reference, I'm
running the latest 4.2.8p12)
Apparently the relevant commands (beyond setting limited & kod) are
'discard' and 'mru'.
'discard' has three settings: avera
Thanks for the link to the paper, very interesting stuff! I've only
given it a quick read, when I have more time I'll definitely sit down
and study it more in-depth.
I noticed the data used was from May-June 2015, has there been any
newer sampling done? Or any other location for some statistics li
In response to my own question I looked a little deeper into the odd
traffic using tcpdump. Best I can tell they are indeed properly
formatted NTP requests, the curious bit is seeing most of these
requests having a precision of -6 or -7. While I know some older MS OS
set their internal time update
I was making some firewall changes and accidently flip-flopped some
settings briefly. While reviewing the firewall logs I noticed that
there was some NTP traffic coming from various privileged ports (other
than 123)... Literally like ports 1,3,5,6,7, and many others in the
double & triple digit ran
I was mainly reading RFC 5905 since it's the latest, but it does make
some references back to the older RFC 4330 (SNTP). I believe it is
that document (and others) that seem to flip-flop on what is signed /
unsigned. i.e. 5905 says poll interval is signed, 4330 says poll
interval is unsigned.
I du
I'm writing my own little query script to decode NTP packets and I've come
across some conflicting information in the RFCs and other white papers that
I'm hoping an authoritative source would know the answer to.
Specifically for the 'Poll Interval' and 'Root Dispersion' fields in the
NTP packet, s
John,
I think this page explain orphan mode and configuration the best:
http://www.eecis.udel.edu/~mills/ntp/html/orphan.html
I kind of did similar to that setup... My S1 servers don't all run
standard NTPD so I couldn't do anything about that. What I did was make a
S2 group that used the "tos o
> On Mint 17 ntp from the repo works well with offsets in the low
> tens of milliseconds, sometimes < 10ms.
Do you have your HPET clock enabled in your BIOS (if there is a choice
for it)?
Maybe as a test try disabling any powersaving features of your CPU (via
the BIOS). Sometimes the dynamic CPU
> I'd have to look this up but think board using Elan 486 used the
> on chip high speed timer to timestamp the pps input at a gpio
> port along with a custom ntpd on FreeBSD to obtain sub us offset.
You mean something like this? *grin*
http://www.rabel.org/pics/Net4501-2.jpg
Yes, that is one of
> There are two obvious ways to go for an embedded client.
>
> One way would be to use the sntp code as the base.
>
> The other would be to either use the current NTP codebase and use the
> configure options to disable all the refclocks and anything else you
> didn't want, or wait until we're done
> Would it be useful to offer an "official" minimal implementation
> intended for embedded systems so that these people won't feel the need
> to code their own? Maybe add minimal NTP support to Busybox?
Actually, Busybox does have a ntp daemon... Where the code comes from I do not
know. I've tri
Has that *always* been the case? Or has the code be changed over time?
Remember, not everyone is running the latest development (or even stable)
version of NTP...
> KOD already sets a timestamp that is the requesters timestamp. See my
> previous response. It's better than your idea since it is
I have to agree on some points with these two below. From my experience also,
using KOD usually results in more packet pounding from
bad clients (from what I can only assume is poor coding of custom clients).
The realization is that many clients don't run the standard NTP distribution,
but rathe
Jaap,
You can skim over these past few months on the time-nuts list. There's lots of
threads with discussion on ARM, Beaglebone, Rasberry
Pi, etc... for GPS based NTP servers...
http://www.febo.com/pipermail/time-nuts/2014-March/date.html
http://www.febo.com/pipermail/time-nuts/2014-April/date.
> Yes, and remember we live in a world of NAT. While there is much to be
> said for running "your" NTP servers that talk to outside NTP servers and
> having all of your other NTP clients talk to your NTP servers, some
> folks don't do this, and that means their clients can send a lot of
> queries
Brian,
A few things you did not mention in your post or your article...
What bandwidth setting (Net Speed) did you specify on the NTP Pool website for
your server? What Zone(s) is it listed in?
Also, can you provide a link to your NTP Pool server's page? The URL would look
something as follow
> Packets in and out from a box are the default variables MRTG is designed
> for, and can be had from FreeBSD, Windows & Linux systems. Frequency,
> offset & jitter, and dispersion you should be able to get by parsing
> "ntpq -crv" output as my Web site shows.
I'm talking NTP only packets, not
> I should perhaps have mentioned that I use MRTG,
> but using the "ntpq" command and parsing its output
That is what I do too... If the meinberg unit is running NTPD (I've seen
several commercial units do that with their own custom
refclock) it would probably be easier to parse the data you wan
> Ok, so on a whim I purged it completely from the system. Installed from
> scratch and the same problem occurred, no starting up of the process. I
> let the installation complete without letting it try to start the
> service again. Then I simply performed a "reinstall" where it detected
> the e
I noticed yesterday morning that my time dispersion suddenly tightened up on my
server... Odd...
http://www.rabel.org/ntp/graph_dispersion.png
(Sorry for the jump at the end, that is when I restarted it earlier this
morning.)
At first I thought maybe NTP switched to a different server, so I lo
> I want to keep the time updated on a small Embedded Linux device.
>
> The clock doesn't have to be very accurate. An offset of a few seconds
> is OK.
>
> This small device only has Internet for a few minutes a day and I have
> to pay for each byte that gets transmitted, so I want to keep the
>
> First, we sync all machines to locally connected GPS receivers with
> PPS output. We use ntpd and kernel PPS. This is wellknown territory.
> In the ntpq -p stats this appears to bring the systems within 10us,
> often within 2us, of the PPS signal. We still have to find out if this
> is realit
> I am saying that the ntpd that ships with Ubuntu 14.04 is limited because
> it was built on a system where timepps.h was not present, and thus the
> ATOM and JUPITER (and a couple other) refclocks were not included in the
> binary. Even though PPS support is present in the kernel.
>
> I built nt
> I recently use TrueTime XL-AK, when I first start the
> system, it only take about 10 minutes to lock satellites.
> And I think it is good. But the second time I move to
> another place (about 40 miles away from the first place),
> it never lock any satellites again. I am not sure about the
> pr
> From my site, both uh.edu and tmc.edu are pretty close,
> latency-wise. And uh.edu's being ST1 was certainly a plus.
> Anyway, it's still in my list, hoping that it comes back alive.
> FWIW, the ST2 server at tamu.edu is pretty close to me too.
> Adding another nearby server, even ST2 would be
> I would like to know whether NTP can sync between a
> client and a server within 1ms if the client and server
> are Linux applications on a simple local network ( less
> than 10 nodes).
Yes, if simply go by the offset figure in NTP, you can usually get
sub-millisecond figures between two mach
> The NTP ST1 server at the University of Houston has been
> offline for about a month. Any information about its demise?
> Yet another victim of a DOS attack?
I don't know, it seemed kind of flaky at first then it stopped responding
altogether. I finally gave up and removed it from my list
a wh
> I wonder why the change was made in the first place. Did it improve
> things for some users? It seems wrong to introduce something that
> causes problems for some use cases unless it benefits others.
Maybe sift through the changelog to see if anything stands out? Or search the
bug tracker? Har
> I've got a Debian Linux system which uses ntp to synchronise its
> clock, and is itself used by my internal systems for time
> synchronisation. This system has two Internet connections for
> resilience and load balancing, configured using Linux advanced routing
> and with two default routes to t
> Orphan Mode is an automatic server discovery scheme. Nothing more.
>
> Orphan Mode does not make it possible for the members of a "time island"
> to determine the correct time in the absence of reference sources.
>
> Symmetric Active/Passive Mode (aka Peer Associations) allows the
> creation of a
Greg,
As others have suggested, any client running NTP should point to *at least* 3
time sources (usually ~5 is preferred)... The reason
being if one server goes wacko, but the other two agree, then the client knows
to X out the bad one and keep the two others. With
only two you are essentially
I've seen in the reflock driver sources where they hard-code in the serial port
speed (i.e. 9600), but what about the parameter
settings? i.e. the data bits, parity bit, and stop bit?
Specifically I'm using the palisade driver, but have selected 'mode 1' because
I'm using an Endrun Technologies
Charles Swiger wrote:
> Your comment means a discussion of best practices of configuring
> these stratum-1s is also beyond the scope of answers to your post.
> Odd, but have this as you would
Charles, my S1 servers are a mixture of NTP appliances and other hardware that
do not run the standar
Figured I would ask just to double-check I'm doing this right since it's my
first time using the "peer" statement.
I'm reconfiguring my NTP setup to try and be somewhat fault-resistant if GPS
blacks out since my receiver is in the window and only
picks up facing east.
I have four stratum-1 serv
> Why not? You really want to as the network entries
> will do iburst and get selected before your refclock
> does and force some clock stepping before settling down.
> I usually use maxpoll 4 as well. The decreased jitter
> in the local signal makes higher poll rates both valid
> and useful.
Arthur,
What OS are you using specifically?
Also, you shouldn't put "iburst" in the server line for a local refclock... I
don't even know if that is valid, hopefully NTP
ignores it.
Jason
___
questions mailing list
questions@lists.ntp.org
http://lis
A while back I saw a couple web pages where people graphed various aspects of
their NTP server(s).
One of the graphs of particular importance to me was where they showed NTP
specific inbound & outbound bandwidth.
For the life of me I can't figure out how they did it though. Are they fudging
th
Chris,
This is *probably* caused from EIST and/or C1E being enabled in your BIOS.
These features dynamically adjust the speed of your CPU (and voltage)
according to the CPU demand. You can try to disable them and see if things
stabilize, if they do then you know what the culprit is.
If you really
Remco,
I've used several Jupiter 8 receivers quite successfully (in Binary Mode)
with NTP & FreeBSD.
Yes, they are not really useable in NMEA mode as the second will jump around
and constantly be off by 1-2sec.
Are you sure your receiver has a valid almanac and enough satellites in
view? Seeing
I've built some RPMs for CentOS using the latest SRC from the FC9 branch.
They include that patch and I've noticed no discernable difference in time
keeping and everything appears to be functioning as it should.
Jason
> I came across the following page:
>
> http://www.lesswatts.org/projects/pow
> Strange. I have an EndRun Cntp, bu it has an Ethernet interface. If 4
> works for you use it. That's a pretty grotty driver with all kinds of
> bandaids to deal with long forgotten radios; I wonder why EndRun chose
> that driver...
>
> Dave
Yeah the code for the TrueTime devices is pretty ha
The TS2100 internally has a Trimble ACE-II or ACE-III receiver. Any standard
5V GPS antenna will work, they are a dime a dozen. If you want to get more
high-end with a timing antenna, I would just watch eBay and be patient for
one of the Trimble Bullet antennas (do a Google search with the part num
> We have tried it with a small test setup and found that w32time domain
> members did identify their PDC as time source when w32time was running on
> the PDC, but not when ntpd was running on the PDC.
>
> I have recently received a note from someone who seemed to be very
familiar
> with Active Di
Soleth,
> Explaining it better, it is a kind of network switch for which I don't
> have total access,
> and can only talk through a protocol, that offers me a date in format
> -MM-DD hh:mm:ss. Period.
Does the server auto-output the info "on-time" every second, or only
dynamically reply when
> >> Are there any GPS systems I could hook up to the Windows domain
> >> controller, and configure W32tm to use this?
> >>
> >
> >Yes. Trimble, Palisade, NMEA, Jupiter, and HOPF (DCF77) Serial and PCI
> >are built for Windows. I cannot tell you much about them but the code is
> >built for them.
You can try using the "prefer" flag (read the docs) to have it stick to one
of the servers.
Jason
> I've recently been provided with 4 "highly accurate" ntp servers that
> are using GPS as their primary synchronization source. Well, 2 of the
> hosts are using GPS (stratum 1) and the other two a
> The GPS computation of location, elevation, and time involves a system
> of four simultaneous equations which can be solved for time, lattitude,
> longitude, and elevation. Doing an extended "site survey" can refine
> your location and elevation. The better location data, the better the
> s
Are both your current clocks using the same GPS antenna? If so, there is a
common point of failure right there.
If you put a 3rd clock w/3rd antenna at a different location you can do some
interesting measurements between the 3.
GPS is going to give you the most accurate / stable time (assuming y
I've compiled some RPMs for RHEL/CentOS that are using the latest stable
version of NTP... Or you can build your own from the SRC RPM...
http://ntp.extremeoverclocking.com/rpm/
Jason
> Hi All
>
> Iam trying to install ISC NTP-4.2.4 on RHEL 4. But Im not able to start
> the services.
>
> I f
I've tried to keep quiet and bite my tongue at this whole ntp vs chrony
thing... But something has been nagging me in the back of my head that i
juat have to know the answer to...
How are you measuring your results? From what I've skimmed over you are
simply using each program's own generated stat
It probably wouldn't hurt to upgrade NTP to a v4 build...
> Hi,
>
> IBM has recommended a reboot of the server after running this command:
>
> bosboot -ad /dev/ipldevice
>
> I have ran the command and am now waiting for a reboot window on the
> server. After all the research and comments I read
>> I have a gpsd and ntpd in connection running on a Fedora 5 box.
>
>Why not connect the gps directly to ntpd? (if it supports nmea output)
>If it has PPS output you get magnitudes higher accuracy.
Linux doesn't directly support a PPS signal (unless you use some 3rd party
code to patch and recomp
> Richard B. Gilbert wrote:
>> Computer Network Time Synchronization: The Network Time Protocol by
>> David L. Mills (Hardcover - Mar 24, 2006)
>>
>> Available from Amazon.com. You may be able to find a copy at a
>> University Book store. Be prepared for "Sticker Shock". It ain't
>> cheap! Pub
Since nobody said anything I went ahead and compiled some RPMs because I was
tired of the old versions some of my RHEL / CentOS servers were running.
http://ntp.extremeoc.com/rpm/
I don't have a el5.i386 RPM up yet, I'll try to get that online later today.
You can always build your own RPM from s
After reading the documentation (took all of a minute or two), thttpd does
support multihoming, but it doesn't look like it supports wildcards.
For that you will probably have to run apache or another web server that
does support wildcards.
Or you could just have some text on your front page sayi
> It's an embedded system. The one I manufacture today can have today
> (or this year) in it but I'll never touch it again to change the
> initial time setting. One thought I had was periodically write the
> time to a file and use that file to initialize the clock at startup
> before using NTP.
I'm just curious if anyone has come across any current (3rd party) RPMs for
RHEL/CentOS. I run a mix of versions 3, 4, and 5, some 32bit and some 64bit.
I was playing around building some RPMs updating the patch files from one of
the older versions, and even though that worked I noticed there were
>> Folkert van Heusden wrote:
>>
>>> Has anyone found a firmware for the wrt54g with an integrated ntp
>>> server?
>>
>> Such a thing is more likely to have an NTP client that polls once per
>> second! ;-)
>
>OpenWrt seems to have it.
>
>https://dev.openwrt.org/browser/packages/net/ntpd/Makefile?re
> The setup: O(10) FreeBSD 6.2 machines in a rack, a PPS source, and an
> NTP server somewhere on the same network. Is it possible (and if so,
> how?) to configure ntpd on these machines so they get the rough time
> over NTP from the network's NTP server, and use the PPS source so they
> stay
> As per your suggestion I would have used the existing NMEA
> reference clock driver
> for Accord GPS Clock. But there are certain issues as listed below.
>
> 1. Accord GPS Clock spits out NMEA at 9600 baudrate
> 2. It has custom NMEA format for GPS (and the driver is
> intended to use this )
>
>When I care about things like that and do not like the stock firmware, I
get
>a unit that will accept the openwrt.org firmware.
+1 for OpenWRT! I installed it on a Dell Truemoble 2300 router I got off
eBay for ~$10. The hardware is more or less identical to the Linksys WRT54G,
just much cheaper t
> What's the proper way of telling whether the PPS signal is actually
> having an effect? That is, what behavior/measurements would show me
> that the PPS signal is or is not being used? What should I be monitoring
> (my guess would be "offset" and "jitter" from the netq -c rv output),
> and w
"prefer" should only be used against one peer/server. This tells NTP that
all things being equal, choose this one over the others. Not only do you
list it in multiple peers, but also multiple times in the same line.
"iburst" tells it to send multiple packets when it is unsynchronized, which
helps
> - is the precision of these "messages" (or timestemps) affected by the
> stability of the local oscillator ?
For all practical purposes, no. As Dr. Mills said, there are many other
factors causing various bits latency in a PC that are independent of the
oscillator. What little you might gain fro
Your output looks okay... like you said, ntptime returned info so I think
you answered your own question. ;)
Jason
> According to the ntptime man page "This program is useful only with
> special Kernels described in the A Kernel Model for Precision
> Timekeeping page."
>
> Is there an
> This is a Trimble SVeeSix (with NMEA firmware) hooked up via a FTDI USB
> to RS232 adapter. I have to use shmpps because IIRC even if I patch the
> Linux kernel, it doesn't support PPS on USB to RS232 adapters (I'm not
> sure anyone does).
But does shmpps support the PPS signal on a RS232-USB c
I don't think you really need to use the "disable" lines in the compiling,
having the extra clocks doesn't hurt anything. In addition to the SHM driver
you probably need the PPS/ATOM driver too which isn't in your compile
string...
Jason
> The starting point was Philip M. White documentation call
> I wonder if there are NTP clients for Windows which can be more
> efficient than w32time. As we can read in
http://support.microsoft.com/kb/939322,
> "The W32Time service cannot reliably maintain sync time to the range
> of 1 to 2 seconds". Can an other client do it ?
You can maintain *decent* t
> What is "Open ntpd"? Where did you get it? Are your really talking
> about the reference implementation?
http://www.openntpd.org/
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
> The host is a dual processor FreeBSD host with low load, today
> counting 107 days of uptime. The connectivity is a 11Mbps fiber optic,
> that proven pretty reliable in the last five years.
> So I did not believe those stats first and put a polling script on
> another server 150 km away from this
My bad, I meant ulimit -l 8192 not -n
Jason
> Jason Rabel wrote:
> > ulimit -n 8192
OK, I put it in the startup ntpd in /etc/rc.d
no change, as soon as the rating gets over 5, and load shows up, ntpd
crashes.
___
questions mai
Well it was worth a shot. I've seen some strange things using the kernel's
hardpps, usually you get better results with NTP's as it averages more data.
I currently don't have a GPS hooked up to my FreeBSD box or I could let you
know the output, but IIRC when you don't set the fudge flag you don't s
Comment out the fudge line for your GPS and see how it goes.
Jason
>
> My ntp.conf is:
> driftfile /etc/ntp.drift
> enable pps
> server 0.ca.pool.ntp.org
> server 1.ca.pool.ntp.org
> server 2.ca.pool.ntp.org
> server time.nrc.ca
> server time.chu.nrc.ca
> server 127.127.20.1 minpoll 4 mode 1
>
> > Jason Rabel wrote:
> > Try adding:
> > ulimit -n 8192
> > To your rc startup for ntp?
> I don't have a .rc, other than what's in /etc/rc.d/init.d
> which really doesn't have options.
>
> Does this work in /etc/ntpd.conf?
No, not in t
Try adding:
ulimit -n 8192
To your rc startup for ntp?
> I also just added to the pool and am having similar problems.
> If you look at the service graph, you see a sawtooth process.
> http://www.pool.ntp.org/scores/70.184.242.241
> the values get better until I start getting real load, and
hing except ntpd deciding what constitutes the best set
> of servers. I even had a hook in the code base to expose this
> information just for this reason, but it got yanked out when the
> preempt code went in.
>
>>Jason Rabel wrote:
>>
>> Brian,
>>
>>
> What Henk has described is just the first step in a facility that I
> have been thinking about for quite some time. The idea is to allow a
> much more extensive level of self-organizing emergent NTP behavior.
> But the ability of get this type of incremental behavior is
> crucial to getting it
Which version of NTP are you using? Any output from the debug or syslog?
> Hi -
>
> On one of our AIX 5.3 boxes, xntpd isn't very happy. If I run
>
> xntpd -l /home/cg5/a.a -dd
>
> it lasts about 10 seconds before hanging and not responding to any
requests.
>
> (If I just run it norm
> If you really care, the best route is a hardware reference clock; e.g. a
> GPS receiver or, if you get a solid signal from Fort Collins, CO, a WWV
> or WWVB receiver. That makes you a stratum 1 server! A GPS receiver
> with a PPS signal should be accurate to within 100ns or better. After
>
> Even if a server is physically 1 mile from you, the route between you and
> that server may go through a network junction a long way from you if you
> use different ISPs.
I can comment on that. I've done a tracroute on a server in the same city as
me (Houston, TX) but using a different backbon
> The main concern is that that the laptop spends to much time adjusting,
> correcting, etc... when it's only got a short time on the ISP. As
mensionned
> before, short time is a few (anywhere between 1 and 4) hours.
> As the other machines of that LAN can't rely on the continuous presence of
> the
>> If only the human scale is required, how about ntpdate run via cron or
>> its platform-specific equivalent. On the laptop, it would try to get
>> time from the ISP's NTP server(s). On the other systems it would try
>> to get time from the laptop. So, when the laptop is connected to the
>> ISP
Maybe also try setting the maxpoll to a reasonable but lower value so that
it doesn't wait 1024s between polls.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
> Spoon wrote:
>
> > On a typical x86 motherboard, are the PIT (Programmable Interval Timer)
> > and LAPIC (Local Advanced Programmable Interrupt Controller) timer
> > driven by the same crystal?
> >
> > In other words, will ntpd compute a similar frequency offset if I switch
> > from PIT to L
> I am a university student undertaking a small undergrad project on
NTP/SNTP.
> I was wanting to know about any sources pertaining to the evolution of
NTP,
> particularly any showstopper flaws / security issues in versions up until
> v3.
I would read the RFC files, they will probably best expl
> I've been searching for a doc I saw previously regarding how high
> jitter/dispersion can indicate impending hardware failures, but in
> my last 2 attempts haven't been able to find it. I'm also interested
> in docs regarding NTP and power quality.
I think it would just be sheer luck if NTP sho
>> What's your root dispersion number? (should be on the same output)
>
>On my stratum 2 it's rootdispersion=5.441
>
>My stratum 1 shows rootdispersion=0.336
Those numbers seem much more reasonable.
The root dispersion is the maximum error between the local clock and the
root of the NTP chain. Yo
1 - 100 of 127 matches
Mail list logo
