On Fri, 09 Feb 2007 20:12:08 -0000, Grant Edwards <grante@visi.com>
wrote:

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.

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

In article <9bgps25hbjcipmh2kjrtq3m475bhfg0gbs@4ax.com>,
Paul Keinanen <keinanen@sci.fi> 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.

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.

You still can't get quick responce times on things like serial ports. The
problem is at the OS level.



--
--
kensmith@rahul.net forging knowledge

On Fri, 09 Feb 2007 21:16:35 +0000, nospam <nospam@please.invalid>
wrote:

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

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

It was generated in a driver interrupt handler so the maximum was also
about 4us barring PCI bus contention from other bus masters.
--

On Sat, 10 Feb 2007 02:43:52 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) wrote:

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

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...@please.invalid> wrote:

In article <0m0rs2dn5ft27b6gtpm6f396o19nj0j91p@4ax.com>,
Paul Keinanen <keinanen@sci.fi> wrote:
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.

In spades.


Starting from Windows

--
--
kensmith@rahul.net forging knowledge

Vladimir Vassilevsky wrote:

Before the time i have a 100 states in a state machine is look to "refactor"
it into multiple interacting state machines of less than 12 states each.

--
JosephKK
Gegen dummheit kampfen die Gotter Selbst, vergebens.Â*Â*
--Schiller