jkp@cs.HUT.FI (Jyrki Kuoppala) (08/19/90)
In article <9008142108.AA03724@jade.berkeley.edu> of mail.sun-nets, 42-5360)CLIFF%edu (CLIFF <(Cliff Frost {415})) writes: >Has anyone had any experience using SLIP and/or PPP from a Sun >(a 3/50 or SPARCstation) at 56 or 64Kbits/sec? I'm interested >in using one of the serial ports to do this. To extend, has anyone written software to talk to Cisco routers at 64 kbits/sec ? I understand that Cisco's support SLIP, but can that be run at 64 kbit/s ? I suppose the protocol Cisco routers use to talk to each other is not any standard protocol but Cisco's own. Are the protocol specs available ? If not, would Cisco object to someone reverse-engineering the protocol ? A local PTT here offers a service to connect company LANs together with Cisco routers; if a general-purpose Unix machine could talk the Cisco protocol and route the traffic (perhaps also DECNET traffic) one could save the money needed to buy the Cisco router. Well, perhaps I shouldn't have said that because I suppose it's not in the best interests of Cisco ;-) //Jyrki
henry@zoo.toronto.edu (Henry Spencer) (08/19/90)
In article <1990Aug18.225126.3678@santra.uucp> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: >To extend, has anyone written software to talk to Cisco routers at 64 >kbits/sec ? I understand that Cisco's support SLIP, but can that be >run at 64 kbit/s ? There is no reason why you couldn't run SLIP at FDDI bit rates, should you really want to. :-) I'd guess that 64kbaud is synchronous rather than async, in which case SLIP's applicability is a bit more dubious, but the idea is not impossible even so. >I suppose the protocol Cisco routers use to talk to each other is not >any standard protocol but Cisco's own... In the long run they will probably use PPP, I would think. What they use *now* is a different question; it may well be proprietary. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (08/19/90)
>Has anyone had any experience using SLIP and/or PPP from a Sun >(a 3/50 or SPARCstation) at 56 or 64Kbits/sec? I'm interested >in using one of the serial ports to do this. You really do NOT want to do this. The zippy CPU in a sparcstation is much better off doing user stuff, rather than trying to service 13000 interupts/second. Servicing interrupts is not something that most risc processors are good at. I've heard people complain about the impact of much slower SLIP connections. You would be better off getting a sync serial interface, which only interrupts the CPU per frame, or a stand alone router box. To extend, has anyone written software to talk to Cisco routers at 64 kbits/sec ? I understand that Cisco's support SLIP, but can that be run at 64 kbit/s ? The maximum speed of an async SLIP line on a cisco terminal server is 38400 bps. Faster than that we like to do frame-at-a-time sync serial too (and you use a router instead of a terminal server.) I suppose the protocol Cisco routers use to talk to each other is not any standard protocol but Cisco's own. Are the protocol specs available ? If not, would Cisco object to someone reverse-engineering the protocol ? We have told people the spec. I don't know whether anyone has actually done anything with it. The current software also supports the IETF Point-to-Point protocol for IP on sync serial lines, which is probably a better idea. A local PTT here offers a service to connect company LANs together with Cisco routers; if a general-purpose Unix machine could talk the Cisco protocol and route the traffic (perhaps also DECNET traffic) one could save the money needed to buy the Cisco router. Well, perhaps I shouldn't have said that because I suppose it's not in the best interests of Cisco ;-) This sort of thing is exactly what the PPP spec is supposed to solve. This is tcp-ip, you don't have to be nice to cisco. Actually, you don't have to be nice to us on the cisco mailing list either :-) Bill Westfield cisco Systems. -------
torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen) (08/19/90)
>In article <9008142108.AA03724@jade.berkeley.edu> of mail.sun-nets, 42-5360)CLIFF%edu (CLIFF <(Cliff Frost {415})) writes: > >>Has anyone had any experience using SLIP and/or PPP from a Sun >>(a 3/50 or SPARCstation) at 56 or 64Kbits/sec? I'm interested >>in using one of the serial ports to do this. Yes, we do have such a beast. We initially developed it on a Sun-3/50 and later migrated to SS-1's. Several early (and quite buggy!) versions got out to a variety of people. We recently redid the whole thing and that hasn't been released yet. One of the main reasons it hasn't gone out yet is that we depend on Sun's lower layer; i.e., we have been using the synchronous zs driver they supply with their Sunlink products. Yes, we have our own, but I'm not enthusiastic about maintaining that one. Much easier to use a tiny piece of Sunlink. Except for the license problems.... Torben
torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen) (08/19/90)
> >Has anyone had any experience using SLIP and/or PPP from a Sun > >(a 3/50 or SPARCstation) at 56 or 64Kbits/sec? I'm interested > >in using one of the serial ports to do this. > >You really do NOT want to do this. The zippy CPU in a sparcstation >is much better off doing user stuff, rather than trying to service >13000 interupts/second. Servicing interrupts is not something that >most risc processors are good at. I've heard people complain about >the impact of much slower SLIP connections. I disagree. We did this on a Sun-3/50 and sure, you could feel it. On an SS-1, the impact isn't what I'd call major. We use the on-board serial ports at 56Kbps in a couple of cases and we don't see a really noticeable impact from it. We've actually gone a good bit higher than this on an SS-1 :-) It all depends on what you're after. If you happen to have an SS-1 handy and you're willing to give up a little chunk of the CPU, go for it. Under normal circumstances, you won't notice it. My feeling is that the load is about the same as you get if you add a reasonably active process to your SS-1. >You would be better off getting a sync serial interface, which only >interrupts the CPU per frame, or a stand alone router box. We're actually playing with this. We have hardware that allows us to run serial lines out of an SS-1 at a full 2.048Mbps. Neat. And the SS-1 is fast. Hopefully, we'll manage to get a hold of a Cisco pretty soon so we can test interoperability. Torben
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/20/90)
In article <12614941747.9.BILLW@mathom.cisco.com>, BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: > > You really do NOT want to do this. The zippy CPU in a sparcstation > is much better off doing user stuff, rather than trying to service > 13000 interupts/second. Servicing interrupts is not something that > most risc processors are good at.... Well, just to pick nits ... One of some RISC CPUs' claims to fame is low interrupts latency. I have intimate knowledge of a 16MHz RISC on a VME FDDI board that that takes an interrupt/frame, for all frames including BEACON and CLAIM. That's about one frame every 3 microseconds. The interrupt handler is limited to about 1.5 usec/interrupt, to ensure that there are cycles left over for talking to the host and other things, while handling the 300,000 interrupts/second. I remember the sales pitch for another RISC CPU about 4 years ago, where they claimed you could start the work of an interrupt routine in 1 cycle. It turned out to be true, although only for interrupt handlers like TLB- miss handlers that need few registers. Vernon Schryver vjs@sgi.com