Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread William Unruh
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

Re: [ntp:questions] Asymmetric Delay and NTP

2014-03-17 Thread Terje Mathisen
Joe Gwinn wrote: I recall seeing something from Dr. Mills saying that a formal proof had been found showing that no packet-exchange protocol (like NTP) could tell delay asymmetry from clock offset. Can anyone provide a reference to this proof? This is similar to Einstein's relativity

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Martin Burnicki
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

Re: [ntp:questions] Time of by 4 min

2014-03-17 Thread Martin Burnicki
David Woolley wrote: Why would they treat it as a bug? Microsoft make money by selling server licences, so clients should be accessing their time from those servers. They provide software to run on those servers, to provide that time. One result of using reference ntpd is that you can use a

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Joe Gwinn
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

Re: [ntp:questions] Time to fix reported driver bug.

2014-03-17 Thread Paul
On Mon, Mar 17, 2014 at 12:01 AM, Danny Mayer ma...@ntp.org wrote: A patch WAS submitted for this though it was done inline instead of as an attachment I added a patch against p433 as an attachment. I recommend that you mark it as possibly blocking 4.2.8 How to do that isn't immediately

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Paul
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

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread William Unruh
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

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Terje Mathisen
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

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Hans Jørgen Jakobsen
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 ___

Re: [ntp:questions] Asymmetric Delay and NTP

2014-03-17 Thread Magnus Danielson
Joe, On 16/03/14 23:16, Joe Gwinn wrote: I recall seeing something from Dr. Mills saying that a formal proof had been found showing that no packet-exchange protocol (like NTP) could tell delay asymmetry from clock offset. Can anyone provide a reference to this proof? It's relative simple.

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Magnus Danielson
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

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Magnus Danielson
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

[ntp:questions] Martin Musatov serious

2014-03-17 Thread my
Promise of a Second Death Coming So you should come comfort me Jesus and say, Yes I was with you Abba and this has been a bittersweet heaven up until this point. We'll correct it after you die. I am sure you will come liking it again. Again be liking, come will you surety be I. Death you had

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Joe Gwinn
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

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Joe Gwinn
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

Re: [ntp:questions] Asymmetric Delay and NTP

2014-03-17 Thread Joe Gwinn
In article 5327757e.5040...@rubidium.dyndns.org, Magnus Danielson mag...@rubidium.dyndns.org wrote: Joe, On 16/03/14 23:16, Joe Gwinn wrote: I recall seeing something from Dr. Mills saying that a formal proof had been found showing that no packet-exchange protocol (like NTP) could tell

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Paul
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. ___

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread E-Mail Sent to this address will be added to the BlackLists
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

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Paul
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.

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread Paul
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

Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?

2014-03-17 Thread E-Mail Sent to this address will be added to the BlackLists
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