From: johnston@me.udel.edu (Bill Johnston)
Subject: Re: Virtual memory kills hardware flow control
Organization: University of Delaware
Date: Fri, 28 Aug 1992 04:44:04 GMT

In article <17k506INN184@mohawk.cs.utexas.edu> newton@cs.utexas.edu (Peter Newton) writes:
>I have been trying to get hardware flow control working between a IIsi
>and a SupraFAX v.32bis modem and have noticed something interesting.
>It appears that when virtual memory is enabled, the Mac no longer
>correctly performs hardware flow control.
[...]
>Here's how you test.  You need to be using a v42 bis modem that runs
>at 9600 or 14400 bps.  Use Zterm 0.9 and upload (send *from* your Mac)
>a file of at least 100k.  Downloading is not a good test.  I used a
>gif file.  You must use the zmodem file transfer protocol since most
>others do not need working flow control.  Set ZTerm's speed to 57600.
>I can also produce the problem with ZTerm set to 19200.  If you can
>send the file with no retries when virtual memory is off but cannot
>when it is on, you are seeing the problem.  Of course, you need to use
>a hardware flow control modem cable and set Zterm to use hardware flow
>control. 

Nothing wrong with the experiment, but the diagnosis is wrong.

First, the Mac serial ports do very little buffering and thus 
must have enough free cycles available to pay close attention to 
the serial ports.  The same problem applies to PCs running
old serial cards -- questions related to replacing serial card
UART chips with ones with more buffer space are a daily FAQ in 
comp.dcom.modems.

A second factor is the MacOS itself.  Without preemptive 
multitasking, the OS has no way to allocate time slices on 
a needs basis.  The only way to be sure of getting enough
cycles for the serial port is to have enough CPU power in
reserve to make sure that the comm app gets to look at the 
serial port often enough.  Any app that is not "multifinder-
friendly" can seriously hurt throughput by holding on to
the CPU long enough to let the buffer overflow.  Once again,
the same problem applies to people running Windows on PCs.

Finally -- and this is where virtual memory comes in -- 
SCSI takes a big chunk of the CPU during read/write.  
With VM on and lots of apps open, the Mac ends up hitting 
the disk frequently.  Size matters too;  unless an app is
designed to to copy files in bite-size chunks like the Finder, 
apps that try to save a large file like a modified .sit or
.cpt file may do several minutes of disk access without 
yielding the CPU.

Until we have a preemptively multitasking, multi-threaded
operating system and 100 MHz PowerPCs, the best way to keep 
Mac telecommunications running smoothly is to understand how 
the Mac works, and don't try to ask it to do the impossible.  

One practical measure is to keep DTE at 19.2 even with modems 
that can go faster;  setting DTE at 38.4 or 57.6 with a v.32bis
modem may give a marginal improvement in screen speed for reading 
text files with a comm app running in the foreground, but it 
will actually worsen throughput when transferring compressed
files.  The modem-to-modem `DCE' rate is independent of DTE
setting, and the built-in data compression (MNP 5 or v.42bis) 
can only handle the extra DTE speed if the data itself is 
compressible.  Even with a 50 MHz accelerator, I still get
the best throughput for compressed data with DTE at 19.2.
Just because one _can_ set DTE to 57.6 with a v.32bis modem 
doesn't mean that it's best to do so.

-- Bill (johnston@me.udel.edu)
-- 
-- Bill Johnston (johnston@me.udel.edu)
-- 38 Chambers Street; Newark, DE 19711; (302)368-1949
Xref: sparky comp.sys.mac.comm:8451 comp.os.vms:14288 comp.mail.misc:2839