From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.43.6.5 with SMTP id oi5mr213190icb.11.1425372171886; Tue, 03 Mar 2015 00:42:51 -0800 (PST) X-Received: by 10.140.34.56 with SMTP id k53mr417908qgk.19.1425372171753; Tue, 03 Mar 2015 00:42:51 -0800 (PST) Path: border1.nntp.dca1.giganews.com!nntp.giganews.com!hl2no3179419igb.0!news-out.google.com!n6ni191qar.0!nntp.google.com!w8no51988qac.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 3 Mar 2015 00:42:51 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.210.1.233; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.210.1.233 References: <8e30f54c-81c4-4861-897c-bb6c563c76e8@googlegroups.com> <14r7a7x3kyv4t.13luzs6ukxqiq$.dlg@40tude.net> <647ebb7f-61fd-4e36-b047-3207ea789807@googlegroups.com> <1p3tujcfe2x5b$.njfp7g1kpm79$.dlg@40tude.net> <4d288aff-66c7-49d8-8ffd-8fc80e9355c5@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <12b6815b-a38a-4a11-b9ae-dddd2811e500@googlegroups.com> Subject: Re: silly ravenscar question From: jan.de.kruyf@gmail.com Injection-Date: Tue, 03 Mar 2015 08:42:51 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.giganews.com comp.lang.ada:192385 Date: 2015-03-03T00:42:51-08:00 List-Id: On Sunday, March 1, 2015 at 11:28:01 AM UTC+2, Dmitry A. Kazakov wrote: > > But the point is you cannot have it well synchronized over Ethernet witho= ut > time stamping. Synchronized slaves is the second scenario I described, > which apply even more for 100BASE. In the core it is triggering synchrono= us > actions by a *local* timer derived from incoming protocol packets/frames > rather than directly from the frames. Yes, so IEEE lays down a packet exchange for synching that measures the cab= le delay and gives the real time for each packet at sending. (it is done by= hardware timestamping at exit, in the NIC or PHY) and timestamping at ent= ry. and both parties know about the exit time on the other side, it is send in = a second message, since it can only be read once the message is gone. >=20 > And from the software perspective, the idea that you could enforce > real-time/synchronicity per real-time protocol is flawed. More complex th= e > 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-pac= ket-sending must be done, as the incoming packet leaves the dma channel. Pr= eferably even without any interrupt on a micro controller, cause before you= know it some clever new feature has increased the latency, and worse: made= it variable. In any case let me study a bit more. The linux ptpd stack people got accura= cies of about 15 usecs between 2 boxes with kernel timestamping only. With = hardware timestamping it will go well below 1usec.=20 So that is the difference between software and hardware _in the terminals_ but there is also the variable delay in a network switch. For that there is= also some clever trick but I am not sure I need that at the moment. It certainly is important as the network layout grows. > And you still need to adjust terminal time sources or translate their > readings to and from master clock. > =20 yes, people have experimented synching it with ntp (frome some outside real= time server) I did not delve into that at all yet. So to sum up: To me there are broadly 3 alternatives 1. a sync pulse broadcast every scan period, which triggers the data readin= g 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 mas= ter. 2. Synchronize a whole subnet to itself. this is very attractive since with= a good algorithm the individual boards will track one-another quite perfec= tly and dead terminals give no real problem. ( If you can imagine a flock o= f birds making a turn: each bird only sees what the nearest neighbors do an= d reacts accordingly) against:=20 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 netw= ork traffic involved, since all exchanges between neighbors must happen ove= r 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.=20 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. Cheers, j.