Date: Tue, 19 Nov 1996 16:19:18 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: tli@jnx.com (Tony Li) Cc: jgreco@brasil.moneng.mei.com, dennis@etinc.com, isp@FreeBSD.org Subject: Re: changed to: Frac T3? Message-ID: <199611192219.QAA06024@brasil.moneng.mei.com> In-Reply-To: <199611190420.UAA14723@chimp.jnx.com> from "Tony Li" at Nov 18, 96 08:20:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. > > Yes, exactly. The problem is that routing protocols (e.g., routed) run as > processes and exhibit this behavior: > > 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. > > This is enough to trash most protocols. Note that ongoing competition from > other process can also be a problem. > > 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. > > Simple to demonstrate. Take a compute bound process which generates and > receives packets periodically. This emulates your routing protocol. Start > a kernel build. You'll notice a non-trivial performance hit in interactive > response and computation by your routing protocol. Now renice your kernel > build. Things get better, but that process still consumes bus cycles, > physical memory, and gets some share of the CPU. Add more load until > processes start paging. You'll note that the progress of your 'routing > protocol' degrades further. Pretty soon, your timers start to slip. > You're now on the brink of collapse. > > The result is simple: routing protocols need a guaranteed minimal amount of > CPU and I/O to survive. Lacking strict resource controls under Unix, the > best way of delivering that guarantee is to exclude other load from the > box. For a seriously robust router, you'd also need to put a cap on the > amount of time spent in interrupt processing. I can see this as a problem for routing protocols, should one choose to run gated/etc on such a box, yes. I suspect that scheduling such a process with real time priority may have some benefits, and scheduling other servers with idle time priority may be a further win. Clearly, neither would be adequate for the case where the machine is being saturated with packets, but from a "piggy process" point of view, this might be sufficient. ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611192219.QAA06024>