eric@snark.uu.net (Eric S. Raymond) (04/29/89)
Well. The last week has been...interesting. I've had to change development
machines twice. I had carefully uucped almost everything off the 386 clone box
to the T5100 and spiffy new 3-1/2" backup media last week. So when time came
to bid farewell to the clone, I simply shipped over the last few files, powered
it down, changed my modem connections...
...and discovered that the $#&^@!! T5100 serial port wouldn't talk to my
Trailblazer! Aaargh!
After a day and a half of experimentation, (fruitless) phone calls to Toshiba
tech support, and extreme frustration, I finally pinned down the problem. The
T5100 uses the same el cheapo 8251 UART-based port hardware design found in
braindamaged DOS machines everywhere; the chip only supports one handshake
line, and they did *not* wire it to support RTS/CTS handshaking.
Result? The 'blazer has to have S58=0 (no handshake) or S58=3 (XON/XOFF) set
for the T5100 to even *open* it -- and XON/XOFF isn't usable because the start
and stop chars are in-band for UUCP's 'g' protocol. Without handshaking
dropped characters are inevitable. Massive lossage either way.
Sooo...I hauled the 3B1 down from the third floor and moved *everything*
back onto it. You remember this 3B1, it's where I was developing six months ago
when it became subject to fits of unsanity and random kernel panics. But
at least it handshakes to the 'Blazer; the only compromise I had to make was
strapping DCD high (S53=0).
So the two machines are now sitting side-by side; I'm developing on the 3B1
with frequent backups via UUCP to the T5100. Damn. I hope AT&T comes through
with my 6386 WGS *soon*...my contact there says next week but I've heard *that*
song before.
It didn't help, either, that I can't use kermit anymore and thus had to switch
to a new Internet connecton (linc.cis.upenn has no uucp dialins) and that said
new internet connection is proving irritatingly difficult to get configured
properly.
Between all this sturm und drang on the hardware and comm front, having to
field minor MRs, and the demands of organic life (eating, sleeping, that sort
of thing) I've had precious little time to move forward on TMNN. And I've
doubtless got *another* siege coming up when the new hardware comes in. But
for now things have quieted down enough for me at least to catch up on
*reading* news :-) and repair some documentation glitches in 7.4.
Meanwhile, I'm waiting on one last set of fixes from Ted Ts'o at MIT. He's been
fine-toothing the code with a copy of the C interpreter Sabre, which helps
catch pointer-corruption bugs and the other kinds of subtle run-time michigoss
for which C is so justly famed.
As soon as these patches come in and I can integrate them, I will release
TMNN7.5 to the whole beta list. Promise!
Eric S. Raymond (the mad mastermind of TMN-Netnews)
UUCP: {uunet!vu-vlsi!cbmvax}!snark!eric INTERNET: eric@snark.uu.net
Post: 22 S. Warren Avenue, Malvern PA 19355 Phone: (215)-296-5718henry@utzoo.uucp (Henry Spencer) (04/30/89)
In article <1RH0R8#4BF6fX=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) writes: >Result? The 'blazer has to have S58=0 (no handshake) or S58=3 (XON/XOFF) set >for the T5100 to even *open* it -- and XON/XOFF isn't usable because the start >and stop chars are in-band for UUCP's 'g' protocol. Without handshaking >dropped characters are inevitable. Massive lossage either way. Aha, a chance to catch Eric in an error! :-) The uucp-spoofing mode in the Trailblazer, when it kicks in, shuts XON/XOFF off, so there is no conflict. With a packet protocol running between host and modem, you don't need any low-level handshaking if your host interface is halfway well built. -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
sl@unifax.UUCP (Stuart Lynne) (05/02/89)
In article <1989Apr29.224526.22914@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <1RH0R8#4BF6fX=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) writes: >>Result? The 'blazer has to have S58=0 (no handshake) or S58=3 (XON/XOFF) set >>for the T5100 to even *open* it -- and XON/XOFF isn't usable because the start >>and stop chars are in-band for UUCP's 'g' protocol. Without handshaking >>dropped characters are inevitable. Massive lossage either way. > >Aha, a chance to catch Eric in an error! :-) The uucp-spoofing mode in the >Trailblazer, when it kicks in, shuts XON/XOFF off, so there is no conflict. >With a packet protocol running between host and modem, you don't need any >low-level handshaking if your host interface is halfway well built. There are two types of character losses. First from not being able to service the received character interrupts fast enough, and second running out of room for the data in the driver buffers (clists). If the driver runs out of room it will flush the data. Prior to actually running out of room it will attempt to flow control. With uucp protocol "g", with a window size of 3 you will not overrun the CLISTS (at least not in standard system v). So the only problem is whether you can actually service interrupts fast enough to actually receive the data. This can be partially helped by designing the interrupt levels so that serial drivers have the highest priority. In fact higher than the kernel is protected from (effectively making allmost all of the kernel interruptable). Then have the serial drivers only send and receive data from it's own data areas (not from the systems clists). Fill or empty the drivers data areas from a clock interrupt service routine. If you then allow that routine to do (for example) hardware handshaking you can handle fairly high data transfers without huge buffers. If the device you are talking to doesn't handle RTS/CTS type flow control you have to provide enough data space to handle the worst case. On Xenix for example at 19.2 you have to buffer about 60 chars to be safe (the clock poll should empty the data every 2 milli seconds, you can receive something like 20 char's per millisecond at 19.2). The bottom line is that if you have a decent serial driver you can run the TB's without *any* flow control because the windowsize of three prevents the standard drivers from overflowing the clists and flushing them. And if you *really* do need flow control it can be done by using hardware (RTS/CTS) full duplex flow control. Anyone who has a Trailblazer hooked up to an SCO 286 system can demonstrate this fact to you. -- Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)