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
> 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
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
>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:
> 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
> 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
>
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
> 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
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:
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
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
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
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,
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
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 with
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
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
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
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 tried
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
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
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 want
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 all
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
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 reality or
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
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
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 ntpd
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
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
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 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
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?
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
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 the
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 standard
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
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.
Greg,
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
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
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
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:
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.
Do these
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 are
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
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
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
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 out
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 recompile
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! Publishing in
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
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.
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
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 to
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 what kind
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 from a
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
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 called
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
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 mailing list
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
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
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 the ntp.conf file... Add it to the ntpd file in your init.d/
directory
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
fudge
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
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 to
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,
Perhaps rather than trying to implement in NTP itself via some new
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 network,
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 LAPIC timer?
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
5 ms is pretty darn good especially over wifi. What number are you using
for
your 'precision'? There is no way you can get µs precision over Ethernet,
you must be reading something wrong.
I have a machine synced exclusively to my stratum 1 over Ethernet that
keeps
a +-100 µs offset, unless
I am a student from a French engineering school. I am currently
working on a synchronization over WiFi project that could apply to
embedded devices.
For the moment, I have only reached a precision of 5 ms.
(Whereas I get a precision of a few hundreds of microseconds with an
Ethernet
Pigs will fly before GALILEO does... It has been way over budget and
nobody wants to sink any more money down that bottomless pit.
Early 2003 they had more money than they could spend. I don't know
their current situation.
Well, I guess they found a way if they are having to resort to
Oooo... Ahhh... :)
http://electronics.howstuffworks.com/gps3.htm
Satellites don't tell you where you are... They only tell you where they are
at a certain point in time. Your receiver has to do the math to determine
its location based on the time it takes for the signals to reach you.
Well,
Making GPS unreliable for navigation would be shooting ourselves in the
foot! Remember that commercial aircraft use GPS for navigation as well
as private aircraft, military aircraft, ships, motor vehicles and lord
knows what else. I'm inclined to doubt that any country's weapons
systems
Finally, I believe President Bush said that in the time of certain
emergencies he would order the GPS satellites to broadcast incorrect time
(which would make GPS unreliable for ... navigation); this possibility is
at
least something to be aware of.
That would probably only be for areas of
Well, I need to clarify datacenter: actually these are not OUR
datacenters, we use co-location at some provider, so we don't have a
lot of control there (some of them will not even allow us to feed
another cable into their server room). So even using a remote
antenna (on the roof) might not
Your GPS offset is almost a second off... Thus it fails the sanity checks
and is discarded.
Which GPS receiver do you have specifically?
http://www.ece.udel.edu/~mills/ntp/html/drivers/driver26.html
If you have a Z3801A (or similar), did you add the mode 1 on the server
config line? And did you
http://www.ece.udel.edu/~mills/ntp/html/drivers/driver26.html
If you have a Z3801A (or similar), did you add the mode 1 on the server
config line? And did you follow the suggestions for the proper fudge
factor?
No. What I posted before is the entire ntp.conf.
clueless newbie question
ACK, thanks also for these tips.
Next newbie question: Is .GPS. the correct refid I should see?
lancelot# ntpq -p
remote refid st t when poll reach delay offset jitter
=
*time.domain.tld .GPS. 1 u 33
Still, something to consider. I'll keep the GPS unit as discreet as
possible.
/mumbles something about the lack of affordable and accurate CDMA timing
receivers.
Did you decide to take a shot with the Garmin GPS 18? You could probably
spray-paint it white, or whatever color the railing is
In cases like this you could just point the drift file to a ramdisk
partition. ;)
Jason
Steve Kostecke [EMAIL PROTECTED] writes:
Embedded systems / appliances which use flash memory are one place where
writing/touching files unecessarily is a BadThing(tm).
In addition to flash you also have
I think Paul hit it right on the head with his post...
A higher-grade oscillator in your PC won't *really* matter (for computing
purposes), and even NTP over the internet you just aren't going to get that
resolution because of all the delays and interrupts. Your drift would be
lower, but since
Just patch the kernel to use the new clock for timekeeping.
Ah, see, my familiarity with Linux does not extend to kernel patching.
If I knew how, that'd be something I'd definitely do.
Are you aware of any references that might be helpful?
You might be able to trudge through the PPSkit
94 matches
Mail list logo
