Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.realtime > #248 > unrolled thread

Comparing phase of physically distant signals

Back to article view | Back to comp.realtime

Contents

  Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 00:45 -0700
    Re: Comparing phase of physically distant signals Jan Panteltje <pNaonStpealmtje@yahoo.com> - 2013-08-03 07:51 +0000
    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 09:58 +0100
      Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 13:21 +0300
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 12:16 +0100
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 11:56 -0700
          Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:17 +0100
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 13:41 -0700
              Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 22:46 +0100
                Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 14:57 -0700
                  Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 23:09 +0100
      Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 13:58 +0300
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 12:30 +0100
      Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 16:08 +0300
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 14:22 +0100
          Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-03 16:38 +0300
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 10:46 -0700
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 10:40 -0700
          Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:04 +0100
          Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 15:55 +0200
            Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-04 19:42 +0300
              Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 21:08 +0200
                Re: Comparing phase of physically distant signals upsidedown@downunder.com - 2013-08-05 15:28 +0300
                  Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-05 22:17 +0200
                    Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-05 23:20 -0400
      Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 14:26 +0100
      Re: Comparing phase of physically distant signals George Neuner <gneuner2@comcast.net> - 2013-08-03 14:47 -0400
    Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 08:17 -0700
      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:08 -0700
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:37 +0100
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:57 -0700
            Re: Comparing phase of physically distant signals Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-08-04 15:58 +0200
        Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 12:44 -0700
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 18:36 -0700
            Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-04 09:56 -0700
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 14:53 -0700
                Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-05 15:38 -0700
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 01:25 -0700
                    Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-07 08:06 -0700
                      Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-07 09:21 -0700
    Re: Comparing phase of physically distant signals josephkk <joseph_barrett@sbcglobal.net> - 2013-08-03 15:40 +0000
      Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 10:05 -0700
        Re: Comparing phase of physically distant signals John S <Sophi.2@invalid.org> - 2013-08-03 12:13 -0500
          Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 10:26 -0700
            Re: Comparing phase of physically distant signals John S <Sophi.2@invalid.org> - 2013-08-03 12:51 -0500
              Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 11:54 -0700
                Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-03 20:27 +0100
                  Re: Comparing phase of physically distant signals George Neuner <gneuner2@comcast.net> - 2013-08-05 03:26 -0400
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-05 10:34 +0100
                    Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-05 23:29 -0400
                      Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 08:53 +0100
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:49 -0700
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:34 -0700
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 12:18 -0700
          Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 12:52 -0700
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 13:21 -0700
              Re: Comparing phase of physically distant signals Jeff Liebermann <jeffl@cruzio.com> - 2013-08-03 13:31 -0700
                Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-03 14:46 -0700
                  Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 15:03 -0700
                  Re: Comparing phase of physically distant signals Jeff Liebermann <jeffl@cruzio.com> - 2013-08-03 17:25 -0700
              Re: Comparing phase of physically distant signals Joerg <invalid@invalid.invalid> - 2013-08-03 14:50 -0700
      Re: Comparing phase of physically distant signals "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-08-04 11:06 +0100
    Re: Comparing phase of physically distant signals John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> - 2013-08-03 11:47 -0700
    Re: Comparing phase of physically distant signals Richard Damon <Richard@Damon-Family.org> - 2013-08-03 18:23 -0400
    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-05 16:53 +0100
      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 13:19 -0700
        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 00:27 +0100
          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-05 20:09 -0700
            Re: Comparing phase of physically distant signals Paul Rubin <no.email@nospam.invalid> - 2013-08-05 22:12 -0700
              Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 09:12 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 01:47 -0700
                Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 10:08 +0100
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:25 -0700
                    Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:48 -0700
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 10:49 +0100
                      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 03:06 -0700
                        Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 11:57 +0100
                          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 10:28 -0700
                            Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 21:52 +0100
                              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 01:34 -0700
                                Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-07 09:46 +0100
                Re: Comparing phase of physically distant signals Les Cargill <lcargill99@comcast.com> - 2013-08-06 07:22 -0500
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 10:42 -0700
                    Re: Comparing phase of physically distant signals Les Cargill <lcargill99@comcast.com> - 2013-08-06 23:04 -0500
                      Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 23:50 -0700
                        Re: Comparing phase of physically distant signals Les Cargill <lcargill99@comcast.com> - 2013-08-07 13:05 -0500
                          Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 18:22 -0700
                            Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-08 09:35 +0100
                Re: Comparing phase of physically distant signals Paul Rubin <no.email@nospam.invalid> - 2013-08-06 22:18 -0700
                  Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-07 03:09 -0700
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-07 12:39 +0100
                    Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-07 13:18 +0100
            Re: Comparing phase of physically distant signals Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-08-06 09:23 +0100
              Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-06 02:02 -0700
            Re: Comparing phase of physically distant signals "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-08-06 09:49 +0100
    Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-16 21:07 +0100

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#335

On 07/08/13 09:34, Don Y wrote:
> On 8/6/2013 1:52 PM, Tom Gardner wrote:
>>> Still waiting for that refutation of the CERN system, Tom.
>>
>> That would require
>>   - my understanding the detail of what CERN was *and was not*
>>     assuming and doing
>
> It's a 15 page paper -- with lots of pictures!  But, perhaps
> you're a slow reader?

I'm a fast reader.

But *understanding* takes me longer, and understanding what *isn't*
being said (because it is implicit for those skilled in the art)
takes me *much* longer.

I think many of your comments imply the same is true for you too.

Whenever I've had a problem to be solved, the first thing
I've done is thorough research on how similar problems have
been successfully solved and/or avoided in the past.

[toc] | [prev] | [next] | [standalone]

#326

Don Y wrote:
> Hi Paul,
<snip>
>
> Likewise, tell the folks at Cisco, Juniper, etc. that this is
> a fool's goal before their stockholders discover they've spent
> all that NRE money developing REAL PRODUCTS that implement these
> *impossible* PTP mechanisms!!  There's NO MARKET FOR THEM!!!
> You *can't* synchronize time over a distance!!  (or, so I'm told)
>
> (Really??!)
>

Presumably, these folks *can* tell whether it works or not in the
context of several big piles o' gear. If there is no
aggregate measure available to estimate the delta-entropy from
*not* having this capability, then there's no way to estimate the gain
from it in the first place.

And if you don't think those folks don't tilt at the odd windmill...

Meanwhile, the audio signal on most cable systems is quite 
un-synchronized from the picture.

> To play Tom's card:  find the references.  Read them.  UNDERSTAND
> THEM.  *Then*, come back and point out the FLAWS in their
> implementations!  (because you obviously are not convinced that
> *I* have already done this!)  Unless you can point out why
> 1588 *can't* work or why White Rabbit is pure fantasy, you
> won't be able to offer me any useful comment on the problem
> I'm addressing (because I *see* 1588 working in front of my eyes
> so regard comments that it "can't work" as in sharp contrast
> with "reality")
>

Can't you use a GPS (or four) to provide a reference? Isn't 1588
just a way to provide GPS-like services without the GPS?

> Again, to be specific:  tell me how I can verify/measure the
> time relationship between those two pulse outputs WHEN THEY ARE
> ACTUALLY SEPARATED BY HUNDREDS OF FEET.
>
> --don

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#328

Hi Les,

On 8/6/2013 5:22 AM, Les Cargill wrote:
> Don Y wrote:
>
>> Likewise, tell the folks at Cisco, Juniper, etc. that this is
>> a fool's goal before their stockholders discover they've spent
>> all that NRE money developing REAL PRODUCTS that implement these
>> *impossible* PTP mechanisms!!  There's NO MARKET FOR THEM!!!
>> You *can't* synchronize time over a distance!!  (or, so I'm told)
>>
>> (Really??!)
>
> Presumably, these folks *can* tell whether it works or not in the
> context of several big piles o' gear. If there is no
> aggregate measure available to estimate the delta-entropy from
> *not* having this capability, then there's no way to estimate the gain
> from it in the first place.
>
> And if you don't think those folks don't tilt at the odd windmill...

Them, silicon manufacturers, standard developers, other entire
*industries*?  They're *all* smoking something??

> Meanwhile, the audio signal on most cable systems is quite
> un-synchronized from the picture.

And you like that and would like to see even more variability
added to it?  What about when you have a live audio+video feed?
("Hey, let's NOT take any precautions to ensure they remain
synchronized...")

>> To play Tom's card:  find the references.  Read them.  UNDERSTAND
>> THEM.  *Then*, come back and point out the FLAWS in their
>> implementations!  (because you obviously are not convinced that
>> *I* have already done this!)  Unless you can point out why
>> 1588 *can't* work or why White Rabbit is pure fantasy, you
>> won't be able to offer me any useful comment on the problem
>> I'm addressing (because I *see* 1588 working in front of my eyes
>> so regard comments that it "can't work" as in sharp contrast
>> with "reality")
>
> Can't you use a GPS (or four) to provide a reference? Isn't 1588
> just a way to provide GPS-like services without the GPS?

You only need a GPS in your *deployed* system if you want to
synchronize precisely *to* "GPS time".  If, instead, what you
want is "consistent, synchronous 'time' WITHIN your system",
then why incur the cost of a GPS-based GrandMaster Clock?

I.e., if you don't mind that all the "clocks" in your home are
"off" from your neighbors *BUT* are all consistent with each
other (i.e., the clock in the kitchen shows the same time as
the clock in your bedroom), then as long as they stay synchronized,
you can live with that discrepancy (until your neighbor invites
you to dinner and wonders why you are early/late arriving!  :> )
Your neighbor's house is *outside* your "system" and, presumably,
of no concern to you.

Without 1588 (et il.), then you would *need* something like
a GPS at each node to provide a reference time that each node
could consult *knowing* it was synchronized to the other nodes.
(the functionality of each of these nodes would then be conditional
on being able to get a GPS signal *at* that node -- not at an
"antenna location" some distance away from it)

[This is the same problem that I have with the idea of using
GPS receivers as "test equipment" in this sort of application]

I.e., 1588 addresses a real issue in real systems in the real
world.  Look at what the CERN folks have been playing with
to see how far folks are willing to push this idea.  Then,
think of how you would do what they want to do *without*
this notion of "synchronized time".

>> Again, to be specific:  tell me how I can verify/measure the
>> time relationship between those two pulse outputs WHEN THEY ARE
>> ACTUALLY SEPARATED BY HUNDREDS OF FEET.

Doctor's appointment...  (sigh)

--don

[toc] | [prev] | [next] | [standalone]

#330

Don Y wrote:
> Hi Les,
>
> On 8/6/2013 5:22 AM, Les Cargill wrote:
>> Don Y wrote:
>>
>>> Likewise, tell the folks at Cisco, Juniper, etc. that this is
>>> a fool's goal before their stockholders discover they've spent
>>> all that NRE money developing REAL PRODUCTS that implement these
>>> *impossible* PTP mechanisms!!  There's NO MARKET FOR THEM!!!
>>> You *can't* synchronize time over a distance!!  (or, so I'm told)
>>>
>>> (Really??!)
>>
>> Presumably, these folks *can* tell whether it works or not in the
>> context of several big piles o' gear. If there is no
>> aggregate measure available to estimate the delta-entropy from
>> *not* having this capability, then there's no way to estimate the gain
>> from it in the first place.
>>
>> And if you don't think those folks don't tilt at the odd windmill...
>
> Them, silicon manufacturers, standard developers, other entire
> *industries*?  They're *all* smoking something??
>

Absolutely. Not always, but things happen. To be clear - I don't
think 1588 is bogus, but let's just say I'm skeptical. It's nearly
certainly not a magic bullet that erases entropy. It may move
it around.

>> Meanwhile, the audio signal on most cable systems is quite
>> un-synchronized from the picture.
>
> And you like that and would like to see even more variability
> added to it?  What about when you have a live audio+video feed?
> ("Hey, let's NOT take any precautions to ensure they remain
> synchronized...")
>

I am saying that they don't (or can't) necessarily bother in a 
consistent manner.

>>> To play Tom's card:  find the references.  Read them.  UNDERSTAND
>>> THEM.  *Then*, come back and point out the FLAWS in their
>>> implementations!  (because you obviously are not convinced that
>>> *I* have already done this!)  Unless you can point out why
>>> 1588 *can't* work or why White Rabbit is pure fantasy, you
>>> won't be able to offer me any useful comment on the problem
>>> I'm addressing (because I *see* 1588 working in front of my eyes
>>> so regard comments that it "can't work" as in sharp contrast
>>> with "reality")
>>
>> Can't you use a GPS (or four) to provide a reference? Isn't 1588
>> just a way to provide GPS-like services without the GPS?
>
> You only need a GPS in your *deployed* system if you want to
> synchronize precisely *to* "GPS time".  If, instead, what you
> want is "consistent, synchronous 'time' WITHIN your system",
> then why incur the cost of a GPS-based GrandMaster Clock?
>

I am saying use a GPS as part of your deployed system as  a device under 
test. Test it locally with <n> GPS units to make sure it works,
then separate them.

You can't do this on all nodes not equipped with the time reference.

> I.e., if you don't mind that all the "clocks" in your home are
> "off" from your neighbors *BUT* are all consistent with each
> other (i.e., the clock in the kitchen shows the same time as
> the clock in your bedroom), then as long as they stay synchronized,
> you can live with that discrepancy (until your neighbor invites
> you to dinner and wonders why you are early/late arriving!  :> )
> Your neighbor's house is *outside* your "system" and, presumably,
> of no concern to you.
>
> Without 1588 (et il.), then you would *need* something like
> a GPS at each node to provide a reference time that each node
> could consult *knowing* it was synchronized to the other nodes.

Right.

> (the functionality of each of these nodes would then be conditional
> on being able to get a GPS signal *at* that node -- not at an
> "antenna location" some distance away from it)
>
> [This is the same problem that I have with the idea of using
> GPS receivers as "test equipment" in this sort of application]
>
> I.e., 1588 addresses a real issue in real systems in the real
> world.  Look at what the CERN folks have been playing with
> to see how far folks are willing to push this idea.  Then,
> think of how you would do what they want to do *without*
> this notion of "synchronized time".
>

I don't really know. The stuff I have worked on does
not need it, generally. The handful of times we did need it,
we were able to add aggregate measures ( usually related to BER )
to various things to estimate clock quality.

>>> Again, to be specific:  tell me how I can verify/measure the
>>> time relationship between those two pulse outputs WHEN THEY ARE
>>> ACTUALLY SEPARATED BY HUNDREDS OF FEET.
>
> Doctor's appointment...  (sigh)
>
> --don

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#332

Hi Les,

On 8/6/2013 9:04 PM, Les Cargill wrote:
> Don Y wrote:
>>>> Likewise, tell the folks at Cisco, Juniper, etc. that this is
>>>> a fool's goal before their stockholders discover they've spent
>>>> all that NRE money developing REAL PRODUCTS that implement these
>>>> *impossible* PTP mechanisms!!  There's NO MARKET FOR THEM!!!
>>>> You *can't* synchronize time over a distance!!  (or, so I'm told)
>>>>
>>>> (Really??!)
>>>
>>> Presumably, these folks *can* tell whether it works or not in the
>>> context of several big piles o' gear. If there is no
>>> aggregate measure available to estimate the delta-entropy from
>>> *not* having this capability, then there's no way to estimate the gain
>>> from it in the first place.
>>>
>>> And if you don't think those folks don't tilt at the odd windmill...
>>
>> Them, silicon manufacturers, standard developers, other entire
>> *industries*?  They're *all* smoking something??
>
> Absolutely. Not always, but things happen. To be clear - I don't
> think 1588 is bogus, but let's just say I'm skeptical. It's nearly
> certainly not a magic bullet that erases entropy. It may move
> it around.

I just don't believe all this energy (silicon developers, standards
developers, switch manufacturers, application industry experts, etc.)
is all smoke and mirrors.

And, when *I* can see 200ns with *my* 'scope that I refuse to believe
has been tampered with by some "black ops" guys in the middle of the
night...

Finally, when you look at the theory (of the various different
schemes that address this issue), there's nothing glaringly wrong.
I.e., everything "mechanically" in the signal path is deterministic
in nature (software, NIC, switch, etc.).  The only source of
randomness comes with the introduction of the switch -- competing
traffic vying for its resources.

If you put a pair of PTP-enabled NIC's back-to-back with a crossover
cable, you'd have no problem believing that they could compensate
for the transport delay in that cable of uncalibrated length.  Right?
(within the realm of clock jitter).

So, you introduce boundary or transparent switches that compensate
for the temporal variance *across* the switch ("store and forward")
and you've effectively put a "dual ported" PTP-enabled device
between the devices connected to the switch.  I.e., each link
from switch is now temporally deterministic and the "bit in the
middle" enforces that relationship as packets transit across it.

Yeah, a deployed 1588 system could spontaneously fail.  *Every*
control packet could mysteriously/coincidentally be corrupted
until the local oscillators drift out of lock.  It's also possible
that a cow could nibble on the power cord to the grandmaster clock...

(i.e., all systems are probabilistic at some level)

>>> Meanwhile, the audio signal on most cable systems is quite
>>> un-synchronized from the picture.
>>
>> And you like that and would like to see even more variability
>> added to it?  What about when you have a live audio+video feed?
>> ("Hey, let's NOT take any precautions to ensure they remain
>> synchronized...")
>
> I am saying that they don't (or can't) necessarily bother in a
> consistent manner.

Perhaps because its unimportant to them -- because consumers
will tolerate this level of wander between the audio and video.

Note, however, that there is a (evolving?) standard regarding
the use of 1588 for A/V applications.  Obviously someone in that
industry sees the need and has bought into the "smoke and mirrors" (?)

>>>> To play Tom's card:  find the references.  Read them.  UNDERSTAND
>>>> THEM.  *Then*, come back and point out the FLAWS in their
>>>> implementations!  (because you obviously are not convinced that
>>>> *I* have already done this!)  Unless you can point out why
>>>> 1588 *can't* work or why White Rabbit is pure fantasy, you
>>>> won't be able to offer me any useful comment on the problem
>>>> I'm addressing (because I *see* 1588 working in front of my eyes
>>>> so regard comments that it "can't work" as in sharp contrast
>>>> with "reality")
>>>
>>> Can't you use a GPS (or four) to provide a reference? Isn't 1588
>>> just a way to provide GPS-like services without the GPS?
>>
>> You only need a GPS in your *deployed* system if you want to
>> synchronize precisely *to* "GPS time".  If, instead, what you
>> want is "consistent, synchronous 'time' WITHIN your system",
>> then why incur the cost of a GPS-based GrandMaster Clock?
>
> I am saying use a GPS as part of your deployed system as  a device under
> test. Test it locally with <n> GPS units to make sure it works,
> then separate them.

I can test <n> units locally (on a bench) without the need for a GPS.
E.g., use a 'scope.

That;s what I did during development.  Then challenged the system:
- withdrawing processor resources to verify the timing daemon
   continued to operate even as the system is stressed beyond 100%
- heating one device while cooling another (force XO's to move in
   different directions)
- intercepting control packets for the timing service to verify
   how it copes with "loss of signal" over different time intervals
- corrupting control packets to verify they can't corrupt the
   timing service
- shutting down a node and verifying the system notes this loss of sync
- powering up a node to determine how quickly it syncs to the timing
   reference
etc.

So, I've assured myself that the algorithms and implementation are
correct.  I don't need reassurance that when I move those nodes
apart from each other that they are *still* exhibiting the same
degree of synchronization.

But, what do you do when there are 1,200 such devices deployed in
a hospital setting?  Drag any suspected devices (1?  2?  500?)
into the conference room and setup a 'scope to verify they are
operating properly?  Does the act of removing them from their
deployed locations affect their (mis)performance?

Much better if a technician ("on staff") can just use standard
techniques to troubleshoot the system in situ -- they're already
on site and have "test equipment" to service the instruments
in use on the premises!

> You can't do this on all nodes not equipped with the time reference.
>
>> I.e., if you don't mind that all the "clocks" in your home are
>> "off" from your neighbors *BUT* are all consistent with each
>> other (i.e., the clock in the kitchen shows the same time as
>> the clock in your bedroom), then as long as they stay synchronized,
>> you can live with that discrepancy (until your neighbor invites
>> you to dinner and wonders why you are early/late arriving!  :> )
>> Your neighbor's house is *outside* your "system" and, presumably,
>> of no concern to you.
>>
>> Without 1588 (et il.), then you would *need* something like
>> a GPS at each node to provide a reference time that each node
>> could consult *knowing* it was synchronized to the other nodes.
>
> Right.

This gets expensive (the appeal of lots of *cheap* SoC's/SBC's).
And, limits where you can deploy the nodes.

>> I.e., 1588 addresses a real issue in real systems in the real
>> world.  Look at what the CERN folks have been playing with
>> to see how far folks are willing to push this idea.  Then,
>> think of how you would do what they want to do *without*
>> this notion of "synchronized time".
>
> I don't really know. The stuff I have worked on does
> not need it, generally. The handful of times we did need it,
> we were able to add aggregate measures ( usually related to BER )
> to various things to estimate clock quality

In my case, I've more often had to deal with external "reference"
events/signals than not.  So, the idea of syntonous and synchronous
servos pervades many of my control algorithms.  E.g., sampling
a capacitive sensor array syntonous with the *instantaneous* AC line
frequency to null out AC line noise coupled from nearby flesh, etc.

In your case, you still need some way to establish a reference -- even
if you try to control accuracy and drift.  And then have to consider
the period of time over which your assumptions will remain valid.

We have no problem dealing with the idea that wall clocks are
synchronized (by imperfect human beings) "roughly" (surely
within 15-20 minutes of each other -- even accounting for
those folks who set their clocks "fast") across the country.
Or, within a few minutes within a single residence.  That
"computers" can be synchronized to a handful of milliseconds
globally.  I.e., it *is* possible to synchronize timepieces.  The
degree to which we want that synchronization varies -- along with
the cost we are willing to bear for it.

How would the CERN folks deploy instrumentation over many kilometers
to collect and control an accelerator if they *couldn't* distribute
a sense of time and provide for *local* (distributed) use of that?
Should they run thousands of multi-kilometer long cables for each
sensor/actuator terminated in a single location (to avail themselves
of a *single* "clock")?  Then, determine the propagation delay of each
cable so they can adjust the "centrally recorded time" of a particular
observation to reflect its transit delay?  *Anticipate* (by the transit
delay to an actuator) when an actuator should be fired to ensure that
the actual "activation signal" is emitted early enough to arrive at
that actuator exactly when needed?

Wouldn't it be *so* much easier to put local intelligence/signal
conditioning/control along that multi-kilometer path and preload
commands with predetermined times RELATIVE TO THE START TIME OF
THE EXPERIMENT?  Just *rely* on having a stable, shared "time
reference" (in terms of "frequency" and "phase") that reduces
the problem of each of those nodes to something easily managed?

It seems incredibly obvious to me that 1588 (et il.) are the way
things will be done in the future.  Folks will just pick what
degree of (time) control and resolution they are willing to
"purchase" in their designs.  Akin to tolerances on electronic
components (e.g., resistors, capacitors, *crystals*...)

Of course, there will still be apps that fit in a single processor
but I think more and more will "distribute" themselves to take
advantage of these economies.
--don

[toc] | [prev] | [next] | [standalone]

#341

Don Y wrote:
> Hi Les,
>
> On 8/6/2013 9:04 PM, Les Cargill wrote:
>> Don Y wrote:
>>>>> Likewise, tell the folks at Cisco, Juniper, etc. that this is
>>>>> a fool's goal before their stockholders discover they've spent
>>>>> all that NRE money developing REAL PRODUCTS that implement these
>>>>> *impossible* PTP mechanisms!!  There's NO MARKET FOR THEM!!!
>>>>> You *can't* synchronize time over a distance!!  (or, so I'm told)
>>>>>
>>>>> (Really??!)
>>>>
>>>> Presumably, these folks *can* tell whether it works or not in the
>>>> context of several big piles o' gear. If there is no
>>>> aggregate measure available to estimate the delta-entropy from
>>>> *not* having this capability, then there's no way to estimate the gain
>>>> from it in the first place.
>>>>
>>>> And if you don't think those folks don't tilt at the odd windmill...
>>>
>>> Them, silicon manufacturers, standard developers, other entire
>>> *industries*?  They're *all* smoking something??
>>
>> Absolutely. Not always, but things happen. To be clear - I don't
>> think 1588 is bogus, but let's just say I'm skeptical. It's nearly
>> certainly not a magic bullet that erases entropy. It may move
>> it around.
>
> I just don't believe all this energy (silicon developers, standards
> developers, switch manufacturers, application industry experts, etc.)
> is all smoke and mirrors.
>

I did not say *all*. I said it happens.

> And, when *I* can see 200ns with *my* 'scope that I refuse to believe
> has been tampered with by some "black ops" guys in the middle of the
> night...
>

I don't know what you mean by that. All I am trying to get to you
is that there is almost certainly a way to close the timing loop for
test purposes.

> Finally, when you look at the theory (of the various different
> schemes that address this issue), there's nothing glaringly wrong.
> I.e., everything "mechanically" in the signal path is deterministic
> in nature (software, NIC, switch, etc.).

Oh dear. No - *NEARLY NOTHING* in that path is purely deterministic to 
any significant resolution.

> The only source of
> randomness comes with the introduction of the switch -- competing
> traffic vying for its resources.
>

Maybe. It all depends on the switch.

> If you put a pair of PTP-enabled NIC's back-to-back with a crossover
> cable, you'd have no problem believing that they could compensate
> for the transport delay in that cable of uncalibrated length.  Right?
> (within the realm of clock jitter).
>


Try it. Spend some time with it. I can tell you, but you'll
select different hardware or a slightly different O/S and it'll
be different.

If you need uncertainty of < 1ms, you really need
to do something else.

> So, you introduce boundary or transparent switches that compensate
> for the temporal variance *across* the switch ("store and forward")
> and you've effectively put a "dual ported" PTP-enabled device
> between the devices connected to the switch.  I.e., each link
> from switch is now temporally deterministic and the "bit in the
> middle" enforces that relationship as packets transit across it.
>
> Yeah, a deployed 1588 system could spontaneously fail.  *Every*
> control packet could mysteriously/coincidentally be corrupted
> until the local oscillators drift out of lock.  It's also possible
> that a cow could nibble on the power cord to the grandmaster clock...
>
> (i.e., all systems are probabilistic at some level)
>

Right.

>>>> Meanwhile, the audio signal on most cable systems is quite
>>>> un-synchronized from the picture.
>>>
>>> And you like that and would like to see even more variability
>>> added to it?  What about when you have a live audio+video feed?
>>> ("Hey, let's NOT take any precautions to ensure they remain
>>> synchronized...")
>>
>> I am saying that they don't (or can't) necessarily bother in a
>> consistent manner.
>
> Perhaps because its unimportant to them -- because consumers
> will tolerate this level of wander between the audio and video.
>

There's a book's worth of reasons. Not the least is that nobody
complains.

> Note, however, that there is a (evolving?) standard regarding
> the use of 1588 for A/V applications.  Obviously someone in that
> industry sees the need and has bought into the "smoke and mirrors" (?)
>

Right. I never said it was smoke and mirrors; I am saying I doubt
some of the claims for it. I have done basic research on
distributed timing, and some variation on NTP, no matter
how awesome, will surprise me if it provides significant
accuracy.

And again, I don't know why anybody needs this. If you need a high 
degree of sync, colocate the equipment.

If you can't, hope your budget is up to it.

>>>>> To play Tom's card:  find the references.  Read them.  UNDERSTAND
>>>>> THEM.  *Then*, come back and point out the FLAWS in their
>>>>> implementations!  (because you obviously are not convinced that
>>>>> *I* have already done this!)  Unless you can point out why
>>>>> 1588 *can't* work or why White Rabbit is pure fantasy, you
>>>>> won't be able to offer me any useful comment on the problem
>>>>> I'm addressing (because I *see* 1588 working in front of my eyes
>>>>> so regard comments that it "can't work" as in sharp contrast
>>>>> with "reality")
>>>>
>>>> Can't you use a GPS (or four) to provide a reference? Isn't 1588
>>>> just a way to provide GPS-like services without the GPS?
>>>
>>> You only need a GPS in your *deployed* system if you want to
>>> synchronize precisely *to* "GPS time".  If, instead, what you
>>> want is "consistent, synchronous 'time' WITHIN your system",
>>> then why incur the cost of a GPS-based GrandMaster Clock?
>>
>> I am saying use a GPS as part of your deployed system as  a device under
>> test. Test it locally with <n> GPS units to make sure it works,
>> then separate them.
>
> I can test <n> units locally (on a bench) without the need for a GPS.
> E.g., use a 'scope.
>
> That;s what I did during development.  Then challenged the system:
> - withdrawing processor resources to verify the timing daemon
>    continued to operate even as the system is stressed beyond 100%
> - heating one device while cooling another (force XO's to move in
>    different directions)
> - intercepting control packets for the timing service to verify
>    how it copes with "loss of signal" over different time intervals
> - corrupting control packets to verify they can't corrupt the
>    timing service
> - shutting down a node and verifying the system notes this loss of sync
> - powering up a node to determine how quickly it syncs to the timing
>    reference
> etc.
>
> So, I've assured myself that the algorithms and implementation are
> correct.  I don't need reassurance that when I move those nodes
> apart from each other that they are *still* exhibiting the same
> degree of synchronization.
>

I see.

> But, what do you do when there are 1,200 such devices deployed in
> a hospital setting?  Drag any suspected devices (1?  2?  500?)
> into the conference room and setup a 'scope to verify they are
> operating properly?  Does the act of removing them from their
> deployed locations affect their (mis)performance?
>

So maybe you pick a couple of victim-systems and add instrumentation
to verify those nodes.

> Much better if a technician ("on staff") can just use standard
> techniques to troubleshoot the system in situ -- they're already
> on site and have "test equipment" to service the instruments
> in use on the premises!
>
>> You can't do this on all nodes not equipped with the time reference.
>>
>>> I.e., if you don't mind that all the "clocks" in your home are
>>> "off" from your neighbors *BUT* are all consistent with each
>>> other (i.e., the clock in the kitchen shows the same time as
>>> the clock in your bedroom), then as long as they stay synchronized,
>>> you can live with that discrepancy (until your neighbor invites
>>> you to dinner and wonders why you are early/late arriving!  :> )
>>> Your neighbor's house is *outside* your "system" and, presumably,
>>> of no concern to you.
>>>
>>> Without 1588 (et il.), then you would *need* something like
>>> a GPS at each node to provide a reference time that each node
>>> could consult *knowing* it was synchronized to the other nodes.
>>
>> Right.
>
> This gets expensive (the appeal of lots of *cheap* SoC's/SBC's).
> And, limits where you can deploy the nodes.
>
>>> I.e., 1588 addresses a real issue in real systems in the real
>>> world.  Look at what the CERN folks have been playing with
>>> to see how far folks are willing to push this idea.  Then,
>>> think of how you would do what they want to do *without*
>>> this notion of "synchronized time".
>>
>> I don't really know. The stuff I have worked on does
>> not need it, generally. The handful of times we did need it,
>> we were able to add aggregate measures ( usually related to BER )
>> to various things to estimate clock quality
>
> In my case, I've more often had to deal with external "reference"
> events/signals than not.  So, the idea of syntonous and synchronous
> servos pervades many of my control algorithms.  E.g., sampling
> a capacitive sensor array syntonous with the *instantaneous* AC line
> frequency to null out AC line noise coupled from nearby flesh, etc.
>
> In your case, you still need some way to establish a reference -- even
> if you try to control accuracy and drift.  And then have to consider
> the period of time over which your assumptions will remain valid.
>
> We have no problem dealing with the idea that wall clocks are
> synchronized (by imperfect human beings) "roughly" (surely
> within 15-20 minutes of each other -- even accounting for
> those folks who set their clocks "fast") across the country.
> Or, within a few minutes within a single residence.  That
> "computers" can be synchronized to a handful of milliseconds
> globally.  I.e., it *is* possible to synchronize timepieces.  The
> degree to which we want that synchronization varies -- along with
> the cost we are willing to bear for it.
>
> How would the CERN folks deploy instrumentation over many kilometers
> to collect and control an accelerator if they *couldn't* distribute
> a sense of time and provide for *local* (distributed) use of that?
> Should they run thousands of multi-kilometer long cables for each
> sensor/actuator terminated in a single location (to avail themselves
> of a *single* "clock")?  Then, determine the propagation delay of each
> cable so they can adjust the "centrally recorded time" of a particular
> observation to reflect its transit delay?  *Anticipate* (by the transit
> delay to an actuator) when an actuator should be fired to ensure that
> the actual "activation signal" is emitted early enough to arrive at
> that actuator exactly when needed?
>

Probably; or some combination thereof.

> Wouldn't it be *so* much easier to put local intelligence/signal
> conditioning/control along that multi-kilometer path and preload
> commands with predetermined times RELATIVE TO THE START TIME OF
> THE EXPERIMENT?  Just *rely* on having a stable, shared "time
> reference" (in terms of "frequency" and "phase") that reduces
> the problem of each of those nodes to something easily managed?
>
> It seems incredibly obvious to me that 1588 (et il.) are the way
> things will be done in the future.

I would not be surprised. It sounds really cool. But I have had
a good look at what this entails, at least for < 19kM distributions.

> Folks will just pick what
> degree of (time) control and resolution they are willing to
> "purchase" in their designs.  Akin to tolerances on electronic
> components (e.g., resistors, capacitors, *crystals*...)
>


Uhhhh... there's a software stack in there, too.

> Of course, there will still be apps that fit in a single processor
> but I think more and more will "distribute" themselves to take
> advantage of these economies.
> --don


We'll see. But I still feel this is relatively esoteric.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#342

Hi Les,

On 8/7/2013 11:05 AM, Les Cargill wrote:

[much elided]

>> And, when *I* can see 200ns with *my* 'scope that I refuse to believe
>> has been tampered with by some "black ops" guys in the middle of the
>> night...
>
> I don't know what you mean by that. All I am trying to get to you
> is that there is almost certainly a way to close the timing loop for
> test purposes.

"Test" on a *bench* is easy.  Test once in situ is a bit more
difficult.  E.g., kilobuck equipment manufacturers want you to run
coax from the node under test back to the test set.  "Um, what
if the node is 100 ft away up two flights of stairs?"

I.e., they assume you remove the node, carry it to the proximity of
the test set and test/validate it *there*.  Which I can do... I
would just like to be able to test things in situ *while* they
(may be) misbehaving...

>> Finally, when you look at the theory (of the various different
>> schemes that address this issue), there's nothing glaringly wrong.
>> I.e., everything "mechanically" in the signal path is deterministic
>> in nature (software, NIC, switch, etc.).
>
> Oh dear. No - *NEARLY NOTHING* in that path is purely deterministic to
> any significant resolution.

Sure it is -- if you set out with that in mind!  They are all state
machines (not "analog circuits subject to random noise, etc.).
You minimize the variance in timing between when a packet is
passed to the NIC from the software; *know* how long the packet takes
to transit the NIC and hit the wire from the PHY; etc.

If you take the naive approach of picking a generic NIC, a generic
network stack, etc. then you have *no* idea as to what's under the
hood.  I.e., taking a timestamp in "user-land" as you pass a packet
to the network stack bears absolutely no relationship as to when
that packet will percolate down through the stack, get transferred
to the NIC and, once under the NIC's control, ultimately get dequeued
from teh NIC's internal queue and placed on the wire.

Similarly, timestamping a packet on the receiving end *after* it has
percolated up through the NIC, network stack, and into user-land
adds even more variation.

OTOH, if you select a PTP-enabled NIC (that hardware timestamps packets
as they are sent and received) -- or, a "well defined" NIC -- then
then you have the time the packet actually hit the wire (or was
peeled off the wire)... to the resolution of the oscillator in the
NIC.

Then, all you have to worry about is variations in actual transport.
I.e., if you had a dedicated link between *two* nodes, there is none.
OTOH, if you have a switch in the middle, then the traffic on other
network nodes serviced by that switch can affect how long *your*
packet sits in the switch before it gets forwarded to its destination.
(E.g., imagine if a packet is currently being delivered *by* that
switch to your destination while your packet is waiting.  Then, the
next time you send a packet, there is NOTHING ahead of you in the
queue -- the transit times across the switch can vary significantly!

>> The only source of
>> randomness comes with the introduction of the switch -- competing
>> traffic vying for its resources.
>
> Maybe. It all depends on the switch.

Yes.  Hence the use of transparent switches and boundary switches.
I.e., switches that are aware of this use and *participate* in
the protocol (instead of messing with it!)

>> If you put a pair of PTP-enabled NIC's back-to-back with a crossover
>> cable, you'd have no problem believing that they could compensate
>> for the transport delay in that cable of uncalibrated length.  Right?
>> (within the realm of clock jitter).
>
> Try it. Spend some time with it. I can tell you, but you'll
> select different hardware or a slightly different O/S and it'll
> be different.

That's what I've already done (though I also have a switch in
the middle).  But, it's *my* hardware -- not something you
can select at random!  And, *my* network stack (designed to
offer deterministic behavior).  And, my *network* (i.e., I
know what traffic coexists with the protocol traffic -- I
don't have to tolerate asynchronous uses at the whim of some
"user")

>>>>> Meanwhile, the audio signal on most cable systems is quite
>>>>> un-synchronized from the picture.
>>>>
>>>> And you like that and would like to see even more variability
>>>> added to it?  What about when you have a live audio+video feed?
>>>> ("Hey, let's NOT take any precautions to ensure they remain
>>>> synchronized...")
>>>
>>> I am saying that they don't (or can't) necessarily bother in a
>>> consistent manner.
>>
>> Perhaps because its unimportant to them -- because consumers
>> will tolerate this level of wander between the audio and video.
>
> There's a book's worth of reasons. Not the least is that nobody
> complains.

Exactly.  There's no reason to provide better service.  Until
someone *does* and market pressures cause folks to demand that
same level of performance from others (who will undoubtedly
adopt the newer technology as a matter of course -- normal
upgrades, etc.  E.g., there are already standards actions in
the works to codify this particular application for 1588
cuz its *so* obvious)

>> Note, however, that there is a (evolving?) standard regarding
>> the use of 1588 for A/V applications.  Obviously someone in that
>> industry sees the need and has bought into the "smoke and mirrors" (?)
>
> Right. I never said it was smoke and mirrors; I am saying I doubt
> some of the claims for it. I have done basic research on
> distributed timing, and some variation on NTP, no matter
> how awesome, will surprise me if it provides significant
> accuracy.
>
> And again, I don't know why anybody needs this. If you need a high
> degree of sync, colocate the equipment.

It's a question of cost and practicality.  If you are monitoring
signals in different locations, do you run "really long wires"
to get all those signals to a common measurement point?

Look at the power industry.  A 60 Hz signal.  Slow, right?
They need event resolutions about 4 times that in order to
successfully do a post-mortem of a failure in the grid
(e.g., like a blackout that puts hundreds of square miles in
the dark).

Located within substations are DME's (disturbance measurement
equipment) that record "events".  These are specified to
be able to record events to an absolute accuracy of better than
1ms.  I.e., over thousands of miles.

[Yes, you can get this with a GPSDO at each substation.  But,
within the substation you also have to guarantee the same
accuracy -- regardless of the physical size of the substation.
Do you put a GPS at each relay, event recorder, etc. *in*
the substation?  Run all the wires to one central "reporting
and recording" station?  Then, add some *other* mechanism to
*communicate* with the substation?]

>>>>> Can't you use a GPS (or four) to provide a reference? Isn't 1588
>>>>> just a way to provide GPS-like services without the GPS?
>>>>
>>>> You only need a GPS in your *deployed* system if you want to
>>>> synchronize precisely *to* "GPS time".  If, instead, what you
>>>> want is "consistent, synchronous 'time' WITHIN your system",
>>>> then why incur the cost of a GPS-based GrandMaster Clock?
>>>
>>> I am saying use a GPS as part of your deployed system as  a device under
>>> test. Test it locally with <n> GPS units to make sure it works,
>>> then separate them.
>>
>> I can test <n> units locally (on a bench) without the need for a GPS.
>> E.g., use a 'scope.
>>
>> That;s what I did during development.  Then challenged the system:
>> - withdrawing processor resources to verify the timing daemon
>>    continued to operate even as the system is stressed beyond 100%
>> - heating one device while cooling another (force XO's to move in
>>    different directions)
>> - intercepting control packets for the timing service to verify
>>    how it copes with "loss of signal" over different time intervals
>> - corrupting control packets to verify they can't corrupt the
>>    timing service
>> - shutting down a node and verifying the system notes this loss of sync
>> - powering up a node to determine how quickly it syncs to the timing
>>    reference
>> etc.
>>
>> So, I've assured myself that the algorithms and implementation are
>> correct.  I don't need reassurance that when I move those nodes
>> apart from each other that they are *still* exhibiting the same
>> degree of synchronization.
>
> I see.

You can purchase a reference design from any number of manufacturers
and "challenge" it yourself for a few hundred bucks.  It hasn't been
"cutting edge" for more than a decade!

>> Wouldn't it be *so* much easier to put local intelligence/signal
>> conditioning/control along that multi-kilometer path and preload
>> commands with predetermined times RELATIVE TO THE START TIME OF
>> THE EXPERIMENT?  Just *rely* on having a stable, shared "time
>> reference" (in terms of "frequency" and "phase") that reduces
>> the problem of each of those nodes to something easily managed?
>>
>> It seems incredibly obvious to me that 1588 (et il.) are the way
>> things will be done in the future.
>
> I would not be surprised. It sounds really cool. But I have had
> a good look at what this entails, at least for < 19kM distributions.

There are just too many applications ready for this sort of
facility.  And, more and more SoC vendors producing cheap
silicon with the hooks already in place to implement these
things.

>> Folks will just pick what
>> degree of (time) control and resolution they are willing to
>> "purchase" in their designs.  Akin to tolerances on electronic
>> components (e.g., resistors, capacitors, *crystals*...)
>
> Uhhhh... there's a software stack in there, too.

Yes.  You don't buy a "generic resistor" when you need 1% at 1/4W.
Similarly, you don't pick a "generic network stack" when you want
deterministic performance from it (and PTP support)!

>> Of course, there will still be apps that fit in a single processor
>> but I think more and more will "distribute" themselves to take
>> advantage of these economies.
>
> We'll see. But I still feel this is relatively esoteric.

Have a look at the Freescale, TI, etc. offerings.  IIRC there
are several ethernet ARMs with PTP-enabled NICs already.

--don

[toc] | [prev] | [next] | [standalone]

#343

On 08/08/13 02:22, Don Y wrote:
> OTOH, if you select a PTP-enabled NIC (that hardware timestamps packets
> as they are sent and received) ...

Out of curiosity, are your applications using TAI or UTC for
their definition of time?

[toc] | [prev] | [next] | [standalone]

#331

Don Y <this@isnotme.com> writes:
> BETTER THAN MICROSECOND LEVEL

OK, 1 microsecond, finally an actual number.

> I have two physical, tangible devices... interconnected by an
> ethernet (CAT5) cable that is >100 ft long (but of uncalibrated
> length).

Well how long is it really?  Is it fair to say 50 meters?  I.e.  several
of us have asked you to state once and for all the actual numbers from
your real system, so we can use them instead of speaking in
hypotheticals.

> difference in absolute time between the two pulses is O(<1us).

I don't know what "absolute time" is supposed to mean but 1us is an
actual number, so fine.

> If I lengthen the cable between the two devices and repeat the
> experiment, the results do not change.

Where are you doing the measurement?  In the middle of the cable?

> so the devices are *really* separated by that 100+ feet, I still
> *know* the two pulses are being emitted at the "same" time
> (within a microsecond of each other).  But, I can't *show*
> that (or verify it!) 

Why do you want to show or verify <1 us?  What happens if it's somehow
become 2 us?

> *I* use it to synchronize (control the timing relationship between):
> - audio emitted from different "speakers"
> - audio from said speakers with video from a "display device"
> - audio received from a microphone with video from a camera

Audio propagates at about 1 foot per millisecond, and there will be
variations of much more than 1us across 100 feet due to changes in air
temperature, breezes, frequency of the audio, etc.  So the 1us
requirement in relation to audio doesn't sound like part of a practical
problem.

> - determining the location of a moving target within an arena
> - partitioning of resources (in time) across the system

I don't see where 1us comes into this either.

> - control phased ultrasonic arrays (emit & detect)
> - deploy audio in "stadium scale" venues
> - geological probes (emit & detect)
> - industrial (process) control systems

Or in those.

> Having a common, shared, synchronized notion of "time" across
> physically separate devices is a powerful mechanism!

But it doesn't make physical sense.

> For example, those silly folks at CERN use a (greatly) enhanced PTP
> implementation ("White Rabbit") that delivers sub-NANOsecond...
> synchronization over distances of KILOMETERS. 

That doesn't make sense either.  The physical world is not a shared
memory system where there's a single register with the current time,
that can be read instantaneously from everywhere.  If A and B are 1km
apart, then saying they happened within 1 ns of each other is
meaningless.  The best you could say "globally" is that they were within
3 us of each other (= 1km at the speed of light).  You could say that
events at A and B were observed within 1 ns of each other at some
specific location C (say midway between A and B).  Maybe that matches
your actual requirement.  There's no location-independent simultaneity.

> Again, to be specific:  tell me how I can verify/measure the
> time relationship between those two pulse outputs WHEN THEY ARE
> ACTUALLY SEPARATED BY HUNDREDS OF FEET.

People have suggested radios, GPS, cables, etc.  Lasers or LED's seems
like another possibility.  I don't see what the problem is, as long as
you concretely say what you what to measure, and it seems to me you've
been vague.  1us at 50m doesn't sound like it needs high tech methods.

[toc] | [prev] | [next] | [standalone]

#336

On 8/6/2013 10:18 PM, Paul Rubin wrote:
> Don Y <this@isnotme.com> writes:
>> BETTER THAN MICROSECOND LEVEL
>
> OK, 1 microsecond, finally an actual number.

Why do you care?  Note I claimed "tens to hundreds of nanoseconds".
You *buy* the level of performance you want/need for the application
you are solving.

As to "finally" implying that this has been a closely held
"secret" that was only "reluctantly divulged", I remind you
that my initial post was at 10:40AM on 8/3.  At 1:21PM on
that same day (i.e., 2.5 hrs later, 3 days *before* your
message) I had already claimed:

     "My software  can easily achieve synchronization between
     nodes to a level better than 1us -- without doing anything
     fancy."

At 1:41PM I further qualified this:

     "That depends on the level of resources I want to apply to the
     problem.  For "free" I can get O(200ns).  If I want to more
     carefully specify my hardware, I can drop that to O(20ns)."

Earlier, at 11:56AM, I had already declared "a city block".

Perhaps you haven't been paying close attention?

>> I have two physical, tangible devices... interconnected by an
>> ethernet (CAT5) cable that is >100 ft long (but of uncalibrated
>> length).
>
> Well how long is it really?  Is it fair to say 50 meters?  I.e.  several
> of us have asked you to state once and for all the actual numbers from
> your real system, so we can use them instead of speaking in
> hypotheticals.


A CITY BLOCK.  For my test, I chose a ~100ft cable.  I could have
chosen a 200 ft cable.  etc.  The length of the cable does not matter!
That's the whole point of the algorithm!  And, why I intentionally and
repeatedly claim it is "of uncalibrated length" (didn't you think
it unusual that I deliberately drew attention to this fact?  Maybe
that's *significant*???)

If you want to pick nits, you could possibly ask if that city
block is planar or three-dimensional -- and, in this latter case,
what limits exist on the Z axis.

(Let's make it simple.  Pretend there is 1/10 - 1/8 mile separating
nodes.  I.e., they are deployed -- possibly *uniformly* -- over 1/100
to 1/64 sq mile of real estate)

>> difference in absolute time between the two pulses is O(<1us).
>
> I don't know what "absolute time" is supposed to mean but 1us is an
> actual number, so fine.

Each device obviously has its own concept of "local time".  That's
the point of "synchronizing" them!  I am drawing attention to the
fact that a single observer in a single location with both devices
physically observable from that position would note <1us of time
difference between two events synthesized on those different
devices *intended* (by those devices) to "coincide" in time.

>> If I lengthen the cable between the two devices and repeat the
>> experiment, the results do not change.
>
> Where are you doing the measurement?  In the middle of the cable?

No.  Two devices on a bench.  Two outputs -- one from each -- connected
to the *same* 'scope.  Some uncalibrated (there's that word, again!)
length of cable electrically connects those two devices.  There is
no other way they can communicate other than by this cable.

Both devices are allowed to "stabilize" (i.e., the FLL and PLL to
settle into lock).  Then, the time difference between two pulses
intended to be omitted coincidentally is measured.  I.e., both
devices share a common concept of "current time" -- even though
they are not residing in the same "CPU" clocked by the same
oscillator, etc.  They are both told to emit a pulse at
t=12345678 (units being irrelevant -- as long as they can be
correlated between the two devices).

Now, power everything off, replace the interconnect cable with
one that is longer/shorter and repeat the process.  The time
difference between the pulses doesn't change.  I.e., the
algorithm compensates for the length of the cable.

[There is some sleight of hand in this explanation but it is
essentially correct -- the delay *will* vary by 1/2 the underlying
timebase, maximum]

>> so the devices are *really* separated by that 100+ feet, I still
>> *know* the two pulses are being emitted at the "same" time
>> (within a microsecond of each other).  But, I can't *show*
>> that (or verify it!)
>
> Why do you want to show or verify <1 us?  What happens if it's somehow
> become 2 us?

Ah!  Now you see the problem!  *Why* would it suddenly become 2 us?
All we did was move the devices.  The electrical connection between
them has not changed.  The software hasn't changed.  Why does moving
the devices such that the cable is now "stretched taut" (or, more
taut than it was previously) change the tightness/looseness of the
synchronization?

If the algorithm and implementation have been *qualified*/quantified
to provide 1us (or 200ns) of synchronization, why does the PHYSICAL
location of the devices matter?  (i.e., it should not -- assuming
you haven't changed some environmental factor *beyond* the limits
of the specification).

So, if you (as a customer/user/technician) observe a deployed system
"misbehaving", what is the "troubleshooting procedure" that you bring
to bear on the problem?

If you're troubleshooting a generic board, chances are you first
check power and other key signals ON WHICH THE DESIGN INTIMATELY
RELIES!  Is the CPU running?  How do you know -- observer the
oscillator?  Monitor address/data bus?  Watch an "idiot light"
blink?

Time is important in most "real world" systems.  You can verify
the device (returning to the system in question, here) has *a*
concept of time.  But, is it consistent with the *system's*
concept of time?  How do you verify that when the other node(s)
that you want to compare against (like you did "on the bench"
in the example above) are behind walls, on different floors
and hundreds of feet away in space?  You need *really* long
arms to "probe" those signals!

>> *I* use it to synchronize (control the timing relationship between):
>> - audio emitted from different "speakers"
>> - audio from said speakers with video from a "display device"
>> - audio received from a microphone with video from a camera
>
> Audio propagates at about 1 foot per millisecond, and there will be
> variations of much more than 1us across 100 feet due to changes in air
> temperature, breezes, frequency of the audio, etc.  So the 1us
> requirement in relation to audio doesn't sound like part of a practical
> problem.

But there have been claims that we *can't* synchronize "time"
at all!  Just note "which comes before/after".  In that context,
1ms is just as "impossible" as 1us!

[Note, also, that you are actually looking to "tune" devices to
a fraction of a foot as the voice coil of a tweeter is often
located at a different "depth" than that of a woofer/squawker]

>> - determining the location of a moving target within an arena
>> - partitioning of resources (in time) across the system
>
> I don't see where 1us comes into this either.

Put a radio in a room.  Let it emit a signal of its own choosing
at a time of its own choosing.  Tell me where it is *without*
a common sense of time.  (there are actually ways to do this
but they typically *add* RF to the environment)

>> - control phased ultrasonic arrays (emit & detect)
>> - deploy audio in "stadium scale" venues
>> - geological probes (emit & detect)
>> - industrial (process) control systems
>
> Or in those.

How do you precisely control the phase of a 100KHz signal with a
e.g., 1ms timebase?  Even a 20KHz (lower end of ultrasound)
signal has a total *period* of only 50us.  I.e., 1us gives
you ~7 degrees of phase resolution.

Now, look at the echo/detect aspect.  How do you determine the
return angle of an echo if you can't resolve the temporal
differences between the many transducers in the array?

(there are ways around this, as well)

>> Having a common, shared, synchronized notion of "time" across
>> physically separate devices is a powerful mechanism!
>
> But it doesn't make physical sense.

Why?  Is "now" somehow different for you than it is for me
based solely on where we are located?  If the sun goes supernova,
doesn't it happen at *a* point in time?  Regardless of where
we are each located?

If the leading edge of an earthquake occurs at some fixed point in
time, isn't it a *single* event occurring in "Time"?  Despite the
fact that two observers may "notice" this event at different
points in "Time".  Don't we explicitly rely on a synchronized
sense of time to locate where the event occurred?  E.g., if
it happened at time=27 and I claim I noticed the event at time=blue;
this would provide no useful information.  And, if I said I noticed
it at time=26 that would be equally useless.  (i.e., having the same
*units* of measurement *and* reference point in time)

>> For example, those silly folks at CERN use a (greatly) enhanced PTP
>> implementation ("White Rabbit") that delivers sub-NANOsecond...
>> synchronization over distances of KILOMETERS.
>
> That doesn't make sense either.  The physical world is not a shared
> memory system where there's a single register with the current time,
> that can be read instantaneously from everywhere.  If A and B are 1km
> apart, then saying they happened within 1 ns of each other is
> meaningless.

No.  You're getting caught up in relativity theory.

If I put two devices 1 inch apart and separate them by
10,000km of interconnect cable (e.g., fibre) and shine
a light on both of them (each has a photodetector),
do you agree that "now" is the same point in "Time"
for both units?

Now, one of the units sends a message to the other
saying "Wow! Someone JUST turned on the light!".
That message arrives at the second unit ~30 ms later!

But, both units understand that this was a single point
in Time that has been made to appear skewed simply because
of the transmission delay in the cable.

If the second unit had a precise notion of "1ms", then
it could accurately and reliably predict the *instant*
the message from the first unit would arrive.

Similarly, if the second device could not *see* the light
but was designed (specified!) to make a noise 50ms after
the light was illuminated, it could wait for the message
from the first unit, delay 20 additional ms and successfully
make that noise exactly 50ms after the light was illuminated!

Now, if you move that second unit to a point in space
10,000 km distant from the first unit and repeat the
experiment, the results remain the same.  A blind but
not deaf observer at that remote location, on hearing
the noise, would *know* that the light was turned
on exactly 50ms ago.  50 of *his* ms being the same
unit of measure as the ms *at* the light!

How has their physical separation changed the instants
at which each of these events actually occurred?

> The best you could say "globally" is that they were within
> 3 us of each other (= 1km at the speed of light).  You could say that
> events at A and B were observed within 1 ns of each other at some
> specific location C (say midway between A and B).  Maybe that matches
> your actual requirement.  There's no location-independent simultaneity.
>
>> Again, to be specific:  tell me how I can verify/measure the
>> time relationship between those two pulse outputs WHEN THEY ARE
>> ACTUALLY SEPARATED BY HUNDREDS OF FEET.
>
> People have suggested radios, GPS, cables, etc.  Lasers or LED's seems
> like another possibility.  I don't see what the problem is, as long as
> you concretely say what you what to measure, and it seems to me you've
> been vague.  1us at 50m doesn't sound like it needs high tech methods.

(sigh)  Yet again:  I want to measure the skew (phase difference if you
want to think in terms of periodic signals) between two times *intended*
to be coincident over a long distance to a high tolerance.

You might want to *try* it before dismissing it  :>  With a (metal?)
wall between you and it and very few dollars to spend.  Everything is
always easy until it's *your* problem to solve with real constraints!
E.g., try synchronizing two "clocks" (located side by side so
it doesn't upset your relativistic sensibilities!) on devices
interconnected by 2km of fibre (i.e., 2us propagation delay) and
*no* intervening hardware (e.g., network switch) to better than 1us.
Heck, you can even use a "present day" PC with all its resources
available to you and all that cost that entails -- for free!   :>
Once you're done, figure out how you can prove this fact when
I drag one of the PC's into another room down the hall...

[toc] | [prev] | [next] | [standalone]

#337

On 07/08/13 11:09, Don Y wrote:
> On 8/6/2013 10:18 PM, Paul Rubin wrote:
>>
>> Well how long is it really?  Is it fair to say 50 meters?  I.e.  several
>> of us have asked you to state once and for all the actual numbers from
>> your real system, so we can use them instead of speaking in
>> hypotheticals.
>
>
> A CITY BLOCK.

Over here we don't have city blocks, so we use
double-decker busses as the unit of length :)
How many double-decker busses are there in
a city block? :)


> But there have been claims that we *can't* synchronize "time"
> at all!  Just note "which comes before/after".

No, there haven't. You really don't understand.


> In that context, 1ms is just as "impossible" as 1us!

Depends on the propagation delay between them. If 1ns then
it has meaning to discuss a common time with a 1us
resolution. If 1s delay, then it would be meaningless.


>>> Having a common, shared, synchronized notion of "time" across
>>> physically separate devices is a powerful mechanism!
>>
>> But it doesn't make physical sense.
>
> Why?  Is "now" somehow different for you than it is for me
> based solely on where we are located?  If the sun goes supernova,
> doesn't it happen at *a* point in time?  Regardless of where
> we are each located?

No. Absolutely not.

Yesterday there were reports of us seeing the first "kilonova"
which happened 4bn years ago. So, yesterday = 4bn years ago,
with no possibility of communicating sooner
<http://science.nasa.gov/science-news/science-at-nasa/2013/03aug_kilonova/>


> If I put two devices 1 inch apart and separate them by
> 10,000km of interconnect cable (e.g., fibre) and shine
> a light on both of them (each has a photodetector),
> do you agree that "now" is the same point in "Time"
> for both units?

Yes, because they are at the same place.

Repeat the experiment with the cable being
straight (so they are 10,000km apart), and
the answer becomes no. Or rather it means
"time" has to be qualified by "as observed
at location..."

[toc] | [prev] | [next] | [standalone]

#338

On 07/08/13 11:09, Don Y wrote:

> Why?  Is "now" somehow different for you than it is for me
> based solely on where we are located?  If the sun goes supernova,
> doesn't it happen at *a* point in time?  Regardless of where
> we are each located?

Suppose we have two identical perfect clocks that showing
identical time (to an observable resolution of 1fs) when
they are next to each other, at point A.

Now move one clock so that it is one light-millisecond
away, to point B.

At 12:00:00.000 "foo" occurs at point A

At 12:00:00.001 "foo" is observed at point B, which
causes "baz" to occur one Planck time later.

At 12:00:00.002 "baz" is observed at point A.

Q: did "foo" and "baz" occur simultaneously or not?
A: yes, repeat no.

Obviously yes at B and no at A (and everywhere else).

If time /was/ common everywhere and they occurred
simultaneously, it would require that
12:00:00.000 = 12:00:00.001 = 12:00:00.002
which is paradoxical.

Note that framing the events in terms of "happens-before"
avoids such paradoxes. And that is why "logical clocks"
are used in real systems of communicating distributed
processors.

[toc] | [prev] | [next] | [standalone]

#316

On 06/08/13 04:09, Don Y wrote:

> On 8/5/2013 4:27 PM, Tom Gardner wrote:
 >>

> I.e., do the hands of Big Ben revolve at a different rate than the
> clock in Times Square?

You are confusing clocks and time.


> See above.  Do you claim that a nondistributed system *can't*
> have an idea of "passing time"?

You are confusing clocks and time.


>> Read and understand the references I gave you.
>
> Old news.

There are some old expressions: "you can lead a
horse to water, but you can't make it drink" and
"those that don't understand history are
condemned to repeat it".


>> Even if you could still have long elastic test leads, the
>> phase (which is equivalent to time) of the PLL will
>> change as the elastic lead is elongated.
>> Now consider three nodes arranged in a triangle so that
>> each node is attached to two test leads. If only one lead
>> is lengthened, should the PLL phase change or not?
>
> You don't lengthen *one* -- you lengthen *both*.  I.e., both
> signals experience the same delay in transit... the phase
> relationship is retained at the "extended" tips of the
> cables (which COULD be different than at the *source* of
> leads)

Three nodes, three leads stretched tight. Now very move
one node at non-relativistic speeds so that only one
(perfectly elastic) lead changes length. Should the PLL
change phase?

[I should have been more explicit about one node
moving - apologies]

[toc] | [prev] | [next] | [standalone]

#319

Hi Tom,

On 8/6/2013 1:23 AM, Tom Gardner wrote:
> On 06/08/13 04:09, Don Y wrote:
>
>> On 8/5/2013 4:27 PM, Tom Gardner wrote:
>
>> I.e., do the hands of Big Ben revolve at a different rate than the
>> clock in Times Square?
>
> You are confusing clocks and time.

Clocks measure the passing of time (in <some> units).

To repeat the first sentence of my post:
     I synchronize the "clocks" on physically distributed processors
     such that two or more different machines can have a very finely
     defined sense of "synchronized time" between themselves.
Was it not obvious from this that the clock was a hardware/software
device that was used to *track* time?  And, that I (already) had
an implementation in place that caused these "mechanisms" (clocks)
on the different processors to reflect a common notion of "now"?

Could you suggest a more explicit way of stating this?  Without
being overly pedantic??

[In some contexts, clocks are hardware devices while timers
are software mechanisms]

>> See above.  Do you claim that a nondistributed system *can't*
>> have an idea of "passing time"?
>
> You are confusing clocks and time.
>
>>> Read and understand the references I gave you.
>>
>> Old news.
>
> There are some old expressions: "you can lead a
> horse to water, but you can't make it drink" and
> "those that don't understand history are
> condemned to repeat it".
>
>>> Even if you could still have long elastic test leads, the
>>> phase (which is equivalent to time) of the PLL will
>>> change as the elastic lead is elongated.
>>> Now consider three nodes arranged in a triangle so that
>>> each node is attached to two test leads. If only one lead
>>> is lengthened, should the PLL phase change or not?
>>
>> You don't lengthen *one* -- you lengthen *both*.  I.e., both
>> signals experience the same delay in transit... the phase
>> relationship is retained at the "extended" tips of the
>> cables (which COULD be different than at the *source* of
>> leads)
>
> Three nodes, three leads stretched tight. Now very move
> one node at non-relativistic speeds so that only one
> (perfectly elastic) lead changes length. Should the PLL
> change phase?

Yes -- if the *electrical* length of the lead has changed
then the propagation delay through that lead will change
and, depending on the wavelength of the (periodic) signal
being propagated along its length, the phase will change
accordingly.

[Assuming it is a periodic signal so the idea of phase makes
sense]

Hence my original comment that measuring the "relationship"
(phase if considering a periodic signal; absolute time for
anything aperiodic) between two physically separate signals
could only be easily accomplished with equal length "test
lead extensions".

If the difference in "extension lengths" is a foot, then
the signal traveling down *that* extension will appear
to be ~1.5ns delayed from the signal traveling down the
shorter lead -- compared to the measurement that would
have been obtained by comparing the actual "non-extended"
pins.

> [I should have been more explicit about one node
> moving - apologies]

[toc] | [prev] | [next] | [standalone]

#318

Don Y wrote:

> On 8/5/2013 4:27 PM, Tom Gardner wrote:

[%X]

>> Because that's all you can realise, in theory and in practice.
> 
> Nonsense.  Do you mean there is NO WAY for two physically
> separated systems to have a common notion of "the passage of time"?
> That a "second" (pick your favorite unit) somehow differs when
> experienced by one system and another system "nearby" or "remote"?
> That a chunk of quartz magically vibrates differently because
> it's in one place and not another?

Temperature effects in the different locations will affect the common sense 
of timing. 

You say you have implemented an LXI like protocol on 1588. You now need 
extra confidence that their is a phase correlation between the two nodes, to 
some fine accuracy, such that you can be certain of the difference in phases 
of the same actions being asked of both distant nodes.

Someone mentioned GPS as a timing reference, which, if you had such a 
receiver at each location, assist in establishing how common a time-frame 
you were working to. If you are monitoring the action in each node you could 
record the GPS time-stamp and the nodes own time-stamp as corrected by LXI 
in order to see how close you are to simultaneity. Other than that the equal 
length cabling installed from each node would be the only other way you 
could determine this.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [next] | [standalone]

#345

Don Y wrote:

> Hi,
> 
> [posted to S.E.D in the hope that a hardware analog might exist]
> 
> I synchronize the "clocks" on physically distributed processors
> such that two or more different machines can have a very finely
> defined sense of "synchronized time" between themselves.
> 
> During development, I would measure this time skew (among other
> factors) by locating these devices side-by-side on a workbench
> interconnected by "unquantified" cable.  Then, measuring the
> time difference between to "pulse outputs" that I artificially
> generate on each board.
> 
> So, I could introduce a disturbance to the system and watch to
> see how quickly -- and accurately -- the "clocks" (think FLL and
> PLL) come back into sync.
> 
> How do I practically do this when the devices are *deployed*
> and physically distant (vs. "electrically distant" as in my
> test case)?
> 
> Two ideas come to mind:
> 1) two equal length cables to connect the "pulse outputs"
> from their respective originating devices to the test gear.
> 2) two *radios* to do the same thing -- after accounting
> for different flight times
> 
> [Though I wonder how hard it is to qualify two different
> radios to have the same delay, etc.  Far easier to trim
> two long lengths of wire to the same length!]
> 
> Of course, I would like to minimize the recurring cost of
> any solution as it is just present for system qualification
> (and troubleshooting) and offers no run-time advantage to
> the design.

You might find this of interest and useful if you had a couple of fibres in 
your installed bundle. I was chatting to one of the guys visiting JET from 
CERN today and he stated that the timing accuracy is 1ps on phase and 1ns on 
time synchronicity.

<http://www.ohwr.org/projects/white-rabbit/documents>

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

Back to top | Article view | comp.realtime

csiph-web