Re: silly ravenscar question

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 3 Mar 2015 00:42:51 -0800 (PST), jan.de.kruyf@gmail.com wrote:

> On Sunday, March 1, 2015 at 11:28:01 AM UTC+2, Dmitry A. Kazakov wrote:
> 
>> And from the software perspective, the idea that you could enforce
>> real-time/synchronicity per real-time protocol is flawed. More complex the
>> software running on top of the protocol less chances you have to keep
>> synchronicity up to the application level because you need time to
>> propagate the signal though levels of hardware and software.
> 
> Yes again. So in my humble opinion the sums for synching and the
> return-packet-sending must be done, as the incoming packet leaves the dma
> channel.

It is not the issue. You cannot hard sync anything complex enough to be
useful.

> So to sum up:
> To me there are broadly 3 alternatives
> 
> 1. a sync pulse broadcast every scan period, which triggers the data
> reading etc. This might then be refined with some averaging circuitry to
> create a stable local clock to do the actual triggering.
> Then for each station the master must keep track of the offset from the master.
> 
> 2. Synchronize a whole subnet to itself. this is very attractive since
> with a good algorithm the individual boards will track one-another quite
> perfectly and dead terminals give no real problem. ( If you can imagine a
> flock of birds making a turn: each bird only sees what the nearest
> neighbors do and reacts accordingly)
> against: 
> The master still needs to keep track of the offset from real time for that
> net.
> (So there will be only 1 offset per subnet) And there is possibly more
> network traffic involved, since all exchanges between neighbors must
> happen over 1 net.
> 
> 3. IEEE1588:
> Time is imposed top-down. It works very accurately if implemented properly
> in a small net. Everybody knows real time.
> Against:
> As the net grows jitter and inaccuracies get bigger. Switchboxes need to
> be preferably IEEE1588 enabled in bigger networks. 
> And as with all top-down structures, collapses will be quite spectacular.
>
> So this is what I have dreamed up so far.
> Please comment as you see fit.

There is no reason why not to support IEEE1588 if available and, when not
available, not to use other means to estimate clock differences. It is not
a big problem to use both in the same network and even between same nodes
weighting the result according to QoS.

The protocol should not synchronize or trigger anything. The latter is an
application-level issue. The former is impossible for described above
reasons and is not required anyway.

If you can schedule actions ahead of the time and know clock differences,
that is the best real-time possible. Since you will never get latencies
shorter than the board can switch contexts anyway.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de