alex@wolf.umbc.edu (Alex Crain) (04/10/89)
CALL FOR DISCUSSION Topic: Serial line networking of unix-pc's. As my efforts to produce a working socket driver for the unix-pc are generating positive results (it works), The looming question of how to interconnect machines is becomming more pertenant. like many people, I bought a large machine and later a small machine as a future parts doner, and getting the two of them to talk would be right nice. I'm running a uucp network now, but I'd really like some kind of packet base protocol. With the TCP driver taking shape, the idea is becomming more attractive. For myself, I would like to run a bus network around my house, consisting of a single serial line. I will probably purchase a mac as a game machine/graphics engine/word processor for my wife in the next year or so, and I would like to pick up a nice printer, an maybe a trailblazer. Also, I never want to buy a peripheral from apple! (nobody has that much money) So I'm figureing my network to be: HARDWARE 1) a bi-directional bus network, or some kind of fault-tolerant ring that can tell when a host goes down. No star networks. I only want to have to deal with one port per machine, and I want to be able to splice in devices. 2) RS232 or simular hardware speeds and voltage levels. ($$$) 3) hardware support for packet acceptance/rejection, and queueing of data so that the machines don't die. SOFTWARE 1) support for virtual circuits and datagrams, with out-of-band facilities. 2) reasonable efficency with in packet overhead. 3) gateway/forwarding capability, for dealing with modems and printers. This means machine addresses and ports. 4) virtual files, as in some kind of restricted NFS. I think that some kind of minimal hardware support is going to be required for speed, but I'd like to make that an option, so that poor folks can use the existing RS232. I envision a card that watches the net and screens packets against their address. I would also like at least 16 bytes of buffer space with a timeout, to limit interrupts. I'd also like to use an existing protocol, custom protocols are a drag unless they catch on, even free ones. The two protocols that come to mind are SLIP and Appletalk. SLIP would be in keeping with tradition, but I'm worried about the overhead. I don't know anything about Appletalk, but the fact that its built around a serial line suggests that its optimized for speed. The fact that I'm looking at a mac also makes Appletalk more desireable :-). Also, Appletalk hardware is pretty close to what I'm looking for, although I don't know much about it. Appletalk also supports some kind of disk sharing that works over a serial line. I will probably add the code for SLIP anyway, since much of the code is free and available. I'm looking into a protocol developed at CMU thats built around Appletalk, and if the code is free, I'll look into adding that to, if only for my future mac. So what does everybody think? I want to write something thats going to be *used*, although I won't be charging for it. What are your needs? I don't know diddly about hardware, so I would like to here from the hardware guys regarding the interface. Optimally we would see the same deal as the hard disk upgrade, namely a "lenny and gil do it yourself" model and a "custom PAL on a special board for $$" version. :alex Alex Crain Systems Programmer alex@umbc3.umbc.edu Univ Md Baltimore County umbc3.umbc.edu!nerwin!alex
les@chinet.chi.il.us (Leslie Mikesell) (04/11/89)
In article <1892@umbc3.UMBC.EDU> alex@wolf.umbc.edu.UUCP (Alex Crain) writes: > > 1) a bi-directional bus network, or some kind of fault-tolerant ring > that can tell when a host goes down. No star networks. I only want to > have to deal with one port per machine, and I want to be able to splice > in devices. I don't know if you can still get the 1Mbit starlan boards for the 7300 or not, but they would work nicely. You can daisy-chain up to 10 units without using a hub. The main problem with them is that the available software is for URP (AT&T proprietary) protocol while the other AT&T machines are changing to OSI protocols so you can't mix 7300's and 6386's on the same net. Also, since you can't get SysVr3 you can't run RFS, but if you want to roll your own software it might work out. Les Mikesell
rkh@mtune.ATT.COM (Robert Halloran) (04/11/89)
In article <8187@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1892@umbc3.UMBC.EDU> alex@wolf.umbc.edu.UUCP (Alex Crain) writes: >> [deleted] > >I don't know if you can still get the 1Mbit starlan boards for the 7300 >or not, but they would work nicely. You can daisy-chain up to 10 >units without using a hub. The main problem with them is that the >available software is for URP (AT&T proprietary) protocol while the >other AT&T machines are changing to OSI protocols so you can't mix >7300's and 6386's on the same net. Also, since you can't get SysVr3 >you can't run RFS, but if you want to roll your own software it might >work out. You should still be able to get starlan boards for the 7300. Correction to your comments above: it is true that the other AT&T systems are moving to ISO protocols, but they CAN share a wire with URP-based systems; they just don't understand one another. Bob Halloran ========================================================================= UUCP: att!mtune!rkh Internet: rkh@mtune.ATT.COM USPS: 17 Lakeland Dr, Port Monmouth NJ 07758 DDD: 201-495-6621 eve ET Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed. Quote: "Well, if it wasn't Buckaroo Banzai, I'd say 'commit the man.'" - where else?
jcm@mtunb.ATT.COM (was-John McMillan) (04/11/89)
In article <7976@mtune.ATT.COM> rkh@mtune.UUCP (Robert Halloran) writes: >In article <8187@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: ... >> The main problem with them is that the >>available software is for URP (AT&T proprietary) protocol while the >>other AT&T machines are changing to OSI protocols so you can't mix >>7300's and 6386's on the same net. ... >Correction to your comments above: it is true that the other AT&T systems >are moving to ISO protocols, but they CAN share a wire with URP-based >systems; they just don't understand one another. > > Bob Halloran 1) Bob is right, as usual ;-) 2) Bob hasn't mentioned that AT&T, INTERNALLY, runs many [most?] of its 3B2 and 6386 systems with software that supports BOTH URP & ISO. (He KNOWS this... but is smart enough to NOT mention it: I'm NOT ;-) The point is: there is inside & outside pressure for AT&T to release the dual protocol software as a product -- at least I think that's still alive -- and there is as yet little isolation of 3B1's WITHIN AT&T. There is just the tedium of knowing which of your clients are URP or ISO talkers. 3) True isolation occurs as StarLAN'ers switch from the 1MB hardware to the 10MB hardware: there is no (known-to-me) means of running the 1MB hardware on a 10 MB net. John (oops, I shouldn't a said that) McMillan -- att!mtunb!jcm
sheldon@quest.UUCP (Scott S. Bertilson) (04/12/89)
I've begun playing with the KA9Q TCP/IP/SLIP package. I'm testing it by plugging it into a SUN running SLIP. It seems that the UNIXpc really can't handle this very well. It connects nicely using a number of applications, but any large transfers seem to kill it (like incoming FTP). I'm wondering if anyone is doing this sort of thing at reasonable transfer rates (>= 4800 baud) with a significant degree of success. If so, what parameters do you use when you set up the serial line in the attach? -- Scott S. Bertilson ...uunet!rosevax!rose3!quest!sheldon scott@poincare.geom.umn.edu
sheldon@quest.UUCP (Scott S. Bertilson) (04/13/89)
I made one change which has yielded a significant improvement to the
(crusty?) copy (version.c says 871225.3) I've been playing with.
Here's a patch:
*** orig/slip.c Mon Jan 11 23:54:26 1988
--- slip.c Wed Apr 12 22:20:13 1989
***************
*** 234,240
doslip(interface)
struct interface *interface;
{
! char c;
struct mbuf *bp;
int16 dev;
int16 asy_recv();
--- 234,242 -----
doslip(interface)
struct interface *interface;
{
! char buf[256];
! register char *cp;
! register int cnt;
struct mbuf *bp;
int16 dev;
int16 asy_recv();
***************
*** 241,249
dev = interface->dev;
/* Process any pending input */
! while(asy_recv(dev,&c,1) != 0)
! if((bp = slip_decode(dev,c)) != NULLBUF)
! (*slip[dev].recv)(interface,bp);
/* Kick the transmitter if it's idle */
if(stxrdy(dev))
--- 243,253 -----
dev = interface->dev;
/* Process any pending input */
! while((cnt = asy_recv(dev,cp = &buf[0],sizeof(buf))) != 0) {
! while (cnt-- > 0)
! if((bp = slip_decode(dev,*cp++)) != NULLBUF)
! (*slip[dev].recv)(interface,bp);
! }
/* Kick the transmitter if it's idle */
if(stxrdy(dev))
--
Scott S. Bertilson ...uunet!rosevax!rose3!quest!sheldon
scott@poincare.geom.umn.edules@chinet.chi.il.us (Leslie Mikesell) (04/13/89)
In article <1466@mtunb.ATT.COM> jcm@mtunb.ATT.COM (was-John McMillan) writes: >>Correction to your comments above: it is true that the other AT&T systems >>are moving to ISO protocols, but they CAN share a wire with URP-based >>systems; they just don't understand one another. >1) Bob is right, as usual ;-) I did know that, and in fact have both types on the same wire now, but what's the point - when we upgrade the 3B2's to the new software the 3B1's won't be able to talk to anything but themselves. >2) Bob hasn't mentioned that AT&T, INTERNALLY, runs many > [most?] of its 3B2 and 6386 systems with software that > supports BOTH URP & ISO. (He KNOWS this... but is > smart enough to NOT mention it: I'm NOT ;-) > The point is: there is inside & outside pressure for AT&T > to release the dual protocol software as a product -- at > least I think that's still alive -- and there is as yet > little isolation of 3B1's WITHIN AT&T. There is just the > tedium of knowing which of your clients are URP or ISO > talkers. Great - I suppose they will wait until just after we dump the 3B1's to release it. And then they'll wonder why we don't buy a copy... There is a product listed as an ISO to URP translator but the description only mentions using it to talk to a slim-C card. Is it in fact a general-purpose translator suitable for (say) allowing DOS ISO clients to talk to the 3B1 (URP) DOS SERVER? Anyway, the correct solution is to provide a matching ISO version for the 3B1. Otherwise AT&T is giving the impression that they cannot be expected to provide continuing support for the products they sell, or perhaps that they are incapable of porting current unix and networking software to more than a few platforms. >3) True isolation occurs as StarLAN'ers switch from the 1MB > hardware to the 10MB hardware: there is no (known-to-me) > means of running the 1MB hardware on a 10 MB net. I assume you mean 1MB URP only. There is a 10-1 bridge for the ISO versions. Les Mikesell
mvadh@cbnews.ATT.COM (andrew.d.hay) (04/13/89)
In article <1466@mtunb.ATT.COM> jcm@mtunb.ATT.COM (was-John McMillan) writes:
"3) True isolation occurs as StarLAN'ers switch from the 1MB
" hardware to the 10MB hardware: there is no (known-to-me)
" means of running the 1MB hardware on a 10 MB net.
"
there is a very expensive (~$3-4K) 1-to-10 bridge...
there is also a starlan-10 cable tap for ethernet controllers.
( anyone know where we can pick up a dozen 3b1 ethernet cards? ;^>)
--
Andrew Hay +------------------------------------------------------+
Null Fu-Tze | LEARN HOW TO AVOID RIPOFFS! |
AT&T-BL Ward Hill MA | SEND $5... |
mvuxq.att.com!adh +------------------------------------------------------+mark@umbc3.UMBC.EDU (Mark Sienkiewicz) (04/14/89)
Some observations on hardware for Alex's network stuff. I know a diddly about harware (I could probably get away with 2 or 3 diddlys if I had to). --- 1. The built in RS232 loses. If you yell at it at 9600 baud, the machine spends all of it's time doing interrupt handling and none running your program. I'm sure a lot of this is because of the line discipline, but doing special drivers probably won't help as much as you hope it will. Implementing a driver on this hardware is probably necessary for people who don't want to hack on their machine. It is also a fantastic way to get things up and running for REAL CHEAP. It just won't be very fast. To quote /usr/include/sys/termio.h: #define B38400 0000017 /* added to pass SVVS. we dont support 38K baud */ --- 2. If you still want to go with RS232, you should look in to a National Semiconductor chip called NS16550. It is upward compatible from the 16450 which is upward compatible from the 8250b which you've seen in IBM PC clones everywhere. The neat thing about this device is it is a complete UART with a built in 16 byte FIFO. You can select how full the FIFO gets before you get an interrupt. This means you can reduce the number of interrupts to 1/14th. You could either have a much less busy machine, or run 14 times as fast. This also has the advantage of being able to talk to machines that use the built in serial port I know other devices like this have got to exist, but I've never seen any. --- 3. You could use a real dumb UART in combination with a FIFO to go one better on the 16550. It would be a major hassle to implement all the functions of a UART, but we only need SEND DATA, RECV DATA, and NETWORK FAILURE. If you read some of the EE type magazines, you will see dozens of ads saying how wonderful Brand X fifo chips are. --- 4. My favorite idea would be to have a bi-directional parallel interface that talks the the machine on the next table. Then one of them would gateway things onto a serial bus network. I think with the right hardware, you could push it to around 100k bps without too many problems. I'd like to run the parallel interface all through the house, but I can't afford that much shielded cable. ----- Of course, in the ideal world, you would like to build this thing in layers. If you build the software-hardware interface right, you could have a driver for any of the above types of hardware. If you get real fancy, you could even do the gateway style stuff in the drivers. Since we have a less than ideal world, you can also suppose that an rs232 interface that uses less overhead could be built without using the expansion bus. It works like this: Find a decoded but unused address on the motherboard. 0xe20000 comes to mind. Divide it up into 8 of 64k chunks with 74138 or something. Find a nearby place with some data and address lines (the floppy controller and dma controller, I think). Run all this to a pair of 14 or 16 pin DIP sockets. Then you have a cheap 8 bit I/O bus. (If you do this, write the software so it is easy to change the memory addresses used -- my hardware might not quite match yours...) --- At work, they have a network called TOPS running on the Mac's. It looks like it uses RS232 or Appletalk. (I also see people selling it: e.g. Mt. Xinu for BSD 4.3) It also runs on Mac's and PC's. I suspect this makes it unlikely that you can do much with it for free. I do notice that it looks like a bus with a little box at each station except at the end. The box is about 4x2x1 inches. I bet it doesn't have much in it. Anybody know? ===== About protocols: There are a few things to give serious consideration to when you choose protocols: 1 - It should be source code compatible with the BSD TCP stuff. Specifically, AF_INET should exist and work as advertised. This gets you an portable interface. I don't have to learn AF_RANDOM styles of thinking or anything like that. 2 - There should be a protocol that is easy enough to implement that it could be ported to other machines. "other machines" includes things like Mac's, PC clones, and even CPM or dumber. This is almost guarenteed to be both stupid and proprietary. 3 - At least one protocol that goes off machine to other UnixPc's should be implemented soon enough that it doesn't look like vapor-ware. 4 - proprietary (or non-standard) protocols suck only if they don't catch on. Free source code catches on quite nicely. 5 - because nobody can ever agree on protocols, it should be possible to run more than 1 protocol on the same hardware. If anybody out there has any pet protocols, lets hear from you. Mark S. uunet!umbc3!nerwin!zilla!mark nerwin!zilla!mark@umbc3.umbc.edu <- one of these is nerwin!zilla!mark@umbc3.umd.edu <- supposed to be right. Miskatonic University Ex ignoratia ad sapientiam. Ex luce ad tenebras.
gil@limbic.UUCP (Gil Kloepfer Jr.) (04/15/89)
In article <1909@umbc3.UMBC.EDU> mark@umbc3.umbc.edu.UMBC.EDU (Mark Sienkiewicz) writes: >4. My favorite idea would be to have a bi-directional parallel interface >that talks the the machine on the next table. Then one of them would >gateway things onto a serial bus network. I think with the right >hardware, you could push it to around 100k bps without too many problems. I'm currently working on this idea. Mike Thompson is working on a SCSI port, which essentially is the same thing (but better). Some observations on the overall tone of the quoted article: First, it is unwise to make a bidirectional parallel interface that is entirely interrupt-driven. I already tried this and it *does* swamp the CPU with interrupts. You'll end up with spirious interrupts because there will be an interrupt coming-in as you're in the process of returning from the interrupt service routine. This isn't good. Second, using a buffered UART to perform I/O is not worth the effort if all you're doing is adding a 16 byte buffer. To gain more throughput and keep the CPU from being overwhelmed, a packet-based protocol should be used with the packets transferred to/from off-board RAM (say, 2K or so) using the 256K address space allocated to an expansion slot (see next paragraph). Off-board, some kind of intelligent controller should be used to transfer the data packet in this RAM off through the UART (or parallel interface chip, such as the 8251). This takes the load off the 3B1's CPU and provides greater (and more reliable) throughput. You could use DMA to the 3B1, but this could hold the bus for an unreasonable period of time. Third, it is not my recommendation to wire anything to the bus through chips on the motherboard -- stick to expansion slots. Like you, I didn't have the right connector so I wired straight to the slot connector. There are signals coming out of the expansion slot, as well as the proper addressing schemes, which should be adhered to so that all peripherals may peacefully coexist. If this doesn't sound good enough for you, let it be known that I/O timing and other CPU timing is different on the 3B1. Unless you have circuitry that can operate at the full processor speed even with the kludgy wiring off a chip, you will experience definite problems with prop. delay. My true feeling is to wait a few months for Mike and the crew to come up with a public-domain SCSI port. Since schematics and software will be all available, you can make with this what you want. If all you want is a serial network, then you'll probably get the best throughput with the on-board serial port and a special driver. I have a feeling though that this SCSI idea will be real good for something, even if the software isn't quite right. ----- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | {decuac,boulder,talcott,sbcs}!icus!limbic!gil or gil@icus.islp.ny.us
david@ms.uky.edu (David Herron -- One of the vertebrae) (05/04/89)
It's been awhile since this discussion was going on so my apologies ..
First off, I'm *VERY* interested in having TCP/IP on both my machines.
For the 3b1 I'll have to go with something "PD" ... which is fine ...
And I wanna help out with developing it too!
BUT I can't afford to tie up the parallel ports on either the 3b1 or
the Amiga. I've got serial ports to spare .. but as people have
pointed out they give lots of interrupts and generally kill the machine.
The SCSI scheme would be nice. I have a vague memory, hgowever, that
the SCSInet stuff required some extensions to SCSI. Anybody know better?
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- By all accounts, Cyprus (or was it Crete?) was covered with trees at one time
<- -- Until they discovered Bronzealex@wolf.umbc.edu (Alex Crain) (05/04/89)
In article <11635@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: > BUT I can't afford to tie up the parallel ports on either the 3b1 or > the Amiga. I've got serial ports to spare .. but as people have > pointed out they give lots of interrupts and generally kill the machine. I've been looking into the serial line driver, and I think that I can do something with the speed. Right now, the sequence for servicing the UART goes something like: Receive interrupt Vector processor off the interrupt stack Save all 16 registers figure out what caused the interrupt (which channel) Jump to that handeler procedure Save the registers that were going to use. read the uart and stick the byte in a clist wake up the clist handler restore some registers so some cleanup restore all 16 registers and fixup the stack pointer return from interrupt I figure that by dedicating the tty port to a packet based protocol, that sequence could be reduced to a state machine that either: 1) starts a new packet, initializes the recieve buffer, etc. 2) moves a byte from the UART to ther receive buffer. 3) terminates the packet, wakes up the buffer handler. with a fixed buffer size, we would spend most of our time doing #2, which would look basically like this: get interrupt vector to our routine save %d0, %d1 and the stack pointer if this is not from the serial port, branch to the default handler. read the uart into %d0 read our global buffer pointer to %d1 write %d0 to (%d1)+ write %d1 back out restore %d0, %d1 and %sp return from interrupt. This ought to be fast enough to run at 9600 baud without slowing the machine down much, offhand I'd guess that it can be made to work in about 50000 machine cycles per second, running full out, not bad for a 10Mhz machine (of course, that doesn't count transmit) I'm thinking that some careful buffer management could make a ring network practical, since the machine should be capable of packet pass-thru without sacraficing speed. ie: the buffer manager would check the addresses of packets and send them back out if neccessary. Alternately, the interrupt handeller could chaeck addresses on the X'th byte, and if necessary notify the transmit side to start feeding them back to the UART. Or, we could freeze the receiveing side while we feed the packet header into the UART, and then add a state which reads one side of the uart and writes to the other side until the end of the packet. Or..... In any case, I think that the serial port is useable, and its to cheap to ignore. BTW: I've got the system call interface and the AF_UNIX domain code about finished, and I'll be tossing it out for beta testing *real*soon*now*, so watch this space. :alex Alex Crain Systems Programmer alex@umbc3.umbc.edu Univ Md Baltimore County umbc3.umbc.edu!nerwin!alex