Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #13015
| From | Don Y <this@isnotme.com> |
|---|---|
| Newsgroups | comp.arch.embedded, comp.realtime |
| Subject | Re: Comparing phase of physically distant signals |
| Date | 2013-08-06 23:50 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <ktsqnq$us3$1@speranza.aioe.org> (permalink) |
| References | (5 earlier) <7xmwovo10s.fsf@ruckus.brouhaha.com> <ktqd7j$j3q$1@speranza.aioe.org> <ktqp9k$of0$1@dont-email.me> <ktrcil$b7v$1@speranza.aioe.org> <ktsgtk$tdg$1@dont-email.me> |
Cross-posted to 2 groups.
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
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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