Subject: Re: Lost clock interrupts in 1.4Z
To: Hal Murray <murray@pa.dec.com>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: current-users
Date: 06/05/2000 21:09:25
On Mon, Jun 05, 2000 at 02:45:31AM -0700, Hal Murray wrote:
>
> I see things like "time reset 15.640742 s" in the log file when running
> heavy network tests.
This is a message from ntpd, rigth ? Maybe it's just that ntp lost sync
messages because of the heavy network tests (I didn't look at the sources
so I'm not sure what this really means :)
> [...]
> 2) I don't understand the buffer allocation strategy. I assume they
> are piling up on the input dispatch queue and can't get processed
> because all the CPU cycles are getting burned by the interupt routines.
>
> Are there any mechanisims to limit that? Will things get better
> if I make NMBCLUSTERS big enough? If so, how big is that? I'm
> running with 4K or 8K now. That works fine for everything but
> the nasty UDP flood type tests.
If the CPU isn't fast enouth to process the incoming packets then you'll never
have enouth MBCLUSTERS.
>
> Should drivers stop listening in cases like this to free up the
> CPU? (I'm interested in the theory. I'm not volunteering to write
> the code.)
>
Maybe mechanism like this could be added, using the pool low and higth
water marks.
> 3) Some drivers call printf from interrupt level. That aggrivates
> this problem. It also provides obscure information which might be
> critical to tracking down a problem. This look like a hard/interesting
> tradeoff to me.
ratecheck() can be used to limit the number of printf() calls.
--
Manuel Bouyer <bouyer@antioche.eu.org>
--