In article , William Unruh
wrote:
> On 2014-03-27, Joe Gwinn 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
On 2014-03-27, Joe Gwinn 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 what they needed an
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. I
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 opposi
Magnus,
In article <532e42c8.6080...@rubidium.dyndns.org>, Magnus Danielson
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, one 19"
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
wrote:
> Hi Joe,
>
> On 20/03/14 01:53, Joe Gwinn wrote:
> > In article <5328ad2...@rubidium.dyndns.org>, Magnus Danielson
> > wrote:
> >
> >> On 18/03/14 01:24, Joe Gwinn wrote:
> >>> I've used IRIG-B004 DCLS before,
Hi Joe,
On 20/03/14 01:53, Joe Gwinn wrote:
In article <5328ad2...@rubidium.dyndns.org>, Magnus Danielson
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 100 meter cables, in
areas
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
e
On Thu, Mar 20, 2014 at 1:35 PM, Rob wrote:
> Paul 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?
>
The original
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 s
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 is
On 2014-03-20, Rob wrote:
> Paul 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 ti
Paul 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
accuracy specs.
In article , Hal Murray
wrote:
> In article <190320142025178186%joegw...@comcast.net>,
> Joe Gwinn writes:
>
> >The original issue was to be able to drop IRIG support in honor of PTP
> >via the ethernet infrastructure we always need.
>
> How stable is your local clock?
These systems are ti
Hal Murray wrote:
In article <53298269.6000...@systematicsw.ab.ca>,
Brian Inglis 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 to feed the PTP GM?
Why use
In article <5328ad2...@rubidium.dyndns.org>, Magnus Danielson
wrote:
> On 18/03/14 01:24, Joe Gwinn wrote:
> > In article <532778bf.50...@rubidium.dyndns.org>, Magnus Danielson
> > wrote:
> >
> >> On 17/03/14 13:50, Joe Gwinn wrote:
> >>> In article , William Unruh
> >>> wrote:
> >>>
> On
In article , Martin
Burnicki 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 "ground" can be elusive?
>
>
> You could use fiber optics to tr
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* re
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 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. An
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), ...
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
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 opposite signs.
>
> That's interesting, and I didn't know about this
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 trans
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. ;-)
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
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 shitty
> performance).
>
> Doing HNTP ma
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 opposite signs.
That's interesting, and I didn't know about this.
Do you have a pointer to this article
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 transfer method like GPS which usually
suffers fro
William Unruh wrote:
On 2014-03-18, 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 wh
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
On 18/03/14 10:26, Martin Burnicki 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 "ground" can be elusive?
You could use fiber optics to transfer an IR
On 18/03/14 10:17, Martin Burnicki wrote:
Paul wrote:
On Mon, Mar 17, 2014 at 8:07 PM, Joe Gwinn 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
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 eventua
On 18/03/14 02:45, Paul wrote:
On Mon, Mar 17, 2014 at 9:33 PM, Joseph Gwinn 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 requir
On 18/03/14 01:24, Joe Gwinn wrote:
In article <532778bf.50...@rubidium.dyndns.org>, Magnus Danielson
wrote:
On 17/03/14 13:50, Joe Gwinn wrote:
In article , William Unruh
wrote:
On 2014-03-16, Joe Gwinn wrote:
I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
achiev
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 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 2014-03-18, 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 c
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
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 "ground" can be elusive?
You could use fiber optics to transfer an IRIG DCLS signal.
However, if you want highe
Paul wrote:
On Mon, Mar 17, 2014 at 8:50 AM, Joe Gwinn 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
your IRIG
Paul wrote:
On Mon, Mar 17, 2014 at 8:07 PM, Joe Gwinn 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.
We have mades some
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 cou
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
On Mon, Mar 17, 2014 at 9:33 PM, Joseph Gwinn 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 techniques not readily avai
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 the shelf
>> products, if you want to call it PTP.
>
> This is my fear and instin
On Mon, Mar 17, 2014 at 8:07 PM, Joe Gwinn 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.
___
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 source
On Mon, Mar 17, 2014 at 8:09 PM, Joe Gwinn 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.
___
questions mailing list
In article <532778bf.50...@rubidium.dyndns.org>, Magnus Danielson
wrote:
> On 17/03/14 13:50, Joe Gwinn wrote:
> > In article , William Unruh
> > wrote:
> >
> >> On 2014-03-16, Joe Gwinn wrote:
> >>> I keep seeing claims that Precision Time Protocol (IEEE 1588-2008) can
> >>> achieve sub-micros
In article , Hans Jørgen Jakobsen
wrote:
> 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.
I'm
In article
,
Paul wrote:
> On Mon, Mar 17, 2014 at 8:50 AM, Joe Gwinn 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
On 17/03/14 13:50, Joe Gwinn wrote:
In article , William Unruh
wrote:
On 2014-03-16, Joe Gwinn 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 b
On 17/03/14 09:48, Martin Burnicki wrote:
William Unruh wrote:
On 2014-03-16, Joe Gwinn 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 readi
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
___
quest
William Unruh wrote:
On 2014-03-17, Martin Burnicki 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 cannot have a 1
ns resoltuio
On 2014-03-17, Martin Burnicki wrote:
> William Unruh wrote:
>> On 2014-03-16, Joe Gwinn 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).
>>>
>>
On Mon, Mar 17, 2014 at 8:50 AM, Joe Gwinn 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
your IRIG system.
Gi
In article , William Unruh
wrote:
> On 2014-03-16, Joe Gwinn 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 15
William Unruh wrote:
On 2014-03-16, Joe Gwinn 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
On 2014-03-16, Joe Gwinn 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 nanosecond,
> b
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 pap
64 matches
Mail list logo
