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

Groups > comp.arch.embedded > #13044

Re: Comparing phase of physically distant signals

Cross-posted to 2 groups.

Show all headers | View raw

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

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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 Don Y <this@isnotme.com> - 2013-08-04 12:19 -0700
  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 Don Y <this@isnotme.com> - 2013-08-06 02:17 -0700
  Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-16 21:07 +0100
    Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-16 14:50 -0700
      Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-18 19:55 +0100
        Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-19 11:43 -0700
          Re: Comparing phase of physically distant signals Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-08-20 21:43 +0100
            Re: Comparing phase of physically distant signals Don Y <this@isnotme.com> - 2013-08-20 14:49 -0700

csiph-web