🚀 go-pugleaf

susanh@ossi.com (Susan Hunts) writes:

>1. Is this a reasonable approach?  Any major drawbacks I should know
>   about?  What kind of performance am I likely to see?  Any
>   problems with the PPP software and SunOS 4.1.1?

Yes it is reasonable. I've run PPP between my Sparcstation at home
(SunOS 4.1.1 and 4.1.2) and our campus net, mainly through a Telebit
Netblazer, but another Sparcstation will work just fine. What do you
mean by "performance" ? 'Interactive' (telnet, ftp)performance between
2 V.32bis modems is quite good, although sometimes you do notice
you're not on a 10MB/s ether..

>2. Does building, installing, configuring, etc. require a guru?  The
>   PPP software appears to have nice, clear cookbook instructions
>   which can be followed by a neophyte.  Any additional hints or tips 
>   someone would like to pass on?  What about setting up the modems?

Building and installing it doesn't require guru status (although it
certainly doesn't hurt :-} ), as the instructions are pretty clear. I
think there was a file that needed to be copied into /usr/include
somewhere that the instructions didn't mention.

If you're going to be running NFS over the link, I'd recommend turning
on UDP checksumming in your kernels (Its OFF by default in SunOS 4.x):

gonzo csh[42]:adb -k /vmunix /dev/mem
physmem 1bf3
udp_cksum?
  _udp_cksum:
  _udp_cksum:     0               = unimp         0x0
udp_cksum/w 1
  _udp_cksum:     0x0     =       0x1
$q


using a '?' instead of '/' will change the value both in the running
kernel and /vmunix on disk. If you use the '/', it only gets changed
in the running kernel, and will be set back to 0 when you reboot. If
you want to generate new kernels with udp checksumming turned on, you
can change /usr/sys/`arch`/OBJ/udp_usrreq.o with the adb in the same manner.

>3. Any comments on choice of modems?  (Cost is a factor.)  If there's
>   a random modem available for free, what minimum capability should
>   it have?

Go for the highest speed modems you can. There is a noticeable
difference between V.32 (9600) and V.32bis (14400), at least in terms
of how fast the link 'feels'. So, at a minimum, make sure you have
V.32. I dont know how/if MNP/compression helps. Perhaps someone here
has done some testing in this area ? I dont think you'd want to run NFS over
anything slower than a 9600 baud link....

							/AWF
------------------------------------------------------------------------------
Internet: feigin@iis.ethz.ch				 Adam W. Feigin
UUCP:{backbones}!iis!feigin			     Network Systems Manager
Mail: Integrated Systems Laboratory	      Institute for Integrated Systems
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41 1 256 50 53
      
  "In Confession, you blame yourself, in analysis, you blame everyone else"

       (knowledge of Refered-to article by the reader assumed)

Hello,

I have two remarks:
   
1. You might try pppd-1.01-beta from for the sparcs to get the most
   ripe non-dialup version. Despite it's 'beta' status, it has the
   most kernel memory allocation/deallocation bugs removed. It's more
   advanced than the pl6 version you mentioned, as far as I know.

   ftp to merit.edu, directory /pub/ppp, file pppd-1.01-beta.tar.Z

2. You might want to try dp-2.2-beta.tar.Z (or -gamma, it that exists
   by now..) to get the dialup ppp package [and tell Kirk Smith
   (ks@acn.purdue.edu) to add yo to the mailing list]. It simulates
   keeping the network connection up, but has time-outs on the phone
   line, so that if (all configurable) the last tcp connection was
   closed, the phone line hangs up after 6 seconds, if the last tcp
   transmission actually occured 10 minutes ago, the phone hangs up,
   or 30 seconds after the last UDP packet... you get the idea. It
   then does an automatic redial, if traffic occurs again.

   The 2.2-beta version has some minor Makefile/include file problems
   (Kirk has my diffs for it), and tends to crash when you have an
   error in the configuration script (deref'ing zero pointers), but
   works like a charm otherwise, AND IT SUPPORTS LOADABLE KERNEL
   MODULES... at least half (i.e., you can load them, but if you do
   the unloading, the system crashes when it tries to do networking
   again). But I think it's better to only reboot the machine to
   remove or update the ppp if you want it, than to built a new kernel
   and reboot the machine :-) Maybe SUN never tested this part of
   their Kernel code? I think they don't have any loadable network
   modules of their own.

   ftp to phoenix.acn.purdue.edu, directory pub, and get PPP.readme
   (1k) with further advice.

   You might want to configure the sendmails at both ends to only
   actually send the mail, say, two times a day, to minimize costs
   [mark the connection expensive].

I used both packages. I like the latter better, because it's less work
and less to backup if you want to install it, and because I won't get 
'how is the ppp startup command' phone calls all the time.

BTW: nfs? You might want to completely avoid it. Try mounting a remote
   filesystem to get the feeling. Basically, you have to avoid
   anything which does stats because they cause lots of traffic, and
   anything which does writes because nfs writes always wait for the
   'written to disk' confirmation from the other side.


--
	Ignatios Souvatzis
	ignatios@cs.uni-bonn.de souva@babsy.mpifr-bonn.mpg.de

ignatios@theory.cs.uni-bonn.de (Ignatios Souvatzis) writes:

[About dp-2.2-beta]

>   The 2.2-beta version has some minor Makefile/include file problems
>   (Kirk has my diffs for it), and tends to crash when you have an
>   error in the configuration script (deref'ing zero pointers), but
>   works like a charm otherwise, AND IT SUPPORTS LOADABLE KERNEL
>   MODULES... at least half (i.e., you can load them, but if you do
>   the unloading, the system crashes when it tries to do networking
>   again). But I think it's better to only reboot the machine to
>   remove or update the ppp if you want it, than to built a new kernel
>   and reboot the machine :-) Maybe SUN never tested this part of
>   their Kernel code? I think they don't have any loadable network
>   modules of their own.

This is not so much a SUN problem, as me. With the help of Paul Fox
(paul@crisp.demon.co.uk) I tried *really* hard to get the unloading
working, but I was/am having problems with removing routing records
to the interface... as I do not have the SunOS source I cannot see
what I am doing wrong. The code in dp-2.2-beta is almost the latest
that I have, but my time is being spent at the moment getting the
dp package going on 386BSD.

>I used both packages. I like the latter better, because it's less work
>and less to backup if you want to install it, and because I won't get 
>'how is the ppp startup command' phone calls all the time.

The main reason for the loadable modules was to "supplement" the dial-
on-demand support, so that the whole thing could be got going easily.

>BTW: nfs? You might want to completely avoid it. Try mounting a remote
>   filesystem to get the feeling. Basically, you have to avoid
>   anything which does stats because they cause lots of traffic, and
>   anything which does writes because nfs writes always wait for the
>   'written to disk' confirmation from the other side.

I only use NFS for mounting things like gatekeeper.dev.com and so on
for reading, and it is fine. I have not tried writing, but I can
imagine :-)

For those who may be interested or would like to help, I have got to
it all compile on 386BSD (except the kernel drivers of course), and I
will be using the ppp from Brad Parker (brad@cayman.com) as a starting
point. I need pre-alpha testers (like not so much testing as telling
me where I f*cked up). Also, has anyone completed the tunneling driver
that Bill Jolitz included in 0.1 ?

Anyway, enough for now,
-- 
Peter Galbavy
Tech Support, Micromuse Ltd
Phone: +44 71 352 7774		E-Mail: P.Galbavy@micromuse.co.uk

Ignatios Souvatzis writes:
|> BTW: nfs? You might want to completely avoid it. Try mounting a remote
|>    filesystem to get the feeling. Basically, you have to avoid
|>    anything which does stats because they cause lots of traffic, and
|>    anything which does writes because nfs writes always wait for the
|>    'written to disk' confirmation from the other side.

you have to avoid reads, too.

but afs over dialup is not too bad.  client caching wins.

	peter