Re: 28.8K modem, pppd and Multiface III card

[Bruce Drake <bruce%synxcti.com@localhost>]

On Wed, 21 Aug 1996, The Terminator rAT wrote:

> Bruce Drake writes:
>  > Are there any other experiences out there?  I wouldn't mind hearing from
>  > you myself.
> 
> Here's a weird (well, maybe not so weird...) effect of PPP/A3000 serial...
> 
  snip snip
> 
> However, running Xdaniver and Mosaic2.7b4, I am unable to even load the
> Yahoo! home page.  It appears that TCP loses, as I see periodic blinks of
> the TX light, indicating retransmissions of packets.  I have left it for
> half an hour to go shopping and come back to find it had managed to load
> just under a kilobyte from the server.  It appears that every packet
> transmitted generates at input or output errors and must be retransmitted
> several times.  Interestingly, the request usually gets through fine -- 
> it's only when the server attempts to respond that the PPP fails.

ugh!

> 
> The interesting thing about this effect is that if I reconfigure PPP to 
> run at 19200 baud, I get fairly impressive performance from Mosaic.  
> Pages load right up, etc, etc.
> 
>       - add '38400' to /etc/ppp/options, kill and restart pppd
> 
>       - start Mosaic.  go to lunch.  come back -- it has loaded 512 bytes
>               from the remote server (only 7 hops away!)
> 
>       - kill Mosaic
> 
>       - change '38400' to '19200' in /etc/ppp/options.  kill and 
>               restart pppd
> 
>       - start Mosaic.  Watch as it happily loads any page I ask for...
> 
> I assume this is some weird interaction between X, Mosaic, and the serial 
> port interrupts.  Anyone have speculations beyond this?
> 

My guess is that since you have 10MB of memory (actually 8MB + 2MB display
memory as far as NetBSD is concerned), your machine has to be swapping
heavily just to be able to run Xdaniver, and then you are running Mosaic
on top of that.  This means that I would expect port communications to be
slow because of all the swapping.  However, this doesn't in and of itself
completely explain the slowness across your PPP link.

Some things to keep in mind when operating under these conditions:

1) Swapping means that most things (not all) are nearly stopped while the
Virtual Memory (VM) part of the kernel has control.  Tasks will still
switch, but then you have to swap it all over again :-)

2) 8 MB is running fairly tight when using X windows.  You will already be
swapping just to bring it up.

3) Mosaic is a large application in memory, at least 5MB while idle with
nothing loaded.

4) pppd, the user-space part of PPP communications, can get swapped out
too sometimes.  Yes, other parts of PPP are in the kernel.

5) Features of TCP/IP can get in the way.  When a machine swaps often (or
constantly), the time to respond to an incoming packet can be quite large,
causing retransmission timeouts.  What happens then is that the other end
now has to reject the extra packets, taking more time.  When you add the
"feature" of modern routers to favor low-response-time net packets into
the mix, you end up with artifically high network propogation delays added
at every router.

6) PPP can be thought of as an HDLC protocol wrapped around your TCP/IP
packets, adding overhead and its own timeouts/error correction to TCP/IP
whether it needs it or not.  This adds time and more things for your
modem to compress.

7) Interrupts arriving at the rate of 1920 per second to support 19200 bps
instead of 3840 per second (38400 bps) to support 28800 bps will save the
kernel a LOT of work.  Other important things will get done besides serve
the serial port interrupt handler.  Although I don't have the Motorola
manuals handy, there is a definite maximum interrupt rate each type of CPU
can handle, not counting Operating System overhead.  The safe maximum for
the 68030 @ 25MHz and NetBSD is just around 2500-3000 or so I would guess. 
That seems like a lot, but it isn't.  To support the internal serial port
at 115200 bps, you would need 11520 interrupts a second from the CPU/OS!
A hardware FIFO would alleviate the interrupt demand.

8) I said all the above to say this.  By the time all the above happens
(and more, I suspect), one missed character could cause whole _minutes_ of
delay PER PACKET on a slow link, compounded by a weak ISP's inability to
carry your throughput to the backbone well. 

Although it may seem that adding memory is the "one size fits all"
solution to the above cascade of events, I will caution that there are
several factors involved, not just swapping processes.  BTW, I have 12MB
of fast memory, and it helped my system tremendously.  I plan to add
another 4MB real soon now, and I expect another performance boost.

One more thing to keep in mind, a 68030 at 25MHz or less is a little weak
to run X, X apps, and the old Amiga chipset display code all at once.  If
you add the fact that Xdaniver uses as much of the display width as
possible, the chip memory's bandwidth is just about used up, and other
devices like the internal serial port will suffer as a result.  This is
where using another video display card is a win in overall machine
performance, even if you have to use the CPU to do all the graphics (and
not the blitter). 

I suspect, but have no hard evidence to prove, that NetBSD could be tuned
to perform better on slower machines in regards to serial ports and other
interrupt-intensive activities.  Perhaps someone In The Know (tm) can
elucidate further?

------------------
Bruce Drake
Synectics, Inc.
(919) 872-1275 USA