HDTenEightyP/NetNews huggingface dataset:
From: karl@MorningStar.Com (Karl Fox)
Subject: Re: ? rsh/cat vs rcp/ftp over PPP?
Reply-To: Karl Fox <karl@MorningStar.Com>
Organization: Morning Star Technologies
Date: Mon, 14 Sep 1992 04:57:29 GMT

In article <laq57rINN34i@jethro.Corp.Sun.COM> Eric.Arnold@Sun.COM
(Eric arnold) writes:

   With PPP, I've noticed that "rsh" ( E.g. 
   "rsh remotehost 'cat <filename' >filename", or whatever -- as long as
   it is a byte stream) is about twice as fast as "ftp" and "rcp".  Is
   there a way around this?  "rcp" and "ftp" are nice facilities,
   especially with wrappers like "ftptool".

I don't get quite the same results, but I do see a small but
significant speed advantage of rsh and ftp over rcp.  I turned up
debugging (I'm using Morning Star PPP, as you might guess :-), and
noticed that rsh and ftp send full size frames (1500 bytes), but rcp
sends 552-byte packets (552=20+20+512).  Both sizes are before Van
Jacobson TCP header compression.
--
Karl Fox, Morning Star Technologies                            +1 800 558 7827
1760 Zollinger Road, Columbus, Ohio 43221                      +1 614 451 1883
Newsgroups: comp.protocols.ppp
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: ? rsh/cat vs rcp/ftp over PPP?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 14 Sep 1992 15:42:19 GMT

In article <KARL.92Sep14005723@crappie.MorningStar.Com>, karl@MorningStar.Com (Karl Fox) writes:
> In article <laq57rINN34i@jethro.Corp.Sun.COM> Eric.Arnold@Sun.COM
> (Eric arnold) writes:
> 
>    With PPP, I've noticed that "rsh" ( E.g. 
>    "rsh remotehost 'cat <filename' >filename", or whatever -- as long as
>    it is a byte stream) is about twice as fast as "ftp" and "rcp".  Is
>    there a way around this?  "rcp" and "ftp" are nice facilities,
>    especially with wrappers like "ftptool".
> 
> I don't get quite the same results, but I do see a small but
> significant speed advantage of rsh and ftp over rcp.  I turned up
> debugging (I'm using Morning Star PPP, as you might guess :-), and
> noticed that rsh and ftp send full size frames (1500 bytes), but rcp
> sends 552-byte packets (552=20+20+512).  Both sizes are before Van
> Jacobson TCP header compression.
> --
> Karl Fox, Morning Star Technologies                            +1 800 558 7827
> 1760 Zollinger Road, Columbus, Ohio 43221                      +1 614 451 1883


I doubt you are comparing apples to apples.  The MSS is not commonly,
at least as far as I know, directly affected or even changable by
the application.

Could your rcp target be more distant?  Causing the familiar
(Host Requirements and elsewhere) mechanisms to pick a maximum segment
size of <= 512?

Of course, `rcp` is implemented with `rsh`.  The local rcp command
does the moral equivalent of `rsh remotehost rcp ...`.  That is the source
of the ever popular "protocol screwup" error message cause by babbling
from the .cshrc on the remote machine.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.protocols.ppp
From: bjork@telebit.com (Steven Bjork)
Subject: Re: Inappropriate ioctl for device
Organization: Telebit Corporation; Sunnyvale, CA, USA
Distribution: usa
Date: Mon, 14 Sep 1992 17:58:18 GMT

In article <BuFs0F.56n@news.orst.edu> uriber@OES.ORST.EDU (Ricardo Uribe) writes:
>Hello
>I am installing ppp.pl6 on my Sparc station running 4.1.2 and when I try
>to issue the ppp command I get:
>ppp: ioctl(TIOCSPGRP): Inappropriate ioctl for device
                ^^^^^
Find the place in the code where it sets the process group.
Comment that code out. Recompile.

--Steven
From: crowell@ctron.com (Chris Crowell)
Newsgroups: comp.protocols.ppp
Subject: ppp executing in user's space on sun?
Keywords: ppp
Date: 9 Sep 92 11:39:48 GMT
Reply-To: crowell@ctron.com (Chris Crowell)
Organization: Cabletron Systems Inc

Is there a PPP implementation that executes in user's space rather than kernel
space ?  All of the implementation I have seen for the sun execute in kernel
space.
--
David W. Wilson (wilson@ctron.com)

Disclaimer: "Truth is just truth...You can't have opinions about truth."
- Peter Schikele, introduction to P.D.Q. Bach's oratorio "The Seasonings."
Newsgroups: comp.protocols.ppp,comp.dcom.modems
From: dwight@hyphen.com (Dwight Ernest)
Subject: Re: Help with World Blazer
Organization: Hyphen, Inc., Wilmington, MA 01887 USA / +1 508 988-0880
Date: Sun, 6 Sep 1992 21:25:05 GMT

dplatt@ntg.com (Dave Platt) writes:

>I have noticed that the WorldBlazer command-parser seems to have trouble
>if you blast dialing commands at it at a high serial-port speed.  Last
>night, I tried using Taylor uucp (1.03) to dial out using our
>WorldBlazer with the serial-port speed set to 38400 (and the WorldBlazer
>configuration set to use that speed, only).  The first few bytes of the
>dial-and-configuration command went out OK, as each one is followed by a
>pause to allow the modem to autobaud (not necessary in this case).
>However, when the remainder of the command was blasted out at 38400 bps,
>the WorldBlazer abruptly deasserted CTS and failed to respond.

>You may need to hack your dialer so that the dialing command is
>"paced"... that is, your dialer must send each individual character, and
>then pause for 10 milliseconds or so before sending the next character.
>This may enable the WorldBlazer to keep up with the command.

I've noticed the same thing on password input.  When S46==3 and a dialin
password is set in the WB, if the dialin password is entered too quickly
by the calling system, it will fail to be properly interpreted.  We've
had to setup our UUCP scripts in such a way that the modem password is
entered slowly, with a slight pause between each character.
-- 
--Dwight A. Ernest   Special Projects Engineer   I speak only for myself.
  Hyphen, Inc. / 187 Ballardvale St. / Wilmington, MA 01887 / +1 508 988 0880
  dae@world.std.com		dwight@hyphen.com
Newsgroups: comp.protocols.ppp
From: billp@ncsa.uiuc.edu (Bill Pottenger)
Subject: PPP/SLIP for Ultrix
Originator: billp@consult.ncsa.uiuc.edu
Organization: Nat'l Ctr for Supercomp App (NCSA) @ University of Illinois
Date: Mon, 14 Sep 1992 18:34:41 GMT

Hi.  I was wondering who has done work on a ppp/slip combined package
for Ultrix... besides Morningstar.  (Public domain).

Thanks,
Bill
ps. please email responses.
From: aronsson@sectra.se (Lars Aronsson)
Newsgroups: comp.protocols.ppp
Subject: Re: PPP implemenation that executes in user space?
Date: 11 Sep 92 09:05:37 GMT
Distribution: comp
Organization: SECTRA AB, Linkoping, SWEDEN

edhall@rand.org (Ed Hall) writes:
>don't expect [KA9Q NOS] to interface with other network software.  To
>do that, you need to either put PPP in the kernel, or use a "tunnel
>driver" like MorningStar does with their PPP (a pseudo-device driver
>which allows a user process to pump IP packets into and out of the
>kernel).

If your computer already supports SLIP, you can do this with a PTY. I
wrote a small user-level program that just tunnels bytes between a PTY
and a TTY. Running SLIP through this "bridge" adds a few copy
operations between kernel and user memory. This gave me no measurable
decrease in throughput (using ftp), and only little longer response
times (using ping). My TTY line does 9600 bit/s TTY line. The slow TTY
line is the real bottleneck here, so you could probably do this on
much slower computers than my HP 9000/400 running HP-UX 8.0 and
IBM-compatible 486 PC running SCO UNIX.

I did this only for some experiments, and as an exercise, and didn't
use it later. The problem I never solved was opening a PTY with a
well-known name. The SLIP implementation used (HP-UX PPL) wants the
name of the underlaying SLIP device to be written in a file, and I
don't know the name of the PTY until I have successfully opened it. If
a window system grabbed my favorite PTY, I would have to use another.

I never tried to translate between SLIP on the PTY and PPP on the TTY,
so I cannot know how much overhead that would have caused.

Is anybody from Hewlett Packard out there? How long do we have to wait
for HP's PPL product to implement the PPP protocol? It has been a
promise for a long time now.
-- 
Lars Aronsson, SECTRA AB, Teknikringen 2, 583 30 Linkoping, Sweden
Newsgroups: comp.protocols.ppp,comp.dcom.modems
From: larry@gator.rn.com (Larry Snyder)
Subject: Re: Help with World Blazer
Organization: The Gator Public Access Unix Site - 219-289-3745
Date: Wed, 9 Sep 1992 11:09:29 GMT

wjk@Phonogenic.COM (Bill Keenan) writes:

>When I was using the autobaud setting (s51=255||254||253), I did have
>trouble with 38,400. I didn't investigate because I wanted to 57,600. I
>now lock DTE at 57,600, and I have not had any problems. (I use uAccess
>and a DigiCHANNEL Nu/4i on a Macintosh Quadra 700.) (I assume you have
>verified that your machine's hardware can support a clean and sustained
>38400 since many machines stop at 19200.)

I was running my WB modems at 57600 baud just fine -- I didn't
notice any increase in throughput -- and the fact of the matter
is that ProYam doesn't support 56700 baud.  The Digi streams drivers
for SVR4 re-uses baud rates in the table, so 50 baud becomes 56700
baud -- and ProYam doesn't like a baud rate of 50 (I don't think it
uses the altered baud rate tables)

I wish Chuck would fix ProYam
-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
Newsgroups: comp.protocols.ppp
From: rypma@waterloo.hp.com (Ted Rypma)
Subject: Re: Why is PPP better than SLIP
Date: Sat, 5 Sep 1992 03:21:21 GMT
Organization: HP Panacom Div Waterloo ON Canada
X-Newsreader: Tin 1.1.3 PL5

Karl Fox (karl@MorningStar.Com) wrote:
: 
: I think you need to check your arithmetic.

So it was late and I was sleepy :-) Each part, IP/TCP header and data are
reduced by about the same factor.

Ted Rypma
From: edhall@rand.org (Ed Hall)
Newsgroups: comp.protocols.ppp
Subject: Re: PPP implemenation that executes in user space?
Date: 10 Sep 92 21:33:42 GMT
Organization: RAND Corporation.

In article <4970@balrog.ctron.com> crowell@ctron.com (Chris Crowell) writes:
>All of the PPP implementations I have seen for Sun have executed in
>kernel space.  Are there implementations that execute in user space ? Can PPP
>operate in user space ?

The KA9Q NOS software can be coaxed to run on a Sun.  There are UNIX
porting kits around for older versions (which don't support PPP); it
is a modest amount of work to adapt these to work with newer versions
of NOS (which do support PPP).  I did this for System V R3.2.

This sort of setup is fine for outbound telnet and for FTP.  It is a
self-contained program which does its own multi-processing, though, so
don't expect it to interface with other network software.  To do that,
you need to either put PPP in the kernel, or use a "tunnel driver" like
MorningStar does with their PPP (a pseudo-device driver which allows a
user process to pump IP packets into and out of the kernel).

MorningStar's latest version of the tunnel driver for the Sun is
dynamically installable, and the PPP software which runs with it is
highly configurable and robust.  It's a commercial product, but it is
worth the bucks if you are going to be using PPP on a regular basis.

		-Ed Hall
		edhall@rand.org
Xref: sparky comp.protocols.ppp:754 comp.dcom.modems:13073
From: wjk@Phonogenic.COM (Bill Keenan)
Newsgroups: comp.protocols.ppp,comp.dcom.modems
Subject: Re: Help with World Blazer
Date: 7 Sep 92 16:35:27 GMT
Reply-To: wjk@Phonogenic.COM (Bill Keenan)
Organization: Phonogenic Systems Corporation
X-Mailer: uAccess - Macintosh Release: 1.6v1


In article <1992Sep6.212505.12383@hyphen.com> (comp.protocols.ppp,comp.dcom.modems), dwight@hyphen.com (Dwight Ernest) writes:
> 
> dplatt@ntg.com (Dave Platt) writes:
> 
> I have noticed that the WorldBlazer command-parser seems to have trouble
> if you blast dialing commands at it at a high serial-port speed.  Last
> night, I tried using Taylor uucp (1.03) to dial out using our
> WorldBlazer with the serial-port speed set to 38400 (and the WorldBlazer
> configuration set to use that speed, only).  The first few bytes of the
> dial-and-configuration command went out OK, as each one is followed by a
> pause to allow the modem to autobaud (not necessary in this case).
> However, when the remainder of the command was blasted out at 38400 bps,
> the WorldBlazer abruptly deasserted CTS and failed to respond.
> 
> You may need to hack your dialer so that the dialing command is
> "paced"... that is, your dialer must send each individual character, and
> then pause for 10 milliseconds or so before sending the next character.
> This may enable the WorldBlazer to keep up with the command.

When I was using the autobaud setting (s51=255||254||253), I did have
trouble with 38,400. I didn't investigate because I wanted to 57,600. I
now lock DTE at 57,600, and I have not had any problems. (I use uAccess
and a DigiCHANNEL Nu/4i on a Macintosh Quadra 700.) (I assume you have
verified that your machine's hardware can support a clean and sustained
38400 since many machines stop at 19200.)

Bill

------------------------------------------------------------------------
Bill Keenan
Internet:	wjk@phonogenic.com -or- phngnc!wjk
AppleLink:	wjk@phonogenic.com@INTERNET#
CompuServe:	>INTERNET:wjk@phonogenic.com
Phonogenic Systems Corporation - Phone 415/365-1083 - FAX 415/365-1083
PO Box 3535, Redwood City CA 94064

Rudman - Tsongas '96 on the Republocatic ticket
Politicians working together for fiscal responsibility! This country
borrows about $4.25 per day per US resident (that is $21/day for a
family of 4) with little hope of paying any of the principle!
Newsgroups: comp.protocols.ppp
From: grevemey@vela.acs.oakland.edu (Steven E. Grevemeyer)
Subject: PPP for Silicon Graphics PI
Reply-To: grevemey@vela.acs.oakland.edu (Steven E. Grevemeyer)
Organization: Oakland University, Rochester MI.
Date: Mon, 14 Sep 1992 14:39:25 GMT


Has anyone gotten PPP to work on an SGI?


===============================================================================
Steven E. Grevemeyer		Fast-email: grevemey@vela.acs.oakland.edu
AMSTA-RVS			Slow-email: segrevem@tacom-emh1.army.mil
US Army Tank-Automotive Command      Phone: (313)574-5007
Warren, MI 48397-5000
==============================================================================
From: perkins@cps.msu.edu (Stephen Perkins)
Newsgroups: comp.protocols.ppp
Subject: Sparc panic
Date: 6 Sep 92 16:00:53 GMT
Organization: Dept. of Computer Science, Michigan State University
Originator: perkins@indian.cps.msu.edu

I have installed PPP (I tried both ppp-sunos4.1.pl6.tar.Z and
pppd-1.01beta.tar.Z) on a Sparc1 running SunOS Release 4.1.1.  The
installation seems to be successful and my NeXT at home seems to
communicate nicely.  However, I have encountered a rather nasty
problem when I try a binary FTP between the Sparc and the NeXT.  I can
transfer files in Ascii mode and even a few in binary mode, but most
binary files cause the Sparc to crash.  The /usr/adm/messages file
gives a message like:

Sep  2 20:22:29 sol vmunix: assertion failed: dbp->db_ref > 0, file: ../../os/str_buf.c, line: 526

The OS then panics and reboots.

The problem does seem to be with binary files because I was able to
transfer gcc (9meg uuencoded) with no problems.  It also only occurs
when the transfer is from the sparc to the NeXT.  Binary transfers
from the NeXT to the Sparc work fine.  To clarify, it doesn't matter
which end I run FTP from.  If the file is being sent from the Sparc to
the NeXT (FTP on Sparc using put) or received from the Sparc by the
NeXT (FTP on NeXT using get), the Sparc crashes.

I am running the link over a NetBlazer using telnet to the host on
which I installed PPP (Unfortunately, not allowed to use the
NetBlazers PPP).  I don't think that telnet is the problem, but
somebody suggested that I make sure characters 250-255 were escaped.
So I went as far as modifying the source to force those characters to
be escaped.  Didn't help.  

I'm not lucky enough to have the source to str_buf (object located in
/usr/kvm/sys/sun4c/OBJ/str_buf.o).  Is there anybody who has an idea
of what the problem may be??  Help would be sincerely appreciated.

- Steve

-- 
====================================================================
Stephen Perkins                    |
Department of Computer Science     | perkins@cps.msu.edu
Michigan State University          |
Newsgroups: comp.protocols.ppp
From: uriber@OES.ORST.EDU (Ricardo Uribe)
Subject: Inappropriate ioctl for device
Organization: Oregon Extension Service, Oregon State University, Corvallis, Or.
Distribution: usa
Date: Fri, 11 Sep 1992 23:02:38 GMT

Hello
I am installing ppp.pl6 on my Sparc station running 4.1.2 and when I try
to issue the ppp command I get:
ppp: ioctl(TIOCSPGRP): Inappropriate ioctl for device

I am using /dev/cub (/dev/ttyb)

Does any one knows how to fix this?

I apreciate any help

Thanks

Ricardo Uribe
Oregon Extension Service, Oregon State University
uriber@OES.ORST.EDU
From: yellowbd@eskimo.celestial.com (Andy Hubbell)
Newsgroups: comp.protocols.ppp
Subject: Is PPP available for MSDOS based pc?
Date: 14 Sep 92 06:41:43 GMT
Organization: -> ESKIMO NORTH (206) For-Ever <-
X-Newsreader: Tin 1.1 PL3

Well, the subject line says it all really.  I'm looking for an
implementation of ppp on an IBM pc/clone (386+ is ok) for me to use
under Desqview/x.  Please mail replies to yellowbd@eskimo.celestial.com
  
Thanks in advance!
  
                    --== Andy ==--
Newsgroups: comp.protocols.nfs
From: fred@maccs.dcss.mcmaster.ca (Fred Whiteside)
Subject: Re: ftp transfers to pc FROM sun take forever. 
Reply-To: fred@bws.com (Fred Whiteside) 
Organization: Beame & Whiteside Software Ltd. 
Date: Fri, 11 Sep 1992 12:18:05 GMT

In <18pam6INNa1t@huon.itd.adelaide.edu.au>, george@frodo.ua.oz.au writes:
>I have noticed some strange behaviour between a pc client running pcnfs4.0a
>and its SUN IPX server. Specifically, ftp transfer rates depend upon the
>direction with transfers "FROM" the SUN to the pc take what seems to
>be 'forever'.
>
>An example:
>
>12934 bytes received in 78.064100 seconds (0.16 kbytes/s)  SUN -> PC
>The same file transfered in the other direction happens at a reasonable
>rate. >10kbtes/s. PC -> SUN.
>
>What could be causing this? It seems to be only for files > 1k and the
>system just looks inactive.

	what type of adapter do you use?  this looks like the card is
having trouble seeing packets sent to it too quickly, causing
re-transmissions, and of course, the associated time-outs.  files of <1K
will fit into 1 ethernet frame, so you don't see the problem.

>Is their any way of determining where/what the problem may be? I'm
>stumped over this.

	an ethernet analyser is generally an invaluable tool for debugging
this sort of problem ...

>                  George Travan "A Rebel Without A Clue!" 
>                  E-mail: george@ache.mad.adelaide.edu.au 

	Fred Whiteside
-- 
Fred Whiteside   Beame & Whiteside Software Ltd., Caledonia, Ontario
fred@bws.com   fred@maccs.DCSS.McMaster.CA   ...!uunet!utai!utgpu!maccs!fred
Newsgroups: comp.protocols.nfs
From: rabbe@infolog.se (Rabbe Fogelholm)
Subject: Re: Ctrl-P key confusing to PC-NFS?
Organization: Infologics AB, Sollentuna, Sweden
Date: Thu, 10 Sep 1992 07:05:20 GMT

In article <18aamfINNmqr@seven-up.East.Sun.COM>
geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the
top) writes:

>Fixed in 4.0a, FTPable from any of
>	bcm.tmc.edu
>	ftpserver.massey.ac.nz
>	src.doc.ic.ac.uk

Thanks! I tried it and it certainly solved the problem. Now I have
another one, as I will describe in a separate post ...

________________________________________________________________________
Rabbe Fogelholm, Infologics AB     rabbe@infolog.se    fax: +46 8 960846
Newsgroups: comp.protocols.nfs
Subject: Re: Ctrl-P key confusing to PC-NFS?
From: carlson@dwp.la.ca.us (Carlson Peters x7898)
Date: 4 Sep 92 22:34:37 GMT
Organization: Los Angeles Dept. of Water & Power

In article <1992Sep3.210602.344@infolog.se> rabbe@infolog.se (Rabbe Fogelholm) writes:

>session and I am back in MS-DOS, I get a message complaining about
>"device PRN" (I think it was) and an "Abort, Retry, Ignore, Fail" prompt.
>

I get this too.  Since ^p is part of emacs style unix command line
editing I am forever hitting this by mistake.  The only alternative
is to reboot.  If I am running a dow session under windows I can
force the window to die with unpredictable results.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Carlson Peters			L.A. Dept. of Water & Power
carlson@manta.dwp.la.ca.us	111 N. Hope St., Room 1129
213.481.7898			L.A. CA 90012
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS Over Satellite Link
Date: 10 Sep 92 11:37:27 GMT



 >In article <1992Sep9.121006.14055@udel.edu>, pahountis@ncf.al.alcoa.com (Julia Pahountis) writes:
 >|> Has anyone, or do you know of anyone, who has done NFS over a satellite link?  (Can it be done?)
 >

yes - we did it years ago - Bill Nowicki ran some tests of getting the
parameters right from Sun to UCL

you need ~1 sec retransmit timers, small blocksizes etc etc...

it worked ok (on a 2*64kbps 5 site satellite system)

remember if you dont have forward error correction on yr satellitew
link, your error rates will be massive compared to what you are used
to on terestrial links (e.g. 5%)

 jon
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
From: beame@maccs.dcss.mcmaster.ca (Carl Beame)
Subject: Re: Sun <=> PC Transfer Rate (Summary)
Organization: McMaster University, Hamilton, Ontario, Canada.
Date: Sat, 12 Sep 1992 22:42:53 GMT

In article <920911085058@minimillian.ftp.com> backman@vaxeline.ftp.com (Larry Backman) writes:
>
	[stuff deleted]
>
> The 3C509 (if this is what you are referring to) has serious problems with
> 8K receives.  I have had little luck in getting its OS/2 NDIS driver to 
> consistently receive all 6 IP fragments in an 8K RPC.  3Com's response
> has been to state that the NFS protocol is flawed if it expects to
> receive 6 back to back packets.
>
> The board has only a 2K buffer.
> 
> Draw your own conclusions.
>
>Larry Backman
>FTP Software

	We have also done tests with the 3C509 card. The tiny buffer size makes
the card little better then their 3C501. Its not just NFS that can expect a
large number of back to back packets, TCP does as well. In our TCP/IP we
set the incoming TCP Window based on the buffer size in the card. A WD8003E/A
micro channel card can run with a 6 to 8K TCP Window size, because it can
accept 6 to 8 back to back packets in its 16K buffer. Many high speed protocols
(Novell's new high speed blit protocol) are based on the fact that the receiver
can handle many back to back packets with out waiting for an ACK.

	In my experience with our TCP over many ethernet cards, the main
factors in performance were the size of the cards buffer and the speed of the
system bus. Ofcourse the CPU is important, but with INTEL machines, the CPU
can usually process packets faster than the cards can deliver them to the CPU.

Carl Beame
Beame & Whiteside Software Ltd.
Newsgroups: comp.protocols.nfs