Date: Tue, 19 Nov 1996 10:36:28 -0500 From: dennis@etinc.com (dennis) To: Tony Li <tli@jnx.com> Cc: isp@freebsd.org Subject: Re: changed to: Frac T3? Message-ID: <199611191536.KAA07083@etinc.com>
next in thread | raw e-mail | index | archive | help
>
> >Here is a point though where Dennis will philosophically disagree with me,
> >and that is all right. Dennis makes a big point out of the fact that a
> >UNIX router can perform other services too... I do NOT believe in that
> >paradigm. So for me, specializing a UNIX kernel for a router would not
> >be a bad concept, but Dennis probably would not agree.
>
> I dont disagree (in fact we may have to do it to route T3), but it will be
> a specialized functions, not for everyone.
>
>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
:-)
> 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.
Dennis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611191536.KAA07083>