murf@caeco.UUCP (Steve Murphy) (08/13/87)
Ultra-fast 'g' Protocol UUCP File Transfer Telebit 'TrailBlazer'
Modems---
I would like to report personal experience using Telebit's new
UUCP transfer mode while in the 'FAST' mode.
Using a vanilla Sun 3/160, with generic uucp provided by Sun
Microsystems, I have recorded an average throughput of about
12K baud. To some this may not seem duly impressive, except for
the following:
A. The Sun 3/160 (and all the sun 2's and the 3/110's also) cannot
hardware handshake AT ALL. They say they do, but in one
direction only, usually so the external device can shut up
the CPU, but not vice-versa. And, as far as I know, this is
available as a special kernel fix (zs_asynch.o) for some $$$.
But, you have to TURN IT ON. Their uucp package can't/won't
do this, so HARDWARE HANDSHAKE is NOT AN OPTION. Now, if I
worked for Sun, I'd blush, because this is a serious systems
shortfall for a company supposed to be at the fore-front of
technology. But they're not unique in this respect, as relatively
few companies even know what hardware (RTS/CTS) handshake is.
(except maybe Apollo).
Even more Ludicrous: Sun OEM's MTI 8/16 port asynch port cards
--which have hardware handshake capability; SUN DISABLES THIS
FEATURE IN IT'S DRIVER. Sun is very philosophical about this.
The only good thing I can say about it is, "At least they're
consistant."
B. At 19200, SUN DOESN'T SOFTWARE HANDSHAKE EITHER. Apparently, the driver
can't send an X-off before the internal buffer overflows. Silo
overflows galore. Try it. Turn on TANDEM and CBREAK and send it
about 10K of data at 19200. I've talked to people over there, and
this problem didn't seem to suprise them. This, by the way,
was on an MTI port. I haven't tried it on the Cpu a/b ports yet,
but I'm not very optimistic.
C. At any rate, until now, with Sun systems, high speed serial devices
were not usable. By experimentation, I know is that the Suns cannot
handle long blasts at 9600 baud without handshaking.
So what does the TrailBlazer do to overcome these serious shortfalls
and still operate on the normal asynch ports at 19200 baud?
Their modems talk the 'g' protocol. They detect the normal startup sequences for
the 'g' protocol (the default protocol currently used by perhaps 95% of
the usenet/UUCP community) and go into a 'protocol spoof mode'. Each
modem acknowleges locally the packets sent to it. The modem on the sending
side gathers packets as fast as it can, sending the acknowledgements itself,
and ships the data to the other modem in a 1-way all-out 'blast' mode.
The modem on the recieve side hands over the packets just like they were
sent, and swallows the acknowledgements. Since the recieve operation is
decidedly the slow part, the receiving modem's buffer will invariably fill,
at which time, the PEP inter-modem communications tell the sending modem
to hold off, and the sending modem holds off. It's buffer will then likewise
fill, and it stops the sending system by holding off on it's acknowledgement
packets.
This simple way of handshaking kills all the problem birds in a system-
independent way. It is actually enhanced by the relatively small packet
size of the uucp g protocol. Thus I can shove data into my 3/160 at about
12Kbaud and not have to worry one whit about the total lack of handshaking
ability. I'm not sure now which is the limiting factor: the ability of the
Sun to handle data any faster than that, or noise limitations on the line.
I shipped a 1,458,176 byte file in 19.98 minutes, among other tests. This
is equivalent to sending data at 4.3 Meg per Hour (roughly).
I forsee nothing but neat things as respecting the TrailBlazer. Conversations
with Mike Ballard at Telebit (1-408-996-8000), who was in charge of the
development of the 'g-spoof' mode, and who is now National Marketing
Manager for this product, revealed that there it is definitely not
impossible that Usenet sites could obtain a Trailblazer for 1/2 price,
about $670. This would be an EXCELLENT price, with many 2400 baud modems
---- ---------
costing more than this (and the Trailblazer talks 2400, 1200 and 300 in
all their flavors just as well as any I've played with, [and I've played
with more than a few, believe me] ).
I'm super-excited about this development and I see definite possibilities
for revolutionizing the Usenet community. No-one has anything like this
out there. The figures I gave were for uncompressed data. What's to keep me
from compressing data before I uucp it, and maybe doubling my total thruput
thereby? If I can thereby send 8.6 meg of data in 1 hour over normal phone
lines, after decompression, who's going to complain about it? Only the phone
company, for the reduction of my bills.
PARTICULARS:
I've tested it locally between a sun 3/160 and a sun 3/110, and obtained
these results: small files send at 13Kbaud, rec. at 11Kbaud, ave=12Kbaud.
Both sides used /dev/cua (ttya), and not the MTI ports.
When the MTI ports were used (same machine - two phone lines and two
MTI ports) thruput at 19200 was only 5Kbaud, and at 9600, 6Kbaud.
Perhaps differences here are attributable to handshake issues, driver
issues, who knows.
Between California and Utah: A Sun 3/160 in Santa Clara and one just like it
here in Salt Lake City. Both have TrailBlazers on the A/B ports. Exactly similar
results ( Ave= 12Kbaud (1,200cps)). And I noted that
2400 baud communications between the two sites is fairly noisy and there
is plenty of garbage. Connecting FAST, though, is easy, and note the
thruput even though the same noisy lines were used as the 2400 baud modems.
NOTES:
Sun's uucico doesn't know about 19200, and doesn't understand the
Trailblazer's return codes. The 19200 problem is fixable by robbing
it of 4800 baud capability via an adb -w fix (which Mike Ballard gave
me). The return code problem is overcome by using the DIR access methods
in L-devices(?) and L.sys. An L.sys entry like this may be used:
hostname Any,0 cua 19200 cua "" ATV0E0X0\r 0 ATD14085551212\r 1 "" login: Ugotit etc....
Note that I locked my interface speed at 19200. (why not?) In fact, I override
the factory settings thusly:
ATs45=255s52=1s53=3s58=0s66=1s111=30s51=5
This allows remote command processing, sets DTR interpretation reasonably,
the rs232 interface to standard interpretations, turns off flow control,
locks the interface speed, sets up the uucp transfer mode,
and sets the interface speed to 19200.
Enough for now. If you have questions, etc. Write or call me.
---
--
Steve Murphy, CAECO, Inc., 7090 South Union Park Avenue,
Suite 200, Midvale, UT 84047
(801)255-8880
<WORLD>!{byuadam,utah-cs,nrc-ut,wicat}!caeco!murfroy@phri.UUCP (Roy Smith) (08/15/87)
In article <192@caeco.UUCP> murf@caeco.UUCP (Steve Murphy) writes: > The Sun 3/160 (and all the sun 2's and the 3/110's also) cannot hardware > handshake AT ALL. [...] Now, if I worked for Sun, I'd blush, because this is > a serious systems shortfall for a company supposed to be at the fore-front > of technology. But they're not unique in this respect, as relatively few > companies even know what hardware (RTS/CTS) handshake is. Arghhhhh! Maybe the reason Sun's RS-232 ports don't do RTS/CTS handshaking is because if they did, it wouldn't be RS-232. As defined in the standard, RS-232 has no flow-control. Granted, hardware flow contol is nice, and you might reasonably argue that the lack of such flow control is a major mis-feature of RS-232, but the thing to do is to define a new standard which has that feature, make sure everybody in the industry implements it in exactly the same way, and call it something different. You would probably want to make it upward compatible with RS-232, but that's another story. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
romain@pyramid.UUCP (08/15/87)
I would caution people who want to believe 'g' spoof mode is a UNIX panacea. It is a clever hack for people running uucp, but anyone else still needs some form of hardware flow control. I doubt anyone wants to graft 'g' protocol into cu or tip, and the thought of adding Kermit or XMODEM spoofware makes my stomach turn. Otherwise, it is just another measure that might delay the collapse of Usenet. I also seem to remember Rick Adams once said that on a VAX 11/780 using 'g' protocol, transfers maxed out at about 9kbps. This isn't a great tragedy if you've got lots of cheap CPU cycles, but I can imagine people on slower systems unable to afford the impact of running 'g' protocol at high speeds. (Still, it does work with existing systems. I'm tempted to add a remark like, "I smell Peter Honeyman" but that would be too cute...) While the Telebits look better than other "fast" modems available today, they are better in the same sense that a Model A Ford is better than a Model T; the technology is still young and developing. Trailblazers are exciting pieces of equipment, but they still have basic drawbacks; e.g., interactive unresponsiveness in FAST mode, and more seriously, the need for data overrun protection. Anyone who buys Telebits should be aware of these limitations and not expect miracles.
jhc@mtune.ATT.COM (Jonathan Clark) (08/17/87)
In article <2849@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > Arghhhhh! Maybe the reason Sun's RS-232 ports don't do RTS/CTS >handshaking is because if they did, it wouldn't be RS-232. As defined in the >standard, RS-232 has no flow-control. Granted, hardware flow contol is nice, Not quite true. Full-duplex RS-232 as defined in the standard has no flow control, true. If you read the standard then it's very obvious that RTS and CTS are only usefully defined when the interface is in half-duplex. Strictly, use of these leads as flow control signals does violate the letter of the RS-232 standard, but EIA flow control is so useful that I (at least) think that this should be in the standard. And the best way to get it there is to put it in products. As long as it's an option no-one should get upset over it. Anyone out there on the RS-232D committee? -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
jhc@mtune.ATT.COM (Jonathan Clark) (08/17/87)
In article <4951@pyramid.pyramid.com> romain@pyrnova.UUCP (Romain Kang) writes: >I would caution people who want to believe 'g' spoof mode is a UNIX >panacea. It is a clever hack for people running uucp, but anyone else >still needs some form of hardware flow control. Yes, but the two of them serve different purposes. Given the TrailBlazer's packetizing algorithm, hardware flow control would not make any difference to the performance (and my understanding is that is *does* support EIA flow control anyway). Sure, what they do is a hack, but it's a clever hack (providing it works). -- Jonathan Clark [NAC,attmail]!mtune!jhc An Englishman never enjoys himself except for some noble purpose.
schoff@a.nyser.net (Martin Lee Schoffstall) (08/17/87)
Now that the "g" protocol is handled in a rational manner what is the status of "SLIPNET" support. Cornell&RPI ran a slipnet connection with a TELEBIT and never dead better than 4800 baud. Marty Schoffstall schoff@nic.nyser.net
beattie@netxcom.UUCP (Brian Beattie) (08/17/87)
RS232 has flow control but only in one direction. DCE asserts CTS (Clear To Send) DTE may transmit DCE deasserts CTS DTE may not send. RTS signals DCE that DTE wants to send (Request To Send). Some people have used RTS for flow control this is tecnically incorrect. -- ----------------------------------------------------------------------- Brian Beattie | Phone: (703)749-2365 NetExpress Communications, Inc. | uucp: seismo!sundc!netxcom!beattie 1953 Gallows Road, Suite 300 | Vienna,VA 22180 |
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/03/87)
In article <376@nysernic> schoff@nic.nyser.net (Martin Lee Schoffstall) writes: >Now that the "g" protocol is handled in a rational manner what is >the status of "SLIPNET" support. Cornell&RPI ran a slipnet connection >with a TELEBIT and never dead better than 4800 baud. This was because of an intervening fuzzball running at 4800 bps -- they could not try the Trailblazer at any faster rate. Those sites that have used the Trailblazers at 9600 and 19200 with SLIP have reported excellent results. I don't have the specifics handy, but I will be soon running SLIP over a bunch of Trailblazers connected to Pyramids. I'll post the results when I'm done. Under great duress from about a dozen people, I'll also be getting the 'g' spoofing PROMs into our Trailblazers real soon; any site who wants to link up their Trailblazers to ours is more than welcome. (We've been using the 'f' protocol on the Trailblazer for over a year now, and have generally not had many sites to talk to.) <csg>