Date: Mon, 18 Nov 1996 21:57:49 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: tli@jnx.com (Tony Li) Cc: dennis@etinc.com, isp@FreeBSD.ORG Subject: Re: changed to: Frac T3? Message-ID: <199611190357.VAA03823@brasil.moneng.mei.com> In-Reply-To: <199611190252.SAA14559@chimp.jnx.com> from "Tony Li" at Nov 18, 96 06:52:57 pm
next in thread | previous 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. 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. User processes should have no way to compete for time spent basically dealing with an interrupt. Real time operating systems deal with this by simply flagging that an interrupt occurred and continuing with the user process until time is available to deal with the interrupt (what an oversimplification, but oh well). Traditional UNIX, from my understanding, does not have this behaviour and observation tends to support this. I have actually seen the syscons cursor's blink slow and then stop on a massively overloaded 386DX/40 router, which suggests to me that the system is extremely busy processing other things. At the time that I witnessed this, I had a "vmstat 1" running. As "sy" reached its peak value of 100, the system's interactive response became virtually dead and as the number of packets routed per second continued to grow, the vmstat "froze". I couldn't coax any response from any daemons on the system, although I was allowed to connect. When the pps being routed dropped, suddenly the system "sprang" to life again. It is quite clear to me that it is possible not to have enough CPU to perform packet routing/forwarding functions, then, based on firsthand observation. However, less clear to me is that your argument against having any "significant non-routing load" on a router applies to UNIX based routers. Maybe someone like David or Bruce could clarify this. Please do not think that I disagree with what you are saying: I agree most wholeheartedly! Routers route. Servers serve. ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611190357.VAA03823>