using System V 'cu'

[James Logan III]

In article <6808 at venera.isi.edu> cracraft at venera.isi.edu
(Stuart Cracraft) writes:
>How do you slow down cu's file transfer capability (e.g. the tilde-put
>command) ??

In reply I suggested:
>There are two thing I can think of to try.  The first idea is to
>give the yourself a nice value of 39.  Just type 
>
>	nice -39 $SHELL

In article <4241 at encore.UUCP> bzs at encore.com (Barry Shein) responded:
>(this increases priority, beyond the max which is silly and may
>actually do nothing, you also have to be super-user, but that's what
>you meant?)

First of all, it DECREASES priority.  A higher nice value means
lower priority.

Second, 39 is not beyond the maximum, it IS the maximum.  Nice(2)
would set the nice value to the corresponding limit if it was too
large anyway...  

Third, you do not have to be root to increase your nice value
(decrease your priority).

Remember:	the nice value is inversely related to the
		priority, and you need to be root to give
		yourself a higher priority.

Another thing to try, if you have root privilege on the machine
receiving the file, is to decrease the nice value for better
response time by typing:     

	exec nice --39 $SHELL

If your nice value is zero (highest priority), your process is
less likely to get swapped out of memory (which is probably the
biggest problem with a busy machine).

>Sounds like a bad idea, this only operates on the process, not the
>terminal handler, if nothing is competing for time it will have very
>little effect if any, might even make things worse, it's just not the
>process priority that's involved.

I understand that.  Sometimes it will help to slow down the "cu"
on the sending machine or speed up the "cat" on the receiving
machine when one of the machines have other processes running
with a higher (or normal) priority.  It wouldn't make the
situation worse.   

>The other idea also sounds like poking around in the dark.

I was confused and thought he wanted to receive a file from the
remote machine.  Now that I've re-read his message, I agree that
it won't do any good.  Sorry...  

>If that can't work I'd either slow down the baud rate on the sending
>side if possible or look at the NLDELAY parameters in termio(7) and
>stty(1), maybe just before you start a try '~!stty nl1 cr1 < /dev/outputty'
>or some such thing and see if that takes, not sure if cu resets line
>parameters at magical times.

You mean NLDLY.  You could end up with either NULLs or DELs in
your file unless you specify "-ofill" which prevents the use of
these fill characters.  With stty(1) you can use   

	stty -ofill nl1 cr3

to delay output for the maximum amount of time.  (The cr3 will
only be in effect if ONLRET is set.)   

You can change the settings for your out-going modem port by
typing:  

	~!stty -ofill nl1 cr1 </dev/ttyXX

from cu where /dev/ttyXX is the modem line.  No, cu won't reset
the line (at least on my system).  Setting NLDLY is a good idea I
didn't think of.  

Another solution to the problem is to get uucp running on both
machines.  It does a better and more reliable job of transferring
files anyway!

			-Jim

-- 
Jim Logan		logan at vsedev.vse.com
(703) 892-0002		uucp:	..!uunet!vsedev!logan
			inet:	logan%vsedev.vse.com at uunet.uu.net