At 16:41 Uhr +0200 22.04.1999, Ulrich Hausmann wrote:
>Bill,
>
>isn't AppleTalk since the very first beginning at 230.400 bps? I think
>even a MacPlus ser port supported that speed. OTOH, as far as I know
>the ser port speed went down, if running at the same time networking
>and ser port connecting activities.

OK, I'm not Bill, but since I am currently into those issues...
LocalTalk (the physical link, not AppleTalk, the protocol) runs the SCC in
polled mode. AFAIK the SCC has some HW support for detecting certain
address tokens on the line so that the CPU need not listen all the time,
but when data is coming in/going out by LocalTalk, not much else is
happening on a (non-IOP/DMA) Mac. All interrupts are disabled then, even
the other serial port is polled. - This is very similar to floppy I/O, btw.

>There are some programs (like ProTERM, FreePPP), allowing you to set
>the port speed higher than 57.6 and it seems to work - sometimes.
>
>May I ask a somewhat related, but not NetBSD question (since you're a
>serial connection guru here :)) ): Would it be better to use a
>IIfx/Quadra 900/950 with the built in serial I/O controller on or off.
>In case of OFF FreePPP allows 230.400 bps (in case of ON only 57.600
>are accepted, possibly because the controller tells FreePPP so).
>Practically, with a LASAT 56K V90 modem attached, performance - to me,
>but it's only an impression - seemed better with the Serial Switcher
>set to ON and consequently port speed set to only 57.600.

With asynchronous, interrupt-driven I/O, there are two issues:

CPU LOAD
-- on every interrupt, the cpu has to save its state, get a char from the
SCC or deliver one to it, evaluate SCC status, restore its state and return
to its previous occupation. Further processing of the I/O data happens
"when there is time" - packet assembly, checksums etc. When SCC interrupts
follow too fast, the  cpu does nothing but interrupt processing.
Eventually, the buffers for serial I/O flow over.

INTERRUPT LATENCY
-- the SCC has a three byte fifo. I.e. to avoid dropping data, you must
access the data register in intervals not larger than 3 *
1/bytes_per_second , and this is a hard limit. With packet-oriented data
transmission, a dropped char means retransmission of an entire packet:
between 250 and 1500 bytes.
There are many places in the kernel where even the highly prioritized
serial interrupts have to be blocked - because they would interfere with
data structures or simply because there is no time now for serving
interrupts (like during floppy I/O). When interrupts are blocked longer
than the above interval, data is lost.

In the example you mentioned, with 230kBPS the machine gets flooded with
interrupts and packets are frequently retransmitted (you don't usually see
that in MacOS). Running with the IOP on and with lower speed helps because
load is taken off the 68k twofold, resulting in a net gain although the
nominal data rate is lower.

	hauke


--
"It's never straight up and down"     (DEVO)