daveh@marob.MASA.COM (Dave Hammond) (03/28/89)
The following excerpts from the /usr/spool/uucp/.Admin/xferstats file
indicate that (for this particular session) the actual file transfer rate
over a 2400 baud line was around 75 cps (well under a reasonable *1200*
baud transfer rate):
M (3/27-11:11:15) (C,28337,3) [tty1A] <- 100000 / 1327.400 secs, 75 bytes/sec
{...}
M (3/27-12:56:12) (C,28337,15) [tty1A] <- 100000 / 1287.300 secs, 77 bytes/sec
{...}
M (3/27-13:40:54) (C,28337,20) [tty1A] <- 100000 / 1304.650 secs, 76 bytes/sec
On average, our transfers are much smaller (most under 10K), and the
actual rate (for 2400 baud lines) floats around 100 chars per second (which
still stinks).
What, if any, tuning can be done to increase our uucp performance?
--
Dave Hammond
daveh@marob.masa.commanes@marob.MASA.COM (Steve Manes) (03/28/89)
From article <601@marob.MASA.COM>, by daveh@marob.MASA.COM (Dave Hammond): > The following excerpts from the /usr/spool/uucp/.Admin/xferstats file > indicate that (for this particular session) the actual file transfer rate > over a 2400 baud line was around 75 cps (well under a reasonable *1200* > baud transfer rate): I heard an unconfirmed story that Xenix 2.3's UUCP transfer time accounting is broken and shouldn't be trusted. According to a friend of mine, he spent several hours sending files from his machine to a Xenix machine in Texas and the difference in transfer time, according to the logs of the two respective machines, was almost a factor of 2. He says he believes that it's a bug in the reading of the HZ variable. -- Steve Manes Roxy Recorders, Inc. Magpie-HQ BBS UUCP : {rutgers|cmcl2}!hombre!magpie!manes (212)420-0527 Smail: manes@MASA.COM
frank@rsoft.UUCP (Frank I. Reiter) (03/29/89)
In article <603@marob.MASA.COM> manes@marob.MASA.COM (Steve Manes) writes: > >I heard an unconfirmed story that Xenix 2.3's UUCP transfer time >accounting is broken and shouldn't be trusted. You can "Trust" it to be out by a factor of exactly 2.5. If it says that you achieved 200 cps then you know that you achieved 500 cps. I'm told they used a HZ value of 20 instead of 50. -- _____________________________________________________________________________ Frank I. Reiter UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank Reiter Software Inc. frank@rsoft.bc.ca, a2@mindlink.UUCP Langley, British Columbia BBS: Mind Link @ (604)533-2312, login as Guest
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (03/29/89)
In article <601@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes: | What, if any, tuning can be done to increase our uucp performance? I had the same problem. I set windows to 7. The problem went away. You will have to ask someone for a patch for v < 2.3.1, I have installed it but lost the doc. 2.3.1 has the info in the manual somewhere. You diddle something with adb from 3 to 7. Now MY question: why in hell doesn't SCO shep uucico set to w=7 by default? Is there a prize for bad performance. I see over 200cps on a 2400 baud line, about 600 on 9600 (but the other machine is an overloaded pig). -- bill davidsen (wedu@crd.GE.COM) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
kory@avatar.UUCP (Kory Hamzeh) (03/29/89)
In article <603@marob.MASA.COM>, manes@marob.MASA.COM (Steve Manes) writes: > From article <601@marob.MASA.COM>, by daveh@marob.MASA.COM (Dave Hammond): > > The following excerpts from the /usr/spool/uucp/.Admin/xferstats file > > indicate that (for this particular session) the actual file transfer rate > > over a 2400 baud line was around 75 cps (well under a reasonable *1200* > > baud transfer rate): > > I heard an unconfirmed story that Xenix 2.3's UUCP transfer time > accounting is broken and shouldn't be trusted. According to a friend of > mine, he spent several hours sending files from his machine to a Xenix > machine in Texas and the difference in transfer time, according to the > logs of the two respective machines, was almost a factor of 2. He says > he believes that it's a bug in the reading of the HZ variable. Yes, there is a bug in Xenix 2.3.1 HDB uucico. It reports the wrong transfer rate. Its because for some stupid reason, it hardcoded for a HZ=20 machine (an XT!!!). 286 and 386 have HZ set to 50. Here is a patch you can make to fix this problem: Run "adb -w" on uucico (in /usr/lib/uucp, you will need to be root) Here is a script: ----- start of patch ---- $ adb -w uucico * $x * millitick+32?ia _millitick+0x32: mov ax,0x14 _millitick+0x35: * .?x _millitick+0x32: 0x14b8 * .?w 32b8 _millitick+0x32: 0x14b8= 0x32b8 * .?ia _millitick+0x32: mov ax,0x32 _millitick+0x35: * $q $ ---- end of patch ---- If you're wondering, the mov ax,0x14 is setting up a divide by 20 for HZ=20 machines. The 0x32 changes it to 50 for HZ=50 machines.. Hope it helps, --kory -- ------------------------------------------------------------------------------- Kory Hamzeh UUCP: ..!uunet!psivax!quad1!avatar!kory INTERNET: avatar!kory@quad.com
jbayer@ispi.UUCP (Jonathan Bayer) (03/29/89)
In article <603@marob.MASA.COM> manes@marob.MASA.COM (Steve Manes) writes: > >I heard an unconfirmed story that Xenix 2.3's UUCP transfer time >accounting is broken and shouldn't be trusted. According to a friend of >mine, he spent several hours sending files from his machine to a Xenix >machine in Texas and the difference in transfer time, according to the >logs of the two respective machines, was almost a factor of 2. He says >he believes that it's a bug in the reading of the HZ variable. This is a known bug. The HZ value has been hardcoded in place :-( Erik Murrey posted the following message back in October which describes how to patch uucico. I applied it and it works well. This also applies the window=7 patch. JB ----------------------- cut here ---------------------- From uunet!mpx2.UUCP!erik Sun Oct 30 12:22:00 1988 Path: ispi!uunet!husc6!bloom-beacon!apple!rutgers!bpa!cbmvax!vu-vlsi!mpx1!mpx2!erik From: erik@mpx2.UUCP (Erik Murrey) Newsgroups: comp.unix.xenix Subject: patch for correct xferstats Message-ID: <263@mpx2.UUCP> Date: 30 Oct 88 17:22:00 GMT Organization: MPX Data Systems, Inc. , Wayne, PA Lines: 51 As distributed with my version of SCO 2.3.1 for 386AT's, the new HDB uucico records incorrect transfer times in /usr/spool/uucp/.Admin/xferstats. This is because the version I got was hard coded for a HZ=20 clockrate machine (i.e. an XT!) Since both the AT286's and AT386's run at HZ=50, uucico needs to be patched to record reasonable time in xferstats. (If this has already been posted, then hit 'n'...) Also, my version has a symbol table, for other patches (like windows=7, might as well do that while your in there...) Run "adb -w" on uucico (in /usr/lib/uucp, you will need to be root) Here is a script: ----- start of script ---- $ date Sun Oct 30 09:03:56 PST 1988 $ copy -om uucico uucico~ $ adb -w uucico * windows/x _windows: 0x3 * windows/w 7 _windows: 0x3= 0x7 * $x * millitick+32?ia _millitick+0x32: mov ax,0x14 _millitick+0x35: * .?x _millitick+0x32: 0x14b8 * .?w 32b8 _millitick+0x32: 0x14b8= 0x32b8 * .?ia _millitick+0x32: mov ax,0x32 _millitick+0x35: * $q $ ---- end of script ---- If you're wondering, the mov ax,0x14 is setting up a divide by 20 for HZ=20 machines. The 0x32 changes it to 50 for HZ=50 machines.. The patch to windows is the famous WINDOWS=7 patch that helps over lines with big delays (eg PC-Pursuit). Erik Murrey MPX Data Systems, Inc. erik@mpx2.UUCP ...!{bpa,spl1,cbmvax,vu-vlsi}!mpx1!erik -------------------------- cut here ---------------------------- -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi.UUCP