In message e1wsemc-000dz8...@stenn.ntp.org, Harlan Stenn writes:
I'm actually not certain that it helps, even if you document it.
It's sort of an administrative distance and it unfairly penalizes
any GNSS in favour of terrestial if you calibrate it according to the
original intent...
I'm
On Mon, Mar 24, 2014 at 4:26 AM, Poul-Henning Kamp p...@phk.freebsd.dkwrote:
In message CABbxVHuQc0144==21mDa_R8ErKov=
em+9rvrbpggexnzztj...@mail.gmail.com
, Chris Albertson writes:
Yes. NTP calls it root distance [...]
And it is generally useless, because people don't calibrate it.
How
In message CAKyJ6kajBO=yvkg44s_sdo5owruzem4tzx8atvcirkmgcn8...@mail.gmail.com
, Paul writes:
On Mon, Mar 24, 2014 at 4:26 AM, Poul-Henning Kamp p...@phk.freebsd.dkwrote:
And it is generally useless, because people don't calibrate it.
How do you calibrate root distance assuming that it's
On Tue, Mar 25, 2014 at 5:52 AM, Paul tic-...@bodosom.net wrote:
On Mon, Mar 24, 2014 at 4:26 AM, Poul-Henning Kamp p...@phk.freebsd.dk
wrote:
In message CABbxVHuQc0144==21mDa_R8ErKov=
em+9rvrbpggexnzztj...@mail.gmail.com
, Chris Albertson writes:
Yes. NTP calls it root distance [...]
[I apologize in advance]
On Tue, Mar 25, 2014 at 7:47 PM, Chris Albertson
albertson.ch...@gmail.comwrote:
Peole here have very much mis-understood the term Root Distance.
I don't think Poul-Henning Kamp should be accused of misunderstanding NTP.
My question was answered (I wondered why I had a
I think I figured it out. rootdisp=0 refers to Root Dispersion which
is quite different from Root Distance. They do look a little alike.
One is the distance from the local clock to the root of the NTP tree and
the other is something different, internal to NTP that is not exposed to a
user.
albertson.ch...@gmail.com said:
The assumption NTP makes is that you can judge the quality of a server by
the variance (of jitter) in the time it reports.
I think it's more complicated than that.
I think it also includes the non-jitter part of the round trip time. NTP
assumes the path is
ja...@extremeoverclocking.com said:
If there was some sort of feature in NTP (maybe there already is???), or
even a separate program that could test a list of NTP servers to try and
pick the lowest latency, I think that could have a positive benefit on
better time transfer.
The current
On Sun, Mar 23, 2014 at 11:50 PM, Hal Murray hmur...@megapathdsl.netwrote:
albertson.ch...@gmail.com said:
The assumption NTP makes is that you can judge the quality of a server
by
the variance (of jitter) in the time it reports.
I think it's more complicated than that.
I think it
In message CABbxVHuQc0144==21mDa_R8ErKov=em+9rvrbpggexnzztj...@mail.gmail.com
, Chris Albertson writes:
Yes. NTP calls it root distance [...]
And it is generally useless, because people don't calibrate it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org |
On 3/23/14 10:48 AM, Paul wrote:
On Sun, Mar 23, 2014 at 1:08 PM, Bob Camp li...@rtty.us wrote:
I suspect that what NIST is looking for is somebody in the cloud business
(Amazon, Google, Microsoft, IBM) to step up and mention that they have
2,989,875 server racks scattered about the world and
Poul-Henning Kamp writes:
In message CABbxVHuQc0144==21mDa_R8ErKov=em+9rvrbpggexnzztj...@mail.gmail.co
m
, Chris Albertson writes:
Yes. NTP calls it root distance [...]
And it is generally useless, because people don't calibrate it.
http://bugs.ntp.org/show_bug.cgi?id=2587
Because I've
In message e1wsboi-000dny...@stenn.ntp.org, Harlan Stenn writes:
Poul-Henning Kamp writes:
In message CABbxVHuQc0144==21mDa_R8ErKov=em+9rvrbpggexnzztj...@mail.gmail.co
m
, Chris Albertson writes:
Yes. NTP calls it root distance [...]
And it is generally useless, because people don't
Poul-Henning Kamp writes:
In message e1wsboi-000dny...@stenn.ntp.org, Harlan Stenn writes:
Poul-Henning Kamp writes:
In message
CABbxVHuQc0144==21mDa_R8ErKov=em+9rvrbpggexnzztj...@mail.gmail.com
, Chris Albertson writes:
Yes. NTP calls it root distance [...]
And it is generally
NTP is best used over the Internet. It was designed for unreliable data links.
In the quest for expansion of NTP over the internet, one thing has always
nagged me.
You can find lists of servers and they will give a physical location along with
other info about them...
Big whoop... Often
Hi
You can (and many do) run through a list of servers with an NTP client and see
what you get. It’s a bit of work, but you only do it once.
———
I suspect that what NIST is looking for is somebody in the cloud business
(Amazon, Google, Microsoft, IBM) to step up and mention that they have
On Sun, Mar 23, 2014 at 9:26 AM, Jason Rabel
ja...@extremeoverclocking.com wrote:
If there was some sort of feature in NTP (maybe there already is???), or even
a separate program that could test a list of NTP
servers to try and pick the lowest latency, I think that could have a
positive
On Sat, Mar 22, 2014 at 6:34 PM, Paul tic-...@bodosom.net wrote:
E.g. FSM says their NTP+PTP servers perform equally well using either
protocol. The trick is to use optimized NTP software and timestamping
hardware.
Yes. If you modify NTP so that is does the same thing as PTP then it
will as
On Sun, Mar 23, 2014 at 1:08 PM, Bob Camp li...@rtty.us wrote:
I suspect that what NIST is looking for is somebody in the cloud business
(Amazon, Google, Microsoft, IBM) to step up and mention that they have
2,989,875 server racks scattered about the world and they would be happy to
run NTP
On Sun, Mar 23, 2014 at 1:37 PM, Chris Albertson
albertson.ch...@gmail.comwrote:
Yes. If you modify NTP so that is does the same thing as PTP then it
will as good as PTP. That should be obvious.
I believe you misunderstand my point.
___
time-nuts
Jason,
On 23/03/14 17:26, Jason Rabel wrote:
NTP is best used over the Internet. It was designed for unreliable data links.
In the quest for expansion of NTP over the internet, one thing has always
nagged me.
You can find lists of servers and they will give a physical location along with
It's not really stratum based. The clock selection algorithm is described
here
http://www.eecis.udel.edu/~mills/ntp/html/select.html
Basically it allows every clock that can logically contribute That means
with estimated error bounds that over lap.
That with those not eliminated nTP applies a
On 3/19/14 9:50 AM, Chris Albertson wrote:
So they want to in-invent NTP?
I think NTP already services way more than 6.5 billion per day. The
problem with NTP is while it is nearly optimal and provides the best
time accuracy for a given hardware/network setup it is not technically
traceable
I can see a use for an inexpensive GPSDO with a built-in
gigabit ethernet or USB3 port powering an NTP server.
On 03/19/2014 10:21 AM, Jim Lux wrote:
On 3/19/14 9:50 AM, Chris Albertson wrote:
So they want to in-invent NTP?
I think NTP already services way more than 6.5 billion per day. The
On Sat, Mar 22, 2014 at 12:24 PM, Chuck Forsberg WA7KGX c...@omen.com wrote:
I can see a use for an inexpensive GPSDO with a built-in
gigabit ethernet or USB3 port powering an NTP server.
Neither of those is a good way to transfer time to an NTP server.
Both Ethernet and USB are packetized.
On Sat, Mar 22, 2014 at 2:24 PM, Chuck Forsberg WA7KGX c...@omen.com wrote:
I can see a use for an inexpensive GPSDO with a built-in
gigabit ethernet or USB3 port powering an NTP server.
Why not a BeagleBoneBlack with a GPS module that has 1pps out connected to
an I/O pin. For that matter,
The PRUs (Programmable Realtime Unit) aren't a feature of ARM in general
(they are not present
on the Raspberry Pi for instance). The BeagleBone has 2 PRUs as you
describe. It uses the TI Siatra
ARM variant.
ARM just describes the core architecture. Manufacturers tack on all
sorts of
On Sat, Mar 22, 2014 at 4:16 PM, Brian Lloyd br...@lloyd.com wrote:
I bet you can come up with an NTP server and a GPSDO for not more than
$200.
I believe the Laureline largely meets the spec. It all open -- hardware
and software.
It's not gigE but it was suggested you could swap in a 1588
Thanks, Yes of course ARM refers only to ARM
Would you know which other systems include the PRUs? Is it only in
the TI products? It seems like an ideal solution to the problem of
non-deterministic latency.
This may not even be required. There is no point to extreme levels of
accuracy
On Sat, Mar 22, 2014 at 3:53 PM, Chris Albertson
albertson.ch...@gmail.comwrote:
Thanks, Yes of course ARM refers only to ARM
Would you know which other systems include the PRUs? Is it only in
the TI products? It seems like an ideal solution to the problem of
non-deterministic latency.
albertson.ch...@gmail.com said:
Would you know which other systems include the PRUs? Is it only in the TI
products? It seems like an ideal solution to the problem of
non-deterministic latency.
There is a much simpler solution - avoid the latency by using a counter/timer
to capture the
The main problem for NIST or USNO's servers is not the actual time
transfer into the machine -- that is a solved problem, but rather
getting enough packets spit out precisely enough, with the required
signature to make it traceable.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
On Sat, Mar 22, 2014 at 2:25 PM, Brian Lloyd br...@lloyd.com wrote:
NTP running in broadcast mode over a local Gig-E network shouldn't be too
bad. I suspect timing jitter is pretty low.
Gigabit Ethernet can be actually worse than 100BaseT because of the
way the hardware works. The packets
The PRU on the BeagleBone each include an enhanced capture module that
can be used as you describe.
It has a 32 bit timer that is latched into one of the capture
registers. The timers are independent of
the timer used by the Linux system so I'm not sure how you would tie
them into use with
In message 532e1620.9080...@tuffmail.us, Mike George writes:
The PRU on the BeagleBone each include an enhanced capture module that
can be used as you describe.
I belive there is also some magic in the ethernet controller, but
I have yet to study it carefully.
--
Poul-Henning Kamp |
PRU appears to be unique to TI.
I have only used Raspberry Pi, Beaglebone, and Cubieboard.
The Cubieboard (Allwinner CPU) has a lot of IO pins like the
Beaglebone but nothing like a PRU.
Mike George
On 3/22/2014 16:53, Chris Albertson wrote:
Thanks, Yes of course ARM refers only to ARM
On Sat, Mar 22, 2014 at 6:55 PM, Chris Albertson
albertson.ch...@gmail.comwrote:
But as I wrote before if you are on a local network and are willing to
buy special PTP compatible hardware you can use PTP and avoid NTP.
PTP relies on external time stamps put on but the network hardware and
is
I would, but I don't have the time at the moment :)
Didier KO4BB
On March 19, 2014 12:18:23 AM CDT, Tom Van Baak t...@leapsecond.com wrote:
If you can design a system that can handle 6.5 billion requests per
day, this opportunity is for you...
On 3/18/14 10:18 PM, Tom Van Baak wrote:
If you can design a system that can handle 6.5 billion requests per day, this
opportunity is for you...
https://www.fbo.gov/spg/DOC/NIST/AcAsD/RFI_InternetTimeServiceComments/listing.html
Solicitation Number: RFI_InternetTimeServiceComments
For
So they want to in-invent NTP?
I think NTP already services way more than 6.5 billion per day. The
problem with NTP is while it is nearly optimal and provides the best
time accuracy for a given hardware/network setup it is not technically
traceable even if the time really is from NIST
40 matches
Mail list logo
