Subject: Re: Old Mac (SE/30) high speed modem performance?
To: Lt Avram Dorfman <dorfman@hq.af.mil>
From: Bill Studenmund <wrstuden@loki.stanford.edu>
List: port-mac68k
Date: 07/15/1996 22:23:39
>
> I was able to crank my serial port up to 57.6k on my SE/30 on a direct
> serial connection to my powerbook. Thus, it was a pure 57.6k, not a
> compressed 19.2 or 28.8. I got about 50kbps through it (via ftp, running
> pppd & MacPPP on the line), and that's pure data. Once you add in
> overhead, I must have been pretty close to 100%.
Cool!
> MacBSD wouldn't let me chose a data rate higher than 57600. Although the
> man page claims that you can pick ANY rate (i.e. other thatn common
> values like 28800, 38400, etc), pppd would only let me pick the common
> values, and the highest it would let me pick was 57600 (or maybe it was
> one higher, like 76800). Can anyone comment on this? Is it just a
> question of what speeds are defined, or did the implementors stop at that
> speed for a more pressing reason?
pppd lets you pick any data rate which the underlying serial driver
accepts, not any rate you wish. Contrast this with the current lpd code;
if you choose a baud rate > 38400 or not a multiple of 300 baud,
lpd squalked, even if the port would support such a rate.
It was 57600. Being the keeper/breaker of the zs/mac68k driver, I made it
stop there as the port won't really go faster. 57600 is the fastest the
baud rate generator will give. Using an external clock, the current code
will (with booter 1.9.3) let you pick /1, /16, /32, and /64 relative
to the external clock. This way, you could get data rates on the order of
500 kb/s; the only way we'll ever support a bunch of the Apple Personal
LaserWriters.
I DON'T recommend trying to receive a significant amount of data at these
higher rates. The overhead for IO servicing could get to be too much.
Transmitting, though, is fine (the difference benig if the computer ignores
a transmitter empty interrupt for a bit, it just slows the transfer
while a received data interrupt will eventually lead to lost data).
Take care,
Bill