From: Mike Wiese <mikew@apple.com>
Subject: Re: ARA and data compression
X-Useragent: Nuntius v1.1.1d15
Date: Mon, 14 Dec 1992 07:45:12 GMT
X-Xxdate: Sun, 13 Dec 92 07:45:07 GMT
X-Xxmessage-Id: <A7517B833A010C85@wiese.apple.com>
Organization: Apple Computer, Inc.

In article <KEN.92Dec13223109@stthomas.Cayman.COM> Ken Siegel,
ken@Cayman.COM writes:
>Why did Apple do compression and correction in the CPU?
>
[ Ken's theory deleted ]

I have my own theory. I had nothing to do with ARA so I could be totally
off.

Reason #1: Simplicity

To get better throughput using a modem's built in compression or 
error free mode, the Mac has to send data to the modem faster than the
actual
data rate between the modems. So the modem has to be able to throttle the
Mac in case errors cause transmission delays or the data isn't
compressing much.
This requires the user to have a cable properly wired for hardware 
handshaking. If you put most modems into hardware handshaking mode w/o
the proper cable, they won't be able to receive commands to get out of
that mode, which leads to user unfriendly software.

It also makes the ARA scripts much more complicated, in that they will now
all have to deal with the situation of the answering modem not supporting
MNP or V.42.

With ARA doing the compression, it has much more knowledge about how
things
are going so it can handle timeouts more easily and intelligently. With
such
low bandwidth connections this is critical.

Reason #2: END-to-END data integrity

I don't care if the data gets between the two modems OK, I care if the
data gets between the two Macs OK. This is NOT the same thing at all.
Since
I'm worried about losing data between the modem and ARA's buffer in RAM,
I'm
going to have to do some kind of error free protocol, no matter what the
modem is doing. SO WHY SHOULD THE MODEM WASTE TIME DOING IT TOO? I'd
rather
the modem used all of the connection's bandwidth to ship bits across as 
fast as possible.

Why am I worried about losing data between the modem and the Mac? Because
the
serial port hardware in most Macs has only a 3 byte buffer. If the Mac is
busy,
(say with MacTCP) it may not be able to read from the  buffer in time at
38400
bps. A Mac Plus will have problems at slower speeds, but Apple has to
support it.

I'm also not sure I want to trust every modem manufacturer to implement
compression and error free stuff correctly. There's no certification
authority
like Underwriter's Labs and I don't want to be in the certification
business.
They've been just sending data for years, so I'm not so worried about
that.

Summary: To increase the odds of things working all the time, ARA does
the compression and error correction itself. 

I would argue that it does not take up significant CPU time on the Mac
to do those functions, compared to the time it takes to send the data.

One problem with this is that by putting the modem in "direct" mode where
it just does the modulation thing on the bits we send, we're not making
very efficient use of the communication channel. The modem's RS-232 port
sends data in "async serial" format, with one start bit and one stop bit
for every byte. So for example 9600 bps only yields 960 bytes/s, not
1200 like you  might think.

IF you can set your modems to NOT use direct mode, then they can talk to
each other using whatever protocol they choose, which may have less than
the 20% overhead that async serial has. So you set your computer to talk
to the modem (using async serial) faster than the modems data rate and
the modem will use hardware handshaking to throttle you. According to
someone at Telebit, the error free mode on their modems has less than
20% overhead, so you should be able to get more than 960 bytes/s in 9600
bps mode. But you still have the drawbacks I listed above.

It may be worthwhile to experiment with your ARA setup to see if you can
improve performance by enabling error free mode, but not compression, in
your modems. If you do get better performance, I'd like to hear from you.

mike
Newsgroups: comp.sys.mac.comm