Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!news.cis.okstate.edu!newsfeed.ksu.ksu.edu!news.physics.uiowa.edu!math.ohio-state.edu!howland.reston.ans.net!EU.net!Austria.EU.net!siemens.at!not-for-mail
From: mingo@pc5829.hil.siemens.co.at (Ingo Molnar)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: FreeBSD as a router
Date: 15 May 1996 09:08:57 GMT
Organization: Siemens AG Austria
Lines: 79
Message-ID: <4nc6v9$jib@news.siemens.at>
References: <4lfm8j$kn3@nuscc.nus.sg> <317CAABE.7DE14518@FreeBSD.org> <4lt098$erq@itchy.serv.net> <Pine.SUN.3.90.960427140735.3161C-100000@tulip.cs.odu.edu> <4mj7f2$mno@news.clinet.fi> <318E6BB1.6A71C39B@lambert.org> <4mtfsg$14l8@serra.unipi.it> <319407B4.32F4B8B6@lambert.org>
NNTP-Posting-Host: pc5829.hil.siemens-austria
X-Newsreader: TIN [UNIX 1.3 BETA-950824-color PL0]
Terry Lambert (terry@lambert.org) wrote:
( it's really not my fault that i have to disagree again )
: Effectively, this means an overall increasse in latency for every
: board added.
:
: For non-shared interrupts, the latency remains constant: another
: board can issue an interrupt immediately after processing since
: the ACK doesn't have to span several cards.
:
:
: Consider a hypothetical router with 4 ethernet interfaces. You
: can not have packets arriving independntly on two of the interfaces
: and sent to the other two interfaces if the interrupts are shared
: on the recievers. If your transmitters are interrupt driven, then
: you are messed up on the transmit side as well.
(provided you have one CPU), you can process interrupts only serialised,
anyways. Shared IRQ contra no-shared IRQ:
logical events: board 1 issues an IRQ
board 2 issues an IRQ
discrete interrupt system:
board 1 issues IRQ1
board 2 issues IRQ2 ( or IRQ1 a bit later if they are serialised
internally)
shared interrupt system:
board1/2 issues IRQ1, one cycle to decide which one it was
board1/2 issues IRQ1, one cycle to decide which one it was
There is an overhead of deciding which one it was.
But if there is heavy traffic, then it's MUCH cheaper to have
shared interrupts. Interrupt frequency is to be kept low.
Internal serialization is a clear loss. Interrupt latencies can
be up to several tens of usecs. Checking for a board is a few PCI
cycles, much faster.
(maybe not true): And for PC compatible machines, interrupt processing
is still working the old way (even with PCI cards): the XT PIC hands
over the IRQ vector in an ISA cycle. (not sure about this last one)
very ineffective. (this was no pain for Intel since DOS was almost never
interrupt-driven)
So theoretically you are right. But on PC compatible systems you are
not.
: The same is true for, for instance, backup or news distribution
: over a network to a machine with the ethernet and the SCSI
: sharing the same interrupt.
no we are talking about network cards. IRQ latency on a 3Com509
card is about 100 usecs, from the point on where a packet arrives and
the board raises the (ISA) IRQ line, to the point where the first
instruction in the IRQ handler starts. (with a call gate in the
IDT, a ring switch and with minimal (read, ~1-2 usecs) preprocessing).
it's a clear win if we "merge" interrupts in busy systems.
Shared IRQ systems with proper OS support do exactly this.
For seldom interrupts, there surely is an overhead, but we are talking
about busy systems, are we :)
: Of course all this assumes you care about performance... which
: you do, or you'd be running cheap ISA cards for everything (and
: not sharing interrupts because ISA is incapable of it anyway).
well, the possibility is there, and many ISPs use shared ISA IRQ
serial cards. (well, serial cards are not a fair example, IRQ
merging is just too idal there, since many lightweight interrupts
occur)
-- mingo