On 2014-03-27, Joe Gwinn joegw...@comcast.net wrote:
Well, it worked, at least partially. One group backed off to the point
of depending on PTP for few microsecond sync error, versus a few tens
to a hundred nanoseconds. This should work.
It sounded and sounds like they really had no idea
In article lh1kir$vie$1...@dont-email.me, William Unruh
un...@invalid.ca wrote:
On 2014-03-27, Joe Gwinn joegw...@comcast.net wrote:
Well, it worked, at least partially. One group backed off to the point
of depending on PTP for few microsecond sync error, versus a few tens
to a hundred
Well, it worked, at least partially. One group backed off to the point
of depending on PTP for few microsecond sync error, versus a few tens
to a hundred nanoseconds. This should work.
As for the sub-microsecond sync error, maybe someday.
For the other group, the hope probably still lives.
E-Mail Sent to this address will be added to the BlackLists schrieb:
Martin Burnicki wrote:
Magnus Danielson wrote:
Indeed. If you read the right article from 1990 you
also know you can do it on L1 C/A only by monitoring
both code and carrier phase, as their ionospheric
effect have
Magnus,
In article 532e42c8.6080...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
Joe,
On 21/03/14 16:17, Joe Gwinn wrote:
Magnus,
Thus, another fairly severe environment.
I have a personal war story from 1992: At a Air Traffic Control center
in Canada,
Joe,
On 21/03/14 16:17, Joe Gwinn wrote:
Magnus,
Thus, another fairly severe environment.
I have a personal war story from 1992: At a Air Traffic Control center
in Canada, one 19 cabinet had the green (safety ground) and white
(power neutral) cables transposed. This caused 2.3 Vrms at 180
Magnus,
In article 532b5621.1040...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
Hi Joe,
On 20/03/14 01:53, Joe Gwinn wrote:
In article 5328ad2...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 18/03/14 01:24, Joe Gwinn wrote:
Hal Murray wrote:
In article 53298269.6000...@systematicsw.ab.ca,
Brian Inglis brian.ing...@systematicsw.ab.ca writes:
Something like a Thunderbolt GPSDO feeding data, PPS, and 10MHz clock to a
chip executing instructions at some clock multiple and handling interrupts
in a deterministic time
In article yvqdnqukc7qjb7fonz2dnuvz_vudn...@megapath.net, Hal Murray
hal-use...@ip-64-139-1-69.sjc.megapath.net wrote:
In article 190320142025178186%joegw...@comcast.net,
Joe Gwinn joegw...@comcast.net writes:
The original issue was to be able to drop IRIG support in honor of PTP
via the
Paul tik-...@bodosom.net wrote:
Sure. My point is I haven't seen a use case in this thread for nanosecond
*accuracy* relative to the TAI paper clock.
It is not for timestamping the moment of clicking in an online auction
or stock trade? Those people normally have infinite timestamping
On 2014-03-20, Rob nom...@example.com wrote:
Paul tik-...@bodosom.net wrote:
Sure. My point is I haven't seen a use case in this thread for nanosecond
*accuracy* relative to the TAI paper clock.
It is not for timestamping the moment of clicking in an online auction
or stock trade? Those
On 19/03/14 10:43, Martin Burnicki wrote:
Magnus Danielson wrote:
On 18/03/14 10:17, Martin Burnicki wrote:
We have mades some tests and found that NTP can yield the same accuracy
as NTP if also hardware timestamping of NTP packets is supported on all
nodes, similar as for PTP.
In fact this
On 19/03/14 10:50, Miroslav Lichvar wrote:
On Tue, Mar 18, 2014 at 10:20:08PM +0100, Magnus Danielson wrote:
No, it's not. NTP is being perceived to be software timestamping
but nothing prohibits you from doing it in hardware. Similarly can
you implement PTP with software time-stamping (with
On Thu, Mar 20, 2014 at 1:35 PM, Rob nom...@example.com wrote:
Paul tik-...@bodosom.net wrote:
Sure. My point is I haven't seen a use case in this thread for
nanosecond
*accuracy* relative to the TAI paper clock.
It is not for timestamping the moment of clicking in an online auction
or
On 19/03/14 18:51, E-Mail Sent to this address will be added to the
BlackLists wrote:
Martin Burnicki wrote:
Magnus Danielson wrote:
Indeed. If you read the right article from 1990 you
also know you can do it on L1 C/A only by monitoring
both code and carrier phase, as their ionospheric
Hi Joe,
On 20/03/14 01:53, Joe Gwinn wrote:
In article 5328ad2...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 18/03/14 01:24, Joe Gwinn wrote:
I've used IRIG-B004 DCLS before, for cables two meters long within a
cabinet. Worked well. How well do they handle
William Unruh wrote:
On 2014-03-18, Martin Burnicki martin.burni...@meinberg.de wrote:
Magnus Danielson wrote:
On 17/03/14 09:48, Martin Burnicki wrote:
You'd need hardware (FPGA?) which can be clocked at 1 GHz, and even in
the hardware signal processing you'd need to account for a number of
Magnus Danielson wrote:
On 18/03/14 10:17, Martin Burnicki wrote:
We have mades some tests and found that NTP can yield the same accuracy
as NTP if also hardware timestamping of NTP packets is supported on all
nodes, similar as for PTP.
In fact this isn't surprising, is it?
No, it's not. NTP
E-Mail Sent to this address will be added to the BlackLists wrote:
Why not just NTP with a PTP RefClock Driver?
People Already Run ( sell) Appliances that are both
PTP NTP servers {which doesn't seem like it should be too hard};
I know. We at Meinberg are selling such appliances. ;-)
On 2014-03-19 03:30, Martin Burnicki wrote:
Brian Inglis wrote:
On 2014-03-18 02:59, Martin Burnicki wrote:
All depends on how accurate and precise you can get your timestamps,
and this
is probably easier with network packet timestampers at both sides of a
cable
than with a wireless time
Brian Inglis wrote:
Martin Burnicki wrote:
At the single nanosecond accuracy level it would also be
important to *which* local realizations UTC(k) you are referring,
UTC(NIST), UTC(USNO), UTC(PTB), ...
The source would need to provided by or calibrated against the ref,
at some cost!
On 2014-03-19 12:01, E-Mail Sent to this address will be added to the
BlackLists wrote:
Brian Inglis wrote:
Martin Burnicki wrote:
At the single nanosecond accuracy level it would also be
important to *which* local realizations UTC(k) you are referring,
UTC(NIST), UTC(USNO), UTC(PTB), ...
On Wed, Mar 19, 2014 at 6:16 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
Each constellation has its own epoch, TAI or UTC time scale, and
uncertainty:
I'm unclear how various time scales relate to PTP. It would appear that
the design intent is local (LAN) process control. And
On 2014-03-19 16:32, Paul wrote:
On Wed, Mar 19, 2014 at 6:16 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
Each constellation has its own epoch, TAI or UTC time scale, and
uncertainty:
I'm unclear how various time scales relate to PTP. It would appear that
the design intent is
On Wed, Mar 19, 2014 at 7:04 PM, Brian Inglis
brian.ing...@systematicsw.ab.ca wrote:
While 1ns precision may be doable, accuracy depends on what
controls the GM, and its traceability to a reference.
Sure. My point is I haven't seen a use case in this thread for nanosecond
*accuracy*
In article i3glva-5vm@ubuntu-server-1.py.meinberg.de, Martin
Burnicki martin.burni...@meinberg.de wrote:
Joe Gwinn wrote:
I've used IRIG-B004 DCLS before, for cables two meters long within a
cabinet. Worked well. How well do they handle 100 meter cables, in
areas where the concept of
In article 5328ad2...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 18/03/14 01:24, Joe Gwinn wrote:
In article 532778bf.50...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 17/03/14 13:50, Joe Gwinn wrote:
In article
Magnus Danielson wrote:
On 17/03/14 09:48, Martin Burnicki wrote:
You'd need hardware (FPGA?) which can be clocked at 1 GHz, and even in
the hardware signal processing you'd need to account for a number of
signal propagation delays which you can eventually ignore at lower clock
rates.
So of
Paul wrote:
On Mon, Mar 17, 2014 at 8:50 AM, Joe Gwinn joegw...@comcast.net wrote:
Yes. My question is basically a query about the current state of the
art.
Some NTP offsets (output may look funny if formatted) clock1 looking at
clock2 and clock3 (a Raspberry Pi). This suggests it can be
Paul wrote:
On Mon, Mar 17, 2014 at 8:07 PM, Joe Gwinn joegw...@comcast.net wrote:
People are also lusting after sub-microsecond sync.
Sure but not optimally in comp.protocols.ntp/questions@lists.ntp.org.
With some help NTP can be quite good but the intent really isn't nanosecond
accuracy.
On Tue, Mar 18, 2014 at 5:14 AM, Martin Burnicki
martin.burni...@meinberg.de wrote:
But without additional measurements you still don't know for sure if this
is the true time offset, or if there is an additional systematic time
offset (e.g. to an asymmetric network connection) which can't be
On 2014-03-18, Martin Burnicki martin.burni...@meinberg.de wrote:
Magnus Danielson wrote:
On 17/03/14 09:48, Martin Burnicki wrote:
You'd need hardware (FPGA?) which can be clocked at 1 GHz, and even in
the hardware signal processing you'd need to account for a number of
signal propagation
On 2014-03-18 02:59, Martin Burnicki wrote:
All depends on how accurate and precise you can get your timestamps, and this
is probably easier with network packet timestampers at both sides of a cable
than with a wireless time transfer method like GPS which usually suffers from
delays which can't
On 18/03/14 01:24, Joe Gwinn wrote:
In article 532778bf.50...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 17/03/14 13:50, Joe Gwinn wrote:
In article lg61s4$ong$3...@dont-email.me, William Unruh
un...@invalid.ca wrote:
On 2014-03-16, Joe Gwinn
On 18/03/14 02:45, Paul wrote:
On Mon, Mar 17, 2014 at 9:33 PM, Joseph Gwinn joegw...@comcast.net wrote:
Will it do 100 meters or more, in bad neighborhoods?
I'm not the right person to ask but since it is expected to maintain
between 2.5 and 100 nanosecond sync with CPE nodes (cable
On 18/03/14 09:59, Martin Burnicki wrote:
Magnus Danielson wrote:
On 17/03/14 09:48, Martin Burnicki wrote:
You'd need hardware (FPGA?) which can be clocked at 1 GHz, and even in
the hardware signal processing you'd need to account for a number of
signal propagation delays which you can
On 18/03/14 10:17, Martin Burnicki wrote:
Paul wrote:
On Mon, Mar 17, 2014 at 8:07 PM, Joe Gwinn joegw...@comcast.net wrote:
People are also lusting after sub-microsecond sync.
Sure but not optimally in comp.protocols.ntp/questions@lists.ntp.org.
With some help NTP can be quite good but
Magnus Danielson wrote: Martin Burnicki wrote:
We have mades some tests and found that NTP can yield the
same accuracy as NTP if also hardware timestamping of NTP
packets is supported on all nodes, similar as for PTP.
In fact this isn't surprising, is it?
No, it's not. NTP is being
On 2014-03-16, Joe Gwinn joegw...@comcast.net wrote:
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achieve sub-microsecond to nanosecond-level synchronization over
ethernet (with the right hardware to be sure).
I've been reading IEEE 1588-2008, and they do talk of one
William Unruh wrote:
On 2014-03-16, Joe Gwinn joegw...@comcast.net wrote:
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achieve sub-microsecond to nanosecond-level synchronization over
ethernet (with the right hardware to be sure).
I've been reading IEEE 1588-2008, and
In article lg61s4$ong$3...@dont-email.me, William Unruh
un...@invalid.ca wrote:
On 2014-03-16, Joe Gwinn joegw...@comcast.net wrote:
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achieve sub-microsecond to nanosecond-level synchronization over
ethernet (with the
On Mon, Mar 17, 2014 at 8:50 AM, Joe Gwinn joegw...@comcast.net wrote:
Yes. My question is basically a query about the current state of the
art.
Some NTP offsets (output may look funny if formatted) clock1 looking at
clock2 and clock3 (a Raspberry Pi). This suggests it can be as good as
On 2014-03-17, Martin Burnicki martin.burni...@meinberg.de wrote:
William Unruh wrote:
On 2014-03-16, Joe Gwinn joegw...@comcast.net wrote:
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achieve sub-microsecond to nanosecond-level synchronization over
ethernet (with
William Unruh wrote:
On 2014-03-17, Martin Burnicki martin.burni...@meinberg.de wrote:
If you have a counter chain clocked by 20 MHz then the timestamps
captured when PTP packets are going out or are coming in have a
resolution of 50 ns.
I am not saying that a computer or a piece of hardware
On Mon, 17 Mar 2014 08:50:08 -0400, Joe Gwinn wrote:
Yes. My question is basically a query about the current state of the
art.
In Cable headends they are using the DTI interface/protocol to sync
multiple boxes to within a few(5) ns.
/hjj
___
On 17/03/14 09:48, Martin Burnicki wrote:
William Unruh wrote:
On 2014-03-16, Joe Gwinn joegw...@comcast.net wrote:
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achieve sub-microsecond to nanosecond-level synchronization over
ethernet (with the right hardware to be
On 17/03/14 13:50, Joe Gwinn wrote:
In article lg61s4$ong$3...@dont-email.me, William Unruh
un...@invalid.ca wrote:
On 2014-03-16, Joe Gwinn joegw...@comcast.net wrote:
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achieve sub-microsecond to nanosecond-level
In article
cakyj6kanol-pbm8d+kfcoceya6yi0chwphwgalxab8gowcg...@mail.gmail.com,
Paul tik-...@bodosom.net wrote:
On Mon, Mar 17, 2014 at 8:50 AM, Joe Gwinn joegw...@comcast.net wrote:
Yes. My question is basically a query about the current state of the
art.
Some NTP offsets (output may
In article 532778bf.50...@rubidium.dyndns.org, Magnus Danielson
mag...@rubidium.dyndns.org wrote:
On 17/03/14 13:50, Joe Gwinn wrote:
In article lg61s4$ong$3...@dont-email.me, William Unruh
un...@invalid.ca wrote:
On 2014-03-16, Joe Gwinn joegw...@comcast.net wrote:
I keep seeing
On Mon, Mar 17, 2014 at 8:09 PM, Joe Gwinn joegw...@comcast.net wrote:
I'm not familiar with DTI.
Look for DOCSIS timing interface. The tight specs mentioned earlier are
over a backplane although the in-premises numbers are sub-microsecond.
___
Joe Gwinn wrote: But my question is about the state of the art in PTP systems,
not
systems in general.
(Shrug) I have Seven {About $500kUSD} AB GuardLogix Systems
using AB {ODVA} CIP Sync IEEE 1588-2008 standard for time synchronization.
It is not using any NTP, GPS, or IRIGB clock sources
On Mon, Mar 17, 2014 at 8:07 PM, Joe Gwinn joegw...@comcast.net wrote:
People are also lusting after sub-microsecond sync.
Sure but not optimally in comp.protocols.ntp/questions@lists.ntp.org.
With some help NTP can be quite good but the intent really isn't nanosecond
accuracy.
On Mon, Mar 17, 2014 at 9:33 PM, Joseph Gwinn joegw...@comcast.net wrote:
Will it do 100 meters or more, in bad neighborhoods?
I'm not the right person to ask but since it is expected to maintain
between 2.5 and 100 nanosecond sync with CPE nodes (cable modems) I assume
it requires RF
On 3/17/2014 6:37 PM, E-Mail Sent to this address will be added to the
BlackLists wrote:
Joe Gwinn wrote: Magnus Danielson wrote:
Joe Gwinn wrote:
Yes. My question is basically a query about the current state
of the art [in PTP].
The state of the art is not yet standard and not yet off
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achieve sub-microsecond to nanosecond-level synchronization over
ethernet (with the right hardware to be sure).
I've been reading IEEE 1588-2008, and they do talk of one nanosecond,
but that's the standard, and aspirational
55 matches
Mail list logo
