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>
--