Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Talking to cisco routers with Unix machines
Summary: just a nit
Message-ID: <67243@sgi.sgi.com>
Date: 19 Aug 90 20:39:01 GMT
References: <1990Aug18.225126.3678@santra.uucp> <12614941747.9.BILLW@mathom.cisco.com>
Sender: vjs@rhyolite.wpd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 26

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