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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: silly ravenscar question Date: Thu, 26 Feb 2015 10:47:49 +0100 Organization: cbb software GmbH Message-ID: References: <8e30f54c-81c4-4861-897c-bb6c563c76e8@googlegroups.com> <14r7a7x3kyv4t.13luzs6ukxqiq$.dlg@40tude.net> <647ebb7f-61fd-4e36-b047-3207ea789807@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: OpkKbm9QwHUq0Y4SxjI2mw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:25043 Date: 2015-02-26T10:47:49+01:00 List-Id: On Thu, 26 Feb 2015 00:48:01 -0800 (PST), jan.de.kruyf@gmail.com wrote: > On Wednesday, February 25, 2015 at 7:55:59 PM UTC+2, Dmitry A. Kazakov wrote: > >> We managed 0.2ms with 4 channels without oversampling, transported over XCP >> under VxWorks. XCP is a UDP-based protocol. The data were coalesced into >> one frame. > > what processor, what clockspeed, what net topology? i7, I don't remember the frequency, some average CPU and motherboard. BTW, a high end motherboard may turn actually slower in terms of latencies. As for the network topology it was an industrial-grade one, a cross-over cable (:-)). [ Switches we measured imposed latencies somewhere between 6 and 15 microseconds. ] > But it is probably as good as it gets with prefab software. > openPowerlink was reported to have a latency up to 450usecs Sync to 1st. I never worked with it, but from the short description I read, looks like they try to mimic CANOpen-nonsense and have master/slave architecture. Not good. We are using a proprietary TCP/IP based protocol (LabNet) for distribution between the nodes. It is a design question about the field bus network topology, in particular switch vs. chained nodes (like in EtherCAT). Real-time crowd will try to convince us that the only way is chained nodes, but I honestly believe that normal networks will eventually win. >> This is one case when you trade latencies for throughout. In other cases >> latencies are more important, e.g. for control and for time >> synchronization. The latter is the weakest spot of all existing field >> buses. Most of them do not have any, others have a garbage clock >> synchronization, like EtherCAT's distributed clock is. > > STM implements the hardware for Precision time protocol IEEE1588 PTP. > So its up to me to implement the software properly. It promises precision > in the sub usec range. Personally I think its quite doable, provided the > latency from packet arrival through software has little or no jitter. OK. However, it is not much an issue to reduce latencies in time synchronization as to actually to use it to compensate clock drift (not necessarily by tuning the clocks) in order to allow the subscriber to get data stamped by the *subscriber's* clock. The problem with actual protocols is that they do it by the *publishe's* clock. 0.005ms accuracy of clocks shift estimation is achievable using normal network stack. The best ADC we ever had had 0.040ms conversion time. So it need not to be hardware clock synchronization, but nice to have, of course. > Otherwise I do not see great problems getting your data collection issue > sorted out. Yes. But you know, once you give customers 8 10kHz channels they start looking forward 16 channels... (:-)) > The numbers I gave you are definitely squeezable, that was just a budget. > The pc side is another kettle of fish though. There is a software stack > around that promises things like 10usec cycletime on RTAI but there is no > indication of the packet size or the net topology. Maybe, but we must keep a big picture. It does not make sense to sacrifice for making latencies 50% shorter. Latencies are not the issue most of the time, though customers will always tell you otherwise. They lie. The real problem is having it configurable, scalable, usable. > But then there is still the digesting of the data. Do you plan to store a > sample in memory for some time? Usually data are stored away to be analyzed later. Typically it is a data-logger which continuously writes a log file. Another subscriber to the data is the HMI, which may render some curves. Yet another is a health monitoring subsystem etc. > any hardrive activity will most likely bug > the cycle response, Not really. The architecture is usually such that the controlling unit is physically separate from the logger, or the HMI. E.g. consider an EtherCAT installation. There is a controller (an industrial PC) running Linux or VxWorks with an EtherCAT master. It does all real-time work. It also samples the high-speed channels and publishes them over the middleware. The data logger is another PC which subscribes to it. But there would be no problem to use a hard drive because the control cycles are 1-10ms. At least in the application area I am working in, there is no processes requiring control under 1ms. Any normal PC can do that. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de