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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,3e3949298ed3b36 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!newsfeed1.uni2.dk!news.get2net.dk.POSTED!53ab2750!not-for-mail Sender: malo@0x52b411d3.dhcp.kabelnettet.dk Newsgroups: comp.lang.ada Subject: Re: High CPU in tasking References: From: Mark Lorenzen Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 25 Jun 2004 23:15:17 +0200 NNTP-Posting-Host: 82.180.17.211 X-Complaints-To: abuse@colt-telecom.dk X-Trace: news.get2net.dk 1088198048 82.180.17.211 (Fri, 25 Jun 2004 23:14:08 CEST) NNTP-Posting-Date: Fri, 25 Jun 2004 23:14:08 CEST Organization: Colt Telecom Kunde Xref: g2news1.google.com comp.lang.ada:1901 Date: 2004-06-25T23:15:17+02:00 List-Id: Lutz Donnerhacke writes: > In order to stop others falling into the same mistake, I debugged several > days. > > I wrote an data stream decoder and output (via TCP) manifolder using Ada > tasking and a protected ringbuffer. The whole application word fine, but the > CPU load increased linear on input load and dramatically over the number of > output queues. > > Debugging turned out: > - Every writing to the ringbuffer wakes up all reader tasks. > - That's why the reader buffers were filled with only the little data amount > just written. > - Tasking overhead caused the CPU load. > > Two solutions (used both): > - The ringbuffer got a minimum reading length => Fewer wakeups. > - The writer task collect a lot of data before writing > => Fewer checks for wakeup. > > The ratio of tasking events before and after the change is about 30:1. > > Conclusion: > When implementing tasking synchonisation with protected objects, > keep in mind, that the standard Ada tasking model generates a near real > time experience, which is mostly not required. > > HTH These are some very good observations regarding soft- vs hard real-time systems. In soft real-time systems we often want high throughput and gladly sacrifice responsiveness. A favorite design of mine, is to have one task for each interface, that encapsulates all the horrible properties of the interface f.x. TCP's chopping of data and so on. When a complete message, telemetry frame or whatever has been read, it can be put into a queue for further treatment. Just like when your writer collects a lot of data before writing. If it is necessary with a lot of readers, you may find out that one task for each reader is not the right solution, but one task for many readers should be used. In very high performance systems, you may want one task for each network interface card on the computer in order to avoid that the tasks compete for the limited resource (i.e. the NIC). One task would then serve many TCP sessions and buffer write requests in a way so that it can write large chunks at a time. Do not underestimate the overhead from tasking. Regards, - Mark Lorenzen