On Monday 21 March 2016 06:04:52 Nicklas Karlsson wrote: > > >>> ... > > >>> Modern disclaimer: I have no clue what sort of priority is given > > >>> DMA by todays crop of CPU's. Sure they've gotten faster, but > > >>> are they better? > > >> > > >> It's a bit off-topic, but anyways: DMA controllers in recent > > >> microcontrollers can be quite complex beasts, far from a simple > > >> incrementing pointer for copy operations. Some use dynamic > > >> descriptors in memory, which hold the DMA configuration. One of > > >> the config options in each descriptor holds the address of the > > >> next descriptor. With this, you can generate "any number" of such > > >> descriptors and then start the DMA with the address of the first > > >> and it will (optionally looping forever) copy N words from here > > >> to there, then M words from foo to bar, followed by K words, etc. > > >> without any CPU intervention at all. Usually it is also possible > > >> to trigger the DMA using a hardware timer, so you could get away > > >> without any interrupt for this transfers at all. But of course > > >> the DMA controller has to access the bus as well, so if the CPU > > >> is doing some heavy memory access on its own, the DMA may be > > >> slowed down quite much. > > > > > > Are you sure CPU slow down DMA and not the opposite? > > > > Depends on the priorities, the DMA may be configurable to get higher > > priority than the CPU. But I'd suspect the "CPU comes first" > > approach to be more common, as the CPU should usually be busy with > > not so memory intensive tasks, so performance will increase if it > > only has to take the bus every once in a while and continue > > immediately with its work, while the DMA is using all the rest of > > the bandwidth. > > > > Bye, > > Philipp > > Ideally DMA priority should depend on how often transfers are done and > scheduling priorities assigned according rate monotonic since a clock > cycle blocked by memory bus busy essential use that clock cycle. > > ADC may be around 1MHz altough only one read/write each time so this > should certainly have higher priority than any CPU task. If DMA is > used for Ethernet packets and they are transferred at 1kHz while there > are a faster servo loop it should however have lower priority than > servo loop. > > I read somewhere about graphic cards on ordinary computers doing huge > DMA transfers blocking CPU and they should certainly have lower > priority than faster real time tasks.
Rant mode on: They do, but once the IRQ that starts the DMA has been granted, there is apparently no way in creation to interrupt it for a far higher priority but only two byte write & confirming read to a parport. NVidia in particular will not give up control until it has done whatever the heck it thinks it has to do. The nouveau driver OTOH seems to be quite well behaved. So does some of the onboard intel i915 stuff, I have two D525MW based machines that can do software stepping at the lower motor speeds quite nicely as the IRQ latency for that read/write is in the 3 to 4 microsecond territory with that read/write scheduled at every 25 microseconds. So while we do use NVidia cards, we don't let their drivers come across the property line. The amd/ati merge may have changed things there, but generally speaking we do not use any ati based cards either, not because the driver is a cpu hog to that 100+ milliseond lockout extent, but without their driver its noticeably slower & the display may be as much as a full second behind what the machine is doing, and with the ati drivers, uptime was measured in hours or less. Couple that with the fact that Alex would tell you card such and such was now supported, but when you went shopping for that card and bought one, the box hadn't changed even the color of a dot on an i, but the card in the box was a newer production and STILL incompatible with any driver available. And no apologies when confronted. So you run it in vesa mode, getting unsquare pixels on modern 16x9 monitors and half what your monitor can do for resolution until you can get back to town and get an NVidia card. Net result is I wouldn't trust what Alex told me if he said it was lunch time and I could smell hot food. If, with the merger, things have improved in that dept, please advise me as I will not waste another 100 dollar or more bill to find out, I blew at least $500 over the last 17+ years since my first linux build and install, trying to support "the little guy", but wound up in driver hell everytime. That's plenty of the "quarter to call somebody who cares" when there wasn't anybody who gave a damn if it worked on linux on the other end of the line. IMO, its up to them now. If they work now, thats great, but unless I am told they do work, and work well... I'll continue to buy NVidia econocards. /Rant mode. > I would however guess it is > possible to speed up memory accesses if they are done sequentially and > ordinary computers are known to maximize throughput. > > > This is the ideal situation then the hardware of course have > limititions. > > > > Nicklas Karlsson > > ---------------------------------------------------------------------- >-------- Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
