Subject: Re: silo overflow contd.
To: None <amiga@NetBSD.ORG,>
From: Niklas Hallqvist <>
List: amiga
Date: 10/20/1994 15:13:37
CC: amiga@NetBSD.ORG
In-reply-to: <> (message from Marc Duponcheel on Thu,
	20 Oct 1994 11:30:44 GMT)
Subject: Re: silo overflow contd.

>>>>> "Marc" == Marc Duponcheel <> writes:

Marc> Hello NetBSD Amiga, I read the 'silo overflow' talk and it says
Marc> that basically the hardware is too slow ... (if I understand
Marc> well)

Marc> But why then is it that using the *same* hardware (under
Marc> AmigaDOS) I get much performance ? (e.g. ftp: 1500 cps -> 2000
Marc> cps).

We're not really discussing performance here, but rather
responsiveness.  Yes, I agree, lost characters induces performance
problem due to packets needing to be retransmitted and such.
But, it wouldn't have to be so, with smart protocols knowing
the nature (statistics) of these glitches.  Anyway, what we need
to improve is the responsiveness of the system.  This is easiest
done by getting better hardware, although it's not the hardware's
fault.  Well, whose fault is it then?  NetBSD, being significantly
different from AmigaDOS, in it's nature is less responsive.  The
kernel spends more time in critical regions where serial interrupts
is put on hold.  Besides much of this code is written in an
architecture-independent fashion which makes it hard to optimize
for the Amiga case specifically.

What can we do to improve the situation without getting new HW?
One way would be to measure spl* protected regions starting at
level 5 and up, to see where long stalls occur.  Then try to
optimize these paths.  Perhaps check out how your SCSI DMA works
(GVP DMA stalls the machine badly) and change the SCSI maximum
transfer size if that seems to be a problem.  Even dropping DMA
going to programmed I/O could help.  If you have memory of different
speeds, try to make sure high-spl-level activity will only deal
with fast memory.  Likewise for stalling DMA architectures.  I may
try something but I don't know.  Now, when I have the option to
use a 16550-based serial card instead I just may go that way.