cracraft@venera.isi.edu (Stuart Cracraft) (11/16/88)
How do you slow down cu's file transfer capability (e.g. the tilde-put command) ?? When the transmitting machine is fast, such as a PC running Unix System V, and the connection is slow (a 1200 baud modem) to another Unix system, a few seconds after issuing the tilde-put command, the input buffer of the target system overflows and one continuous bell is heard. The file isn't successfully transferred. Any ideas on how to solve this one? Stuart
logan@vsedev.VSE.COM (James Logan III) (11/19/88)
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) ?? 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 and as soon as you get a prompt, "take" the file. The second idea is to rewrite the "cat" command that cu invokes on the machine that has the original file and put it in a personal bin directory that is listed before /bin and /usr/bin in your $PATH. The following program reads X number of characters, sleeps for several seconds and then writes them to stdout. Put it in a file called "cat.c", then type this at a shell prompt: mkdir $HOME/bin PATH=$HOME/bin:$PATH export PATH make cat cp cat $HOME/bin and you're ready to roll. Let me know how it goes. -Jim ------------- CUT HERE ------------ 8< ------------------------- #include <stdio.h> #define BLOCKSIZ 256 #define SLEEPVAL 2 main(argc, argv) int argc; char **argv; { char buf[BLOCKSIZ]; int numread; FILE *infd; if ((infd = fopen(argv[1], "r")) == NULL) { fprintf(stderr, "%s: Can't open ", *argv); perror(argv[1]); exit(1); } while (numread = fread(buf, 1, sizeof(buf), infd)) { if (fwrite(buf, 1, numread, stderr) != numread) { fprintf(stderr, "%s: ", *argv); perror("Write error"); break; } sleep(SLEEPVAL); } fclose(infd); exit(0); } ------------- CUT HERE ------------ 8< ------------------------- -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net
bzs@encore.com (Barry Shein) (11/20/88)
In reply James Logan suggests >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) ?? > >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 (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?) 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. The other idea also sounds like poking around in the dark. If something is competing for processor time it better be the process of a good personal friend :-) Tip (bsd cu superset) has linedelay and chardelay, I guess cu doesn't, you might consider just getting Kermit which is free, probably works on your system and will solve this problem and provide reliable transfer as well, CKermit is very nice (-19) and worth putting up. 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. Your problem is you're trying to kludge around a real problem the old cu doesn't address adequately, period. I recommend something like Kermit, cu is really old and simple-minded. -Barry Shein, ||Encore||
jc@minya.UUCP (John Chambers) (11/21/88)
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) ?? > > When the transmitting machine is fast, such as a PC running Unix > System V, and the connection is slow (a 1200 baud modem) to another > Unix system, a few seconds after issuing the tilde-put command, the > input buffer of the target system overflows and one continuous bell is > heard. The file isn't successfully transferred. > > Any ideas on how to solve this one? I've been bitten by this one on several systems. What I've done is write my own version of cat (typically 10 lines or so) that runs quite slowly, typically by reading 100-byte chunks, writing them, and then doing sleep(1). I make a script called "cu" that has this "cat" in its search path before /bin, and knows the name of the real cu. It seems to work pretty well. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
logan@vsedev.VSE.COM (James Logan III) (11/21/88)
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 </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@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net
pmech@oucsace.cs.OHIOU.EDU (Paul J. Mech) (11/22/88)
In article <138@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: - 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) ?? - > - I've been bitten by this one on several systems. What I've done is - write my own version of cat (typically 10 lines or so) that runs quite - slowly, typically by reading 100-byte chunks, writing them, and then - doing sleep(1). I make a script called "cu" that has this "cat" in - its search path before /bin, and knows the name of the real cu. It - seems to work pretty well. - A simular technique that I use is a C program that metes out characters with any number of delay schemes using fflush(), sleep(), and optional characters in the file to flag additional delays. I use this as a filter with the ~$ command. It was a quick and dirty workaround to transfer a file to an IBM mainframe that didn't seem to like me at all, but has prooven to be of enough utility to keep around.
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (11/23/88)
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) ?? I know this is a dumb comment, but you did set xon/xoff flow control on the destination system, didn't you. Check your stty options. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
allbery@ncoast.UUCP (Brandon S. Allbery) (11/26/88)
As quoted from <4241@encore.UUCP> by bzs@encore.com (Barry Shein): +--------------- | In reply James Logan suggests | >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) ?? | > | >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 | | (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?) +--------------- You DID see the subject line, didn't you? It very clearly says "System V". Csh -- BSD, *not* System V -- uses "+nn" to lower priority and "-nn" to raise it. Sh and ksh -- which are what are USUALLY found on System V systems -- use "-nn" to lower priority and "--nn" (yes, that's TWO hyphens) to raise it. Sigh. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
avr@mtgzz.att.com (a.v.reed) (11/29/88)
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) ??
<
< When the transmitting machine is fast, such as a PC running Unix
< System V, and the connection is slow (a 1200 baud modem) to another
< Unix system, a few seconds after issuing the tilde-put command, the
< input buffer of the target system overflows and one continuous bell is
< heard. The file isn't successfully transferred.
<
< Any ideas on how to solve this one?
<
< Stuart
Use a protocol-based file transfer program - that is why I put the
tilda-plus escape in cu in the first place. For example, start up umodem
on the remote, then do
~+ umodem -options < /dev/culine
or the equivalent with the protocol of your choice. This way you can
also transfer binary files. (No, I don't know why ~+ is still
undocumented, even though it has been in cu for 6 years already. Or why
it is not in SVID. So it is possible that your machine's cu doesn't have
it. But probably it does.... )
Adam Reed (avr@mtgzz.ATT.COM)les@chinet.chi.il.us (Leslie Mikesell) (11/30/88)
In article <4700@mtgzz.att.com> avr@mtgzz.att.com (a.v.reed) writes: > ~+ umodem -options < /dev/culine >[...](No, I don't know why ~+ is still >undocumented, even though it has been in cu for 6 years already. Or why >it is not in SVID. So it is possible that your machine's cu doesn't have >it. But probably it does.... ) Perhaps the reason is that it is not compiled into the official AT&T release, at least not up to SysVr3.1 on the 3B2's. It would be extremely useful, though, as would the ability to execute a script like that found in the Dialers file at an arbitrary time (i.e. after the connection is made). The code is obviously already there. Is Larry Wall listening? How about adding ioctl() to perl so we can use it instead? Les Mikesell
avr@mtgzz.att.com (a.v.reed) (12/02/88)
In article <7031@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: < In article <4700@mtgzz.att.com> avr@mtgzz.att.com (a.v.reed) writes: < > ~+ umodem -options < /dev/culine < < >[...](No, I don't know why ~+ is still < >undocumented, even though it has been in cu for 6 years already. Or why < >it is not in SVID. So it is possible that your machine's cu doesn't have < >it. But probably it does.... ) < < Perhaps the reason is that it is not compiled into the official AT&T < release, at least not up to SysVr3.1 on the 3B2's. It would be extremely < useful, though, as would the ability to execute a script like that < found in the Dialers file at an arbitrary time (i.e. after the connection < is made). The code is obviously already there. The code for ~+ is #ifdef'ed in the HDB cu source. If you have HDB source, just remake cu with the appropriate -D option. That's what we have on our System V machines. Adam Reed (avr@mtgzz.att.com)
guy@auspex.UUCP (Guy Harris) (12/04/88)
>The code for ~+ is #ifdef'ed in the HDB cu source. If you have HDB >source, just remake cu with the appropriate -D option. Unfortunately, many (quite possibly "most") people with HDB binaries do not have HDB source.... The "#ifdef" symbol is "forfutureuse". Eventually, "future" becomes "present"; what is the event being waited for here? Is there something about it that doesn't work, or is somebody just chicken**** about enabling it?
avr@mtgzz.att.com (a.v.reed) (12/06/88)
In article <575@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes:
< >(avr) The code for ~+ is #ifdef'ed in the HDB cu source. If you have
< > HDB source, just remake cu with the appropriate -D option.
<
< Unfortunately, many (quite possibly "most") people with HDB binaries do
< not have HDB source....
<
< The "#ifdef" symbol is "forfutureuse". Eventually, "future" becomes
< "present"; what is the event being waited for here? Is there something
< about it that doesn't work, or is somebody just chicken**** about
< enabling it?
No, there's nothing about it that doesn't work. It has been in use for 6
years now by people who have known about it, and has worked fine for all
of them - not a single MR on it to date. As for what is holding back the
people who decide about externally distributed UNIX(R), I can only
guess, since I'm not one of them. My guess is that it is a standards
issue: they're waiting for code merger with SUN/BSD, and the analogous
option in "tip" is called something else. But then, I only work here....
Adam Reed (avr@mtgzz.ATT.COM)guy@auspex.UUCP (Guy Harris) (12/08/88)
>My guess is that it is a standards issue: they're waiting for code >merger with SUN/BSD, and the analogous option in "tip" is called >something else. Unlikely: 1) S5R3 antedates the AT&T/Sun agreement, and the #ifdef in question is in S5R3 (and may be in earlier releases); 2) the BSD "tip" has a "cu mode" wherein it emulates V7's "cu", so if the two are merged into one utility (as opposed to just leaving them as two separate programs), it could use different options in different modes.