pag@hao.UUCP (Peter Gross) (02/05/85)
Our main mail machine runs a version of uucp that is based on the original v7 one, but with zillions of bug fixes. We have noticed a peculiar problem: uucp sessions with 4.2bsd uucp sites typically have a drop off in transfer rate for data RECIEVED by us (data SENT goes ok). This is at 1200 baud, where transfer rates on a good connection normally are around 105-110 chars/sec. When the 4.2 problem arises the received rate drops to around 70-75 chars/sec. What is peculiar is that it does not always happen, but usually does. There is never a drop off when the uucp version is v7 or 4.1. Has anyone else noticed this, and if so, are there any fixes? Perplexed, --peter gross hao!pag
mp@allegra.UUCP (Mark Plotnick) (02/06/85)
Check if your neighbors are running the speedup hack in pkcget() that sleeps for 1 second if the read() doesn't return the full number of characters requested. I'm told this scheme was intended to reduce the load on the cpu, at the expense of a slower transfer rate. We looked and saw that we were getting a transfer rate of between 75 and 80 cps for many machines, and a whopping 36cps when sending to machines like vortex. Honeyman came up with a fix so that instead of sleep()ing, uucico nap()s for a time equal to (time it takes 1 char to come in at line's baud rate) x (# of chars left to be read in) We now get transfer rates of 90 to 108 cps with most machines. vortex is up to 80cps. Since uucp here typically spends over 20 hours a day on the phone, cutting down on the transfer time (and our phone bill) was more important than being nice to the cpu; besides, sendmail and uux each take more cpu time just to queue a typical message than uucico takes to transmit it. We still have a spurious problem when we call a 4.2bsd site, send some files, and change roles; sometimes the transfer rate drops to 10 cps (one time it was 3cps). I have no idea what the fix would be, but from looking at an audit the problem appeared to be a protocol botch resulting in lots of retransmitted packets. Mark Plotnick allegra!mp
wls@astrovax.UUCP (William L. Sebok) (02/07/85)
> We have noticed a peculiar problem: > uucp sessions with 4.2bsd uucp sites typically have a drop off in transfer > rate for data RECIEVED by us (data SENT goes ok). This is at 1200 baud, > where transfer rates on a good connection normally are around 105-110 > chars/sec. When the 4.2 problem arises the received rate drops to around > 70-75 chars/sec. I don't know about that but when a but when a 4.2 BSD uucp receives data from elsewhere it sure brings the system to its knees. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls
honey@down.FUN (code 101) (02/07/85)
Here is the pkcget() trick. In the read loop, immediately after the test to see if all the characters have been read has failed, add the following line. nap((n * HZ * 10) / linebaudrate); /* n char times */ This assumes you set linebaudrate (or a similar variable) in fixline(), and that you have a nap call (or a similar function). I wish I didn't have to be so cagey about what I can and can't show here -- the line of code above belongs to me, not AT&T. Now it belongs to everyone. Peter
lauren@vortex.UUCP (Lauren Weinstein) (02/08/85)
That's the first time I've ever seen anyone explicitly give away a single line of code. I wonder if that same line could be used in some other programs. Perhaps it would be of use in some spreadsheets or games? Just kidding, Peter.... By the way, I'm told that the fix Peter gave out only applies to uucp's running the PKSPEEDUP mods under 4.2. Apparently the problem does not occur with 4.1, Version 7, or System V, due to varying tty driver designs in these other systems. People have tested System V explicitly and it does not need the fix; the exact status for 4.1 and Version 7 isn't as clear from what I've heard. However, if PKSPEEDUP is being used by a 4.2 site, that one line apparently makes a tremendous difference, especially when talking to smaller or heavily loaded sites. --Lauren--
mather@uicsl.UUCP (02/08/85)
Is it possible to get the "nap()" call code? We cannot do sub-second sleeps. Or is this V5 stuff ?? Or is this 4.2bsd buried somewhere?? b.c.mather uiucdcs!uicsl!mather
honey@down.FUN (code 101) (02/11/85)
/* "sleep" for n clock ticks */
#include <sys/time.h>
nap(n)
{
struct timeval t;
if (n <= 0 || n > 3000)
return; /* unreasonable */
t.tv_sec = n / 60;
t.tv_usec = ((n % 60) * 1000000) / 60;
(void) select(32, 0, 0, 0, &t);
}
this assumes a 60 hz clock. your mileage may vary.
peterhoney@down.FUN (code 101) (02/12/85)
i recommend the pkspeedup code for all versions of uucp and unix, at all baudrates. it is simply the correct thing to do. lauren and others have observed that short reads are more frequent in 4.2. the obvious conclusion is that 4.2 has a smaller system call overhead, but this goes against my religion. in any case, we have ample evidence that the speedup is useful in 4.2: mark plotnick tested a number of cases and pkspeedup beat them all on throughput *and* cpu overhead. some versions of uucp use the system v VMIN/VTIME trick; as such, the pkspeedup line will usually not be reached. on those (rare) instances when the read returns short, pkspeedup remains the best thing to do. v7 based systems (e.g. 4.1bsd) don't have VMIN. v8 has a buffering line discpline that you push on top of of the ld stack; this makes it look look vaguely like the system v VMIN. i posted a 4.2 nap() here the other day (today?). i have seen nap() hacks for other unix versions in net.sources in the past -- consult net.wanted.sources.
ptw@encore.UUCP (P. Tucker Withington) (02/13/85)
This message is empty.
ptw@encore.UUCP (P. Tucker Withington) (02/13/85)
>Here is the pkcget() trick. In the read loop, immediately after the >test to see if all the characters have been read has failed, add the >following line. > > nap((n * HZ * 10) / linebaudrate); /* n char times */ > Um, Peter, well I guess you have your own spiffy uucp, but in what comes off the 4.2 tape I *think* you want to say: nap(((n-nchar) * HZ * 10) / linebaudrate); /* char times */ to wait for the number of chars you still need (vs. the whole msg.) Yes? Admittedly the pkcget fix is kind of groaty already, but just to save anyone who charged off and plopped your line in verbatim... o.o --tucker ~ P.S. Since you gave the line away, I guess I'll give my 6 chars away too.
honey@down.FUN (code 101) (02/14/85)
thank you for the correction, tucker. i didn't look at 4.2 uucp; they did change pkcget() and your line of code is correct. i'll let you have mine if you let me have yours ... peter
hubert@entropy.UUCP (Steve Hubert) (02/15/85)
> By the way, I'm told that the fix Peter gave out only applies to uucp's > running the PKSPEEDUP mods under 4.2. > > --Lauren-- Sorry, but what is PKSPEEDUP? Can someone give it to me? Steve Hubert Dept. of Stat., U. of Wash, Seattle {decvax,ihnp4,ucbvax!lbl-csam}!uw-beaver!entropy!hubert hubert%entropy@uw-beaver
hammond@petrus.UUCP (02/15/85)
> /* "sleep" for n clock ticks */ > #include <sys/time.h> > nap(n) > { > ... > } > > this assumes a 60 hz clock. your mileage may vary. > > peter Beware, although some 4.2 code, such as accounting stuff, still assumes the clock rate is 60 ticks per sec, I believe a vanilla 4.2 on a vaxen actually runs at 100 ticks per sec.
honey@down.FUN (code 101) (02/15/85)
Beware ... I believe a vanilla 4.2 on a vaxen actually runs at 100 ticks per sec. Rich Hammond A good point. In honey danber, we rely on a manifest called HZ. While some varieties of unix make HZ available in a <sys/include> file, others, e.g., the one I am running here, require you to read kmem. A quick egrep of the 4.2 source shows the same to be true there -- see conf/param.c. For such systems, we set HZ in a uucp header file. Peter
ron@men1.UUCP (Ron Flax) (02/15/85)
>> Is it possible to get the "nap()" call code? >> We cannot do sub-second sleeps. >> >> Or is this V5 stuff ?? >> Or is this 4.2bsd buried somewhere?? >> >> b.c.mather >> uiucdcs!uicsl!mather > > /* "sleep" for n clock ticks */ > #include <sys/time.h> > nap(n) > { > struct timeval t; > > if (n <= 0 || n > 3000) > return; /* unreasonable */ > t.tv_sec = n / 60; > t.tv_usec = ((n % 60) * 1000000) / 60; > (void) select(32, 0, 0, 0, &t); > } > > this assumes a 60 hz clock. your mileage may vary. > > peter [ Replace this MUNGE with your MUNGE ] Peter I think you forgot something?? This code is great if you happen to have the 'select' system call... ...which I believe is a 4.2bsd system call. Ron@men1 (Ron Flax) MTACCS Engineering Network ..!{seismo,umcp-cs}!{prometh,cal-unix}!men1!ron "The opinions expressed herein are mine only if you agree with them."
wls@astrovax.UUCP (William L. Sebok) (02/16/85)
>> /* "sleep" for n clock ticks */ >> #include <sys/time.h> >> nap(n) >> { >> ... >> } >> >> this assumes a 60 hz clock. your mileage may vary. >> >> peter > > Beware, although some 4.2 code, such as accounting stuff, still assumes > the clock rate is 60 ticks per sec, I believe a vanilla 4.2 on a vaxen > actually runs at 100 ticks per sec. This is really irrelevent, since the above code DEFINES a 60 HZ clock, or at least defines the units for this nap() to be in 60ths of a second. The 4.2 BSD select() call used in this code allows time to be specified to the microsecond. This is not to say that microsecond intervals are actually available. There is something to be said for overspecifying the time interval. If a finer clock becomes available on a future machine it can be supported without having to change the units in the software. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls
honey@down.FUN (code 101) (02/19/85)
if you are running system v, you can ignore all of this because you have a superior tty line discipline -- use it. if you are running something else, and you have an inferior v7 based line disc., then you must use something else. like a loop around a register. (this is how honey danber naps under under system v (for smart modem delays), so it must be the right thing to do.) if you can add to your kernel, you can have nap(). (it's not a real unix until it's been hacked for uucp.) i have seen several of them flash past on net.sources in days of yore. or just about anybody could find the right sequence of spl7, timeout, sleep, splx to roll his own. her own. whatever. peter