another bizarre architecture
in [Embedded]
|
From: John Larkin on 9 Feb 2007 22:47 On Fri, 09 Feb 2007 21:16:35 +0000, nospam <nospam(a)please.invalid> wrote: >"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. But what was the *maximum* width of that pulse? I'd expect that, under Windows, the probability tail is still nonzero at some number of seconds. John
From: nospam on 9 Feb 2007 23:35 John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Fri, 09 Feb 2007 21:16:35 +0000, nospam <nospam(a)please.invalid> >wrote: > >>"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. > >But what was the *maximum* width of that pulse? I'd expect that, under >Windows, the probability tail is still nonzero at some number of >seconds. It was generated in a driver interrupt handler so the maximum was also about 4us barring PCI bus contention from other bus masters. --
From: Paul Keinanen on 10 Feb 2007 04:03 On Sat, 10 Feb 2007 02:43:52 +0000 (UTC), kensmith(a)green.rahul.net (Ken Smith) wrote: >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. Sounds like all the treads waiting for various events are running at the same priority level. On older Windows NT versions, only the tread priority levels 16, 22-26 and 31 were available in the realtime priority class, so assigning priorities to various threads was quite tricky. Starting from Windows 2000 the levels 16-31 are available. In non-realtime priority classes, round-robin scheduling and priority boost for interactive threads etc. makes predicting timing more or less pointless. Paul
From: Didi on 10 Feb 2007 04:11 > 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. Sounds like the delay has been down to bridging to/from the PCI bus, PCI is much faster than that. Maximum latencies can get large because of bus (req/grant etc.) delay, but minimum (when the bus is free or owned) are much below 1uS. However, for a monstrous mess like the x86 your figures are about the best one could expect, sound quite reasonable. Dimiter On Feb 9, 11:16 pm, nospam <nos...(a)please.invalid> wrote: > "Didi" <d...(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: Ken Smith on 10 Feb 2007 11:55
In article <0m0rs2dn5ft27b6gtpm6f396o19nj0j91p(a)4ax.com>, Paul Keinanen <keinanen(a)sci.fi> wrote: >On Sat, 10 Feb 2007 02:43:52 +0000 (UTC), kensmith(a)green.rahul.net >(Ken Smith) wrote: > >>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. > >Sounds like all the treads waiting for various events are running at >the same priority level. Not all of them have to be at the same priority for the effect to be seen. The event just needs to pass through a thread to end up being timed at that threads priority even if the thread waiting for that thread to finish dealing with it is at some other priority. >On older Windows NT versions, only the tread priority levels 16, 22-26 >and 31 were available in the realtime priority class, so assigning >priorities to various threads was quite tricky. In spades. Starting from Windows >2000 the levels 16-31 are available. > >In non-realtime priority classes, round-robin scheduling and priority >boost for interactive threads etc. makes predicting timing more or >less pointless. > >Paul > -- -- kensmith(a)rahul.net forging knowledge |