From owner-freebsd-isp  Tue Nov 19 07:29:59 1996
Return-Path: owner-isp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id HAA12201
          for isp-outgoing; Tue, 19 Nov 1996 07:29:59 -0800 (PST)
Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA12187
          for <isp@freebsd.org>; Tue, 19 Nov 1996 07:29:48 -0800 (PST)
Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id KAA07083; Tue, 19 Nov 1996 10:36:28 -0500
Date: Tue, 19 Nov 1996 10:36:28 -0500
Message-Id: <199611191536.KAA07083@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Tony Li <tli@jnx.com>
From: dennis@etinc.com (dennis)
Subject: Re: changed to: Frac T3?
Cc: isp@freebsd.org
Sender: owner-isp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>
>   >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