Prev: OpenTherm protocol: looking for schematics
Next: From Access to MySQL
From: D Yuniskis on 23 Dec 2009 14:17
Spehro Pefhany wrote:
> On Wed, 23 Dec 2009 10:08:53 -0700, D Yuniskis
>
>> With that, fine-grained synchronization over (wired) networks
>> becomes problematic -- there's no deterministic way for a
>> processor in a particular node to have any idea of its
>> relative packet time wrt any other node in the network
>> (though it is pretty obvious that a packet arrives at
>> its destination some time *after* leaving its source! :> )
>>
>> Sure, things like NTP *try* to quantify this skew. But,
>> its goals are much more long-term... if it is wrong on
>> the short term, there is no significant consequence.
>> (I also suspect the apparent precision and accuracy that
>> NTP provides is largely delusional :-/ )
>>
>> So, how *do* you achieve fine-grained synchronization
>> nowadays? What is *practical*? And theoretically
>> *achievable* (without an a priori characterization
>> of the network infrastructure and topology)?
>
> Hey, Don:-
>
> PTP.. IEEE-1588.

Hi Spehro,

Yes, but this makes lots of assumptions (constraints)
about deployment.

Let me rephrase my question in a more general way:

What level of synchronization can you expect to achieve
in an unconstrained deployment environment? E.g.,
imagine you are trying to coexist within an *existing*
network structure -- you can't tell the customer
to replace his switches; or flatten his network;
or stop running applications that generate lots of
network traffic, etc.

I.e., you *can't* count on the user having special hardware
to generate good timestamps; special switches to propagate
this behaviour across the switch; "benign" applications that
let the network quiesce during times when synchronization
activities are happening; hosts that are NOT evenly loaded
wrt network traffic; NICs vary from machine to machine; etc.

I.e., you have to coexist with what is rather than
redesign what you would *like*...

Note that in days past, this was a lot easier to
achieve as broadcasts tended to *truly* be broadcasts,
propagation delays were simply K * distance * speed of
light, etc.
From: Vladimir Vassilevsky on 23 Dec 2009 14:58


D Yuniskis wrote:

> What level of synchronization can you expect to achieve
> in an unconstrained deployment environment? E.g.,
> imagine you are trying to coexist within an *existing*
> network structure -- you can't tell the customer
> to replace his switches; or flatten his network;
> or stop running applications that generate lots of
> network traffic, etc.


J = packet delivery jitter (sec)
V = number of sync packets per sec
D = drift of the local clock (Hz/sec)

D J^4 1
Time error (sec) = [-------] ^ ---
2 V^2 5


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
From: Ed Prochak on 29 Dec 2009 13:53
On Dec 23, 2:17 pm, D Yuniskis <not.going.to...(a)seen.com> wrote:
> Spehro Pefhany wrote:
[]
>
> > Hey, Don:-
>
> > PTP.. IEEE-1588.
>
> Hi Spehro,
>
> Yes, but this makes lots of assumptions (constraints)
> about deployment.
>
> Let me rephrase my question in a more general way:
>
> What level of synchronization can you expect to achieve
> in an unconstrained deployment environment?  E.g.,
> imagine you are trying to coexist within an *existing*
> network structure -- you can't tell the customer
> to replace his switches; or flatten his network;
> or stop running applications that generate lots of
> network traffic, etc.
>
> I.e., you *can't* count on the user having special hardware
> to generate good timestamps; special switches to propagate
> this behaviour across the switch; "benign" applications that
> let the network quiesce during times when synchronization
> activities are happening; hosts that are NOT evenly loaded
> wrt network traffic; NICs vary from machine to machine; etc.
>
> I.e., you have to coexist with what is rather than
> redesign what you would *like*...

Question is: what are your trying to achieve? What really are your
real-time constraints?

Is it soft real time? Is the timestamped data essentially historical?
(i.e. late delivery updates a database of some sort. It is not used
immediate calculations for process control) You need all the data, but
late or out of order delivery does not create serious error
conditions.
IMO, This case could essentially be solved at the application layer.
(Timestamps generated by the end point devices, correlated to the
destination device's clock.)

Is it really hard real time? IOW, you are doing some kind of process
control?
Sorry, but ethernet being what it is does not provide any way to
assure delivery times. That's why there tends to be distributed
process control. Put as much intelligence as needed at the point of
control.

>
> Note that in days past, this was a lot easier to
> achieve as broadcasts tended to *truly* be broadcasts,
> propagation delays were simply K * distance * speed of
> light, etc.

Only if you happened to be on the same wire. Since hubs and bridges,
it has never been that simple.
Ed

From: Dombo on 29 Dec 2009 14:47
Ed Prochak schreef:

> Is it really hard real time? IOW, you are doing some kind of process
> control?
> Sorry, but ethernet being what it is does not provide any way to
> assure delivery times. That's why there tends to be distributed
> process control. Put as much intelligence as needed at the point of
> control.

For real-time applications one could consider ethercat.

From: Vladimir Vassilevsky on 30 Dec 2009 10:00


D Yuniskis wrote:

> I want to know what is *possible* before even considering various
> communication media.

Anything is possible. Providing everything is done right, snake networks
achieve picosecond level of accuracy over 100M Ethernet. However, this
doesn't work with WiFi because of unpredictable delays.

BTW, I've done project where I synchronized a network with microsecond
accuracy over voiceband wireless link.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: OpenTherm protocol: looking for schematics
Next: From Access to MySQL