kak@hico2.UUCP (Kris A. Kugel) (05/29/91)
In around 107 somewhat related articles, several authors discuss
Hardware Flow Control, telebits, and throughput.
I thought I'd add some transfer statistics from hico2,
a 3b1 with starlan (low option), serial patch, HDB uucp,
and a Trailblazer Plus (4.0 roms), using uucp spoofing
and locked 19200 interface speed.
What I did was look at the files /usr/spool/uucp/.Adm/xferstats
and /usr/spool/.Old/xferstats, edit out irrelavant information,
and then throw out data on very short transfers ( < 3 seconds ),
or slow transfers ( < 1000 bytes/sec ). I've ordered the remaining
entries from faster to slowest.
I'm seeing some respectable top transfer rates.
Note that some of these are on substantial transfers.
Also note that I get occasional good transfers
with several machines, in both directions
(although one direction seems to have a faster top speed
than the other, 1266 bytes/sec vs. 1754 bytes/sec).
I think only dxis and maybe zorch are 3b1s.
I suspect that a 3b1 can send faster than it can receive.
Assuming that these numbers are realistic, and
at least somewhat meaningful,
it's at least POSSIBLE to get good throughput.
For what it's worth, here it is:
kadath -> 6902 / 3.933 secs, 1754 bytes/sec
kadath -> 6449 / 3.683 secs, 1751 bytes/sec
kadath -> 6385 / 3.650 secs, 1749 bytes/sec
kadath -> 5684 / 3.250 secs, 1748 bytes/sec
tsdiag -> 5359 / 3.066 secs, 1747 bytes/sec
att -> 6195 / 3.550 secs, 1745 bytes/sec
tsdiag -> 5466 / 3.133 secs, 1744 bytes/sec
kadath -> 5467 / 3.133 secs, 1744 bytes/sec
kadath -> 5435 / 3.116 secs, 1744 bytes/sec
kadath -> 11771 / 6.750 secs, 1743 bytes/sec
kadath -> 14169 / 8.133 secs, 1742 bytes/sec
kadath -> 13842 / 7.950 secs, 1741 bytes/sec
kadath -> 12053 / 6.933 secs, 1738 bytes/sec
kadath -> 8429 / 4.850 secs, 1737 bytes/sec
kadath -> 6863 / 3.950 secs, 1737 bytes/sec
kadath -> 13063 / 7.533 secs, 1734 bytes/sec
tsdiag -> 5201 / 3.000 secs, 1733 bytes/sec
kadath -> 5201 / 3.000 secs, 1733 bytes/sec
kadath -> 12628 / 7.283 secs, 1733 bytes/sec
att -> 6010 / 3.466 secs, 1733 bytes/sec
kadath -> 5341 / 3.083 secs, 1732 bytes/sec
kadath -> 11177 / 6.450 secs, 1732 bytes/sec
kadath -> 10477 / 6.050 secs, 1731 bytes/sec
kadath -> 8708 / 5.033 secs, 1730 bytes/sec
kadath -> 7121 / 4.116 secs, 1730 bytes/sec
kadath -> 6278 / 3.633 secs, 1728 bytes/sec
tsdiag -> 6018 / 3.483 secs, 1727 bytes/sec
kadath -> 5407 / 3.133 secs, 1725 bytes/sec
att -> 5013 / 2.916 secs, 1719 bytes/sec
kadath -> 8968 / 5.233 secs, 1713 bytes/sec
att -> 5998 / 3.516 secs, 1705 bytes/sec
att -> 5069 / 3.016 secs, 1680 bytes/sec
tsdiag -> 8080 / 4.900 secs, 1648 bytes/sec
tsdiag -> 7229 / 4.400 secs, 1642 bytes/sec
tsdiag -> 7148 / 4.383 secs, 1630 bytes/sec
tsdiag -> 7432 / 4.566 secs, 1627 bytes/sec
tsdiag -> 5341 / 3.283 secs, 1626 bytes/sec
kadath -> 5108 / 3.166 secs, 1613 bytes/sec
kadath -> 28428 / 18.233 secs, 1559 bytes/sec
kadath -> 44627 / 29.816 secs, 1496 bytes/sec
tsdiag -> 7403 / 5.166 secs, 1433 bytes/sec
dxis -> 9268 / 6.516 secs, 1422 bytes/sec
tsdiag -> 8433 / 5.966 secs, 1413 bytes/sec
tsdiag -> 8665 / 6.150 secs, 1408 bytes/sec
tsdiag -> 10716 / 8.250 secs, 1298 bytes/sec
tsdiag -> 5405 / 4.216 secs, 1282 bytes/sec
dxis -> 10092 / 7.933 secs, 1272 bytes/sec
tsdiag -> 10373 / 8.166 secs, 1270 bytes/sec
kadath <- 16253 / 12.833 secs, 1266 bytes/sec
zorch <- 54500 / 43.333 secs, 1257 bytes/sec
zorch <- 113339 / 90.316 secs, 1254 bytes/sec
tsdiag -> 12933 / 10.466 secs, 1235 bytes/sec
kadath <- 11431 / 9.283 secs, 1231 bytes/sec
kadath <- 10022 / 8.166 secs, 1227 bytes/sec
tsdiag -> 16614 / 14.333 secs, 1159 bytes/sec
zorch <- 22904 / 19.966 secs, 1147 bytes/sec
tsdiag -> 15478 / 13.683 secs, 1131 bytes/sec
tsdiag -> 23642 / 21.950 secs, 1077 bytes/sec
tsdiag -> 22620 / 21.383 secs, 1057 bytes/sec
tsdiag -> 37347 / 37.016 secs, 1008 bytes/sec
zorch <- 11179 / 11.116 secs, 1005 bytes/sec
It'd be interesting to see if other people are or aren't
getting these kind of numbers. Your milage may vary.
Kris A. Kugel
( 908 ) 842-2707
uunet!tsdiag.ccur.com!hico2!kak (maybe)
{daver,ditka,zorch}!hico2!kak
internet: kak@hico2.westmark.comdnichols@ceilidh.beartrack.com (DoN Nichols) (05/30/91)
In article <1789@hico2.UUCP> kak@hico2.westmark.com writes: > >In around 107 somewhat related articles, several authors discuss >Hardware Flow Control, telebits, and throughput. > >I thought I'd add some transfer statistics from hico2, >a 3b1 with starlan (low option), serial patch, HDB uucp, >and a Trailblazer Plus (4.0 roms), using uucp spoofing >and locked 19200 interface speed. > >What I did was look at the files /usr/spool/uucp/.Adm/xferstats >and /usr/spool/.Old/xferstats, edit out irrelavant information, >and then throw out data on very short transfers ( < 3 seconds ), >or slow transfers ( < 1000 bytes/sec ). I've ordered the remaining >entries from faster to slowest. But, the slow transfers are a symptom of the problem we've been discussing! They result from lost data forcing a timeout and a resend of the affected packet. What percentage of the whole was the collection of slow transfers? [ ... ] >I suspect that a 3b1 can send faster than it can receive. That, I believe, has been the general concensus of the discussion. >Assuming that these numbers are realistic, and >at least somewhat meaningful, >it's at least POSSIBLE to get good throughput. > >For what it's worth, here it is: > [ ... acres of statistics trimmed out ] I found that, at least with the ethernet enabled, the very slow entries more than ate up the gain by running at 19200 instead of 9600. (It also usually ended in a timeout and failure of the transfers, if there was more than one package of news waiting to come to my machine. Also, when I tried the 'e' protocol, at 9600, outgoing packets improved, while incoming ones failed with the ethernet enabled. I didn't bother trying it with the ethernet disabled, since I no longer run that way. (News comes into the 3b1, I am using a Sun 2/120 as a terminal via ethernet. Love those 80x65 xterm windows. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
rog@ingres.com (Roger Taranto) (06/03/91)
In article <1991May29.224256.24529@ceilidh.beartrack.com> dnichols@ceilidh.beartrack.com (DoN Nichols) writes: >In article <1789@hico2.UUCP> kak@hico2.westmark.com writes: >>I suspect that a 3b1 can send faster than it can receive. > > That, I believe, has been the general concensus of the discussion. That seems to make sense. It seems to me that terminal drivers and interrupt routines were designed to be able to send lots of data, but receive comparatively low amounts. (How many users do you know who can type at 19200 bps?) We have a brave, little microvax II with 4 Telebits connected; it serves as our UUCP and news machine. We can get ~14500 bps on our outgoing connections, but we can't do better than ~9700 bps on the incoming connections. With nothing else going on and just one UUCP connection (incoming), the CPU is pegged at ~93-95% trying to handle the single character interrupts for that uucico process. I imagine that the 3B1 is similarly handicapped, i.e., it's running out of CPU trying to handle single character interrupts while receiving data via the serial lines. -Roger {mtxinu,pacbell,amdahl,sun,hoptoad}!rtech!rog rog@ingres.com