another bizarre architecture
in [Embedded]
|
From: Paul Keinanen on 9 Feb 2007 14:40 On Fri, 9 Feb 2007 14:48:51 +0000 (UTC), kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <1171028058.046574.318680(a)q2g2000cwa.googlegroups.com>, >Didi <dp(a)tgi-sci.com> wrote: >>> which is, of course, event driven software. which is (AIUI) what windows >>> is all about. perhaps that explains it. >> >>You must be joking? While event and interrupt are quite different >>things, >>to claim that windows is "event driven" with its many seconds range >>latencies is laughable at best. A wanna-be event dirven, may be :-). > > >"Event driven" is a classification of how something operates. A "Pinto" >was a car. Windows uses the event FIFO model. This ensures that the >events are taken in turn. It doesn't ensure that they are acted on >quickly. This model actually makes it harder to react quickly to events >but it saves having to implement event commutation. Consider this >happening: > >Disk operation complete >Mouse moved to the right 10 mickeys >Printer port interrupt >Serial interrupt >Mouse button clicked > >You can safely move the mouse action down the list to after the serial >interrupt. In an interrupt priority system it could be. Windows, however >can't easily do this sort of thing, What you are describing sounds very much like the 16 bit Windows 3.x style single thread system as well as 32 bit windowed applications. However, at least in the Windows NT family, you can run console multithread applications with ordinary main() and synchronisation primitives similar to those used in RSX11/VMS. If the timing is important in your Windows application, stay away from windowed applications and use console applications instead. Paul
From: Grant Edwards on 9 Feb 2007 15:12 On 2007-02-09, Paul Keinanen <keinanen(a)sci.fi> wrote: >>>tell me about it. A couple of years back I developed some >>>testers that used a PC to talk to a range of little blue I/O >>>boxes. The PC(s) were >= 1GHz pentiummyjigs, and our pc guru >>>(who is good) couldnt even get a guaranteed 1ms interrupt out >>>of the poxy OS. >> >> >>There are special drivers for serial ports that get about that >>sort of timing. >> >> >>The trend these days is to offload the work from the PC to some >>external box. This way you can have the PC only set the >>parameters and run the user interface. The actual work is done >>by a much more capable processor such as an 8051. > > While there are protocol specific intelligent I/O processors > doing all the protocol handling, but for instance RocketPort > 8-32 line multiplexor cards simply implement deep Rx and Tx > FIFOs for each channel in an ASIC. No interrupts are used, but > the driver scans all Rx FIFOs once every 1-10 ms and each FIFO > is emptied at each scan. The Tx side works in a similar way. > > The latency with such cards does not depend so much about the > number of active channels or number of bytes in a channel, but > rather about the scan rate. So if the scan rate is 10 ms, the > Rx-processing-Tx two way latency is 10-20 ms regardless of > number of lines. With 115200 bit/s, there can be about 120 > character at each scan with 10 ms scan rate. However, if the > received message ends just after the previous scan, there can > be a more than 100 character time pause before the response is > sent. As one of the maintainers of that driver, I thought I might comment on the reasoning behind the decision not to use an interrupt-driven scheme. For a few channels with sporadic data flow, using interrupts makes a lot of sense -- the driver isn't using up CPU time unless there is data to be transferred, and data is handled with low latency. However, the RocketPort driver is intended to support a large number of channels with high throughput rates: it supports up to 256 serial ports at 921.6K baud all in use at 100%. For a large number of ports with heavy usage, polling the boards at a fixed interval results in a much lower overhead than handing interrupts from up to 256 different UARTs. There's a definite trade-off between low-latency and efficient high-throughput, and the RocketPort driver leans towards the latter. [Though CPU speed has increased so much that polling at 1ms isn't really much overhad and provides pretty good latency.] -- Grant Edwards grante Yow! PARDON me, am I at speaking ENGLISH? visi.com
From: nospam on 9 Feb 2007 16:16 "Didi" <dp(a)tgi-sci.com> wrote: >> The delay between input and output edges was nominally 17us -0 +4 which >> occasionally stretched to +15 during intense disc activity. The system was >> quite happy taking interrupts at 10kHz. > >While 17 uS is a bit too long for a GHz range CPU, this is a sane >figure. But the PCI bus doesn't run at GHz and has lots of overhead for a single cycle I/O access. On the same system the minimum width of a software generated pulse on an I/O line was about 4us. --
From: Paul Keinanen on 9 Feb 2007 17:14 On Fri, 09 Feb 2007 20:12:08 -0000, Grant Edwards <grante(a)visi.com> wrote: >On 2007-02-09, Paul Keinanen <keinanen(a)sci.fi> wrote: >> While there are protocol specific intelligent I/O processors >> doing all the protocol handling, but for instance RocketPort >> 8-32 line multiplexor cards simply implement deep Rx and Tx >> FIFOs for each channel in an ASIC. No interrupts are used, but >> the driver scans all Rx FIFOs once every 1-10 ms and each FIFO >> is emptied at each scan. The Tx side works in a similar way. >> >> The latency with such cards does not depend so much about the >> number of active channels or number of bytes in a channel, but >> rather about the scan rate. So if the scan rate is 10 ms, the >> Rx-processing-Tx two way latency is 10-20 ms regardless of >> number of lines. With 115200 bit/s, there can be about 120 >> character at each scan with 10 ms scan rate. However, if the >> received message ends just after the previous scan, there can >> be a more than 100 character time pause before the response is >> sent. > >As one of the maintainers of that driver, I thought I might >comment on the reasoning behind the decision not to use an >interrupt-driven scheme. For a few channels with sporadic data >flow, using interrupts makes a lot of sense -- the driver isn't >using up CPU time unless there is data to be transferred, and >data is handled with low latency. > >However, the RocketPort driver is intended to support a large >number of channels with high throughput rates: it supports up >to 256 serial ports at 921.6K baud all in use at 100%. For a >large number of ports with heavy usage, polling the boards at a >fixed interval results in a much lower overhead than handing >interrupts from up to 256 different UARTs. No doubt, the RocketPort cards are targeted for ISPs running a large number of modem lines using a full duplex protocol like PPP. In such applications, the scan rate or line turn-around time is really not an issue. However, in any half-duplex protocol, the latencies and line turnaround times can seriously degrade the system throughput. A 10 ms delay at 115k2 corresponds to 120 character dead time, which is catastrophic for the throughput when using short messages. >There's a definite trade-off between low-latency and efficient >high-throughput, and the RocketPort driver leans towards the >latter. [Though CPU speed has increased so much that polling at >1ms isn't really much overhad and provides pretty good >latency.] The 1 ms poll rate has not been an issue even at processors below 1 GHz. While the poll rate for Linux 2.4 drivers was usually 1/HZ, I stumped on some driver version that forced 10 ms poll time even for kernels with HZ >100. When forcing the poll rate to 1 ms (HZ=1000), the throughput and latency performance was quite acceptable at serial speeds below 115k2. Paul
From: Ken Smith on 9 Feb 2007 21:43
In article <9bgps25hbjcipmh2kjrtq3m475bhfg0gbs(a)4ax.com>, Paul Keinanen <keinanen(a)sci.fi> wrote: >On Fri, 9 Feb 2007 14:48:51 +0000 (UTC), kensmith(a)green.rahul.net (Ken >Smith) wrote: [....] >>Disk operation complete >>Mouse moved to the right 10 mickeys >>Printer port interrupt >>Serial interrupt >>Mouse button clicked >> >>You can safely move the mouse action down the list to after the serial >>interrupt. In an interrupt priority system it could be. Windows, however >>can't easily do this sort of thing, > >What you are describing sounds very much like the 16 bit Windows 3.x >style single thread system as well as 32 bit windowed applications. Yes applications that are tied to the user interface have the problem right up at the surface. In other applications, the FIFO model is more hidden but it is still there under the surface. The task dispatching still tends to take the task in the order of the events. The code does not run very much as interrupt code. When the interrupt happens, the fact is recorded and then the code returns to being non-interrupt code. It is the what happens next that matters at this point. >However, at least in the Windows NT family, you can run console >multithread applications with ordinary main() and synchronisation >primitives similar to those used in RSX11/VMS. You still can't get quick responce times on things like serial ports. The problem is at the OS level. >If the timing is important in your Windows application, stay away from >windowed applications and use console applications instead. > >Paul > -- -- kensmith(a)rahul.net forging knowledge |