At 11:48 PM -0600 11/18/01, Bruce Anderson wrote:
>On Sun, Nov 18, 2001 5:40 PM, T&B <mailto:list.mac68k@tandb.com.au> wrote:
>>I have a few remaining issues, with which I hope someone can help:
>>
>>4) The throughput speed (eg: ftp or http) is too slow at about 1kB/s. It's
>the
>>same on a IIcx or IIvx, accessing local or Internet servers. By contrast,
>I get
>>2.5kB/s dialing into a IIvx running Mac OS 7.6 and Remote Access, with the
>same
>>modem and cables. I get over 4kB/s dialing out through the same
>connections.
>
>Add to: /etc/ppp/peers/answer
>
> modem                          # use full modem control
> cdtrcts                        # use hardware flow control on Mac's

Three things:

1. "modem" doesn't work on macs.  this option mostly causes pppd
to pay attention to the CD line on the serial port.  The DIN-8 connector
on Macs does not connect CD.  If you try to use it, you'll get
flaky stuff to happen, or it won't work.  I don't remember.

2. The reason that the modem doesn't drop the line when you
disconnect is that there is is no CD (carrier detect) signal to tell
it that the modem is "connected".  Without that CD
line, it's not easy to get a reliable way to tell pppd that the modem
has dropped the data connection.  I played with this a bit with my
setup, but never got anything quite satisfactory.  There are two options that
I thought of that you might want to try.  One, play with the LCP-* options
in pppd options.  These LCP "echo" packets are the moral equivalent of
a ping to the other side, and you can tell pppd to drop
the connection if the LCP-echo fails N times.  Look At lcp-echo-failure.
Modem options Y1 and &D0 are also a really good idea, as mentioned
below.

3. The speed of dial-in should not be limited by either the serial
ports or CPU on a Mac II.  I ran my dial-in  on a IIci, and got
what I considered perfectly acceptable performance. (80-90% of
what the modem could do in TCP throughput.)  For instance, I
could get 3.5-4 K bytes/second when the modem was connected at 28.8 or 33.6.
(note: compression must be helping out here.)  1K is pretty poor.
Something is slowing you down.  Do you have **really** verbose
logging enabled?  is your CPU busy finding prime numbers?

4. It is possible that if you're not using cdtrcts in your options, this
may be causing performance problems.  (usually this will cause hangs, though)
(OK, four things)

-dgl-


>>6) Answering works with my Banksia Wave56 and Simple56 modems, but not a
>>SupraFax33.6 (I get Serial Line Looped Back errors when it tries to
>initialise)
>>I tried 38400 serial speed. The Supra works okay with Mac OS and Remote
>Access.
>
>Add to: /etc/ppp/chat/answer
> E0  to modem init string (alwase after the &F command).
>
>>
>>7) With at least one dial in user, when they drop the connection, their
>>software reports that the connection is dropped, but the modems at each
>end
>>keep the connection open.
>
>Add  Y1 &D0  to modem init string (alwase after the &F command).
>    # Y1 &D0   are essential to get the modem to hangup while using 
>    # cdtrcts  hardware flow control with external modems.
>Add   S26=0  to modem init string (alwase after the &F command).
>    # S26 is the "RTS to CTS delay register" (See your modem manual first).
>    # Reduces silo overflows.
>
>
>
>
>" Stamp out root logins .  .  .  . su "   --Bruce Anderson  
> This message was created and sent using Cyberdog 2.0, MacOS 8.6,
> awk, find, sed, sendmail, sh, and NetBSD a free Multi-Platform OS.
> NetBSD runs on  44 different system architectures featuring 16
> distinct families of CPUs.   http://www.netbsd.org/