Date: Tue, 19 Nov 1996 14:32:19 -0800 (PST) From: Tony Li <tli@jnx.com> To: dennis@etinc.com Cc: isp@freebsd.org Subject: Re: changed to: Frac T3? Message-ID: <199611192232.OAA16231@chimp.jnx.com> In-Reply-To: <199611191536.KAA07083@etinc.com> (dennis@etinc.com)
next in thread | previous in thread | raw e-mail | index | archive | help
>In fact, there is a _great_ deal of painful experience in dealing with >routers where there isn't quite enough CPU time to get everything done. >Routing protocols are basically soft real-time distributed systems. When >they get delayed, they tend to collapse in spectacular ways. As a result, >putting any significant non-routing load on a router is a _really_ bad >idea. that's 'cause you've been working with machines that have stinky little CPUs :-) Like 150Mhz MIPS boxes. ;-) You're right. Of course, I also consider a PP200 to be a "stinky little CPU", so we still haven't gotten rid of the problem. > You MIGHT be able to get away with it by suitable modifications to ^^^^^^ >>the Unix scheduler, but then it wouldn't be Unix, would it? ;-) And the >>cost of another box to support a server is sufficiently low that it would >>seem to make sense not to risk the routing... The point of this discussion, I believe, was to try to determine what "it" is. As machines get faster, it keeps changing. Certainly there is a limit, but its not totally clear what it is. As I think I pointed out in another message, "it" is a guarantee of cycles and I/O to the routing protocols. Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611192232.OAA16231>