From owner-freebsd-isp Tue Nov 19 07:15:56 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA11434 for isp-outgoing; Tue, 19 Nov 1996 07:15:56 -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 HAA11423 for ; Tue, 19 Nov 1996 07:15:51 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id KAA06980; Tue, 19 Nov 1996 10:21:09 -0500 Date: Tue, 19 Nov 1996 10:21:09 -0500 Message-Id: <199611191521.KAA06980@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: Joe Greco 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. 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... > >I guess I never bothered to explore this topic... > >I always thought packet routing was handled as a fairly high priority >thing. Packet arrives, generates interrupt, kernel processes, queues >for output, and sends it. It kind of does work that way, except that you cant assume that every process will get its piece of the CPU in time, because there are multiple processes sharing it. As speed increases, the possibility of an overrun increases...and that is the issue. The "efficiency" of BSD is much lower than that of a router because of the way processes share CPU time, however a PP200 has 10 or more times the processing power of most dedicated routers, so it doesnt have to be as efficient. Dennis