Subject: Re: PPP slow (long)
To: T&B <list.mac68k@tandb.com.au>
From: Bruce Anderson <brucea@spacestar.net>
List: port-mac68k
Date: 07/31/2000 21:44:30
On Mon, Jul 31, 2000 10:44 AM, T&B <mailto:list.mac68k@tandb.com.au> wrote:
>I transfered a test file using this command:
>ftp http://www.tandb.com.au/fast/smile.sit smile.sit
>under some different configs, with these results:
>
>serial   control        init      kB/s    o/flows
>115200   modem cdtrcts  at&fe0     3.84    24
> 57600   modem cdtrcts  at&fe0     modem hung up on 3 attempts when ftp
started
>115200   modem cdtrcts  at&fe0     3.26    49 (repeat of test 1)

Above we are using hadware flow coltrol on the port but the
modem is not setup to do it. Note: cdtrcts says use
DTR/CTS for flow control; most modems default to 
&D2: DTR causes modem to hang up.

>115200   modem cdtrcts  at&f&d0e0  3.28    51

Above we are using hadware flow coltrol and the modem
is set not to hangup when DTR drops. But the modem
is taking too long to respond and so we get overflows.
Note: default delay for RTS-to-CTS on most modems is
10ms or more.  To reduce overflows and thus thruput
change the delay for RTS-to-CTS of the modem with:
S26=0  (Check your modem manual. Default:S26=1 for
Zoom56k modem)


> 38400   modem cdtrcts  at&f&d0e0  3.59     0
> 19200   modem cdtrcts  at&f&d0e0  1.85

Above we are using hadware flow coltrol and the modem
is set not to hangup when DTR drops. We are now going
slow enough not to need harware flow control when the
machine is idle.

> 38400   <none>         at&f&d0e0  3.65     0

Above we are using  no  hadware flow coltrol and the modem
is set not to hangup when DTR drops. We are now going slow
enough not to need harware flow control when the machine
is idle.

> 38400   <none>         at&f       3.62     0

Above we are using no hadware flow coltrol and the modem
is set to hangup when DTR drops.

>NetBSD thu IIsi/MacOS/IPNetRouter  5.38
>Anarchie on IIsi thru IPNetRouter  5.5

Here the performance of ftp is enhanced by your connection
using vj compression mith MacOS

Test again with this added* to you option file:

predictor1 
vj-max-slots 16


>
>Except for the last, the above kB/s figures are the averages given by ftp
at
>the end of the transfer. The transfers peaked at up to a reported 8 kB/s.
For
>the IPNetRouter/MacOS/IIsi test, I still used the IIcx/NetBSD as the ftp
>client, but routed through the IIsi.
>
>So, my best bet seems to be no extra modem inits (just rely on whatever
the at&
>f defaults are) and no connect script modem controls (again just rely on
>defaults). But this best situation still only does 3.6 kB/s, not the 5.4
>provided by a Mac OS based router on similar hardware. I'll have to check
under
>exactly the same hardware and ISP account.
>
>The "o/flows" are the sum of the silo number in these errors in the
message
>log:
>Aug  1 00:09:02 macbsd /netbsd: zstty1: 8 silo overflows, 0 ibuf floods
>Should I be concerned about these? Is there any way to achieve those
higher
>serial speeds without errors?


Don't worry about silo overflows. Do worry about ibuf floods.
Each  "silo overflows" represents a  packet that must be 
retransmitted, thus reducing thruput.

>
>As a side issue, when I start the pppd process, my resolv.conf file is
reset to
>some default. I have not scripted this in my above setup, so what's
responsible
>and how do I stop it?
>

I answered this in the email about "ppp NAT" where I included a full
set of sample files.
"welcome" & "disconnect" & "ip-up" & "ip-down" may mess with your setup.

comment out the welcome & disconnect scripts as neede in the
peer/file like so:
# welcome '/sbin/route delete default' # delete any current default routes
first
# pppd changes the routing table for us.
# ipparam "MYISP.net 206.191.193.xx,192.168.1.31 MYISP.net,home.org"
# disconnect /etc/ppp/?? # eg. You could reset the default route here when 
# pppd is done. 



Other notes: 
If you only do outbound calls: do not place commands in any 
option file. All the /etc/ppp/option* files should be blank
for simplicity.

  &D0 is essential to keep the modem from hanging up while
  using  cdtrcts  hardware flow control with external modems.

  Y1 is essential to get the modem to hangup while using 
  &D0 with external modems.  The remote modem  might not
  hang up when the connection is done, so make sure we do.





" 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.