Path: utzoo!attcan!uunet!vsedev!logan From: logan@vsedev.VSE.COM (James Logan III) Newsgroups: comp.unix.wizards Subject: Re: using System V 'cu' Message-ID: <1245@vsedev.VSE.COM> Date: 21 Nov 88 05:30:11 GMT References: <6808@venera.isi.edu> <1244@vsedev.VSE.COM> <4241@encore.UUCP> Reply-To: logan@vsedev.VSE.COM (James Logan III) Organization: VSE Software Development Lab Lines: 91 In article <6808@venera.isi.edu> cracraft@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@encore.UUCP> bzs@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