Date: Wed, 5 May 1999 14:14:33 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: nadas@raleigh.ibm.com Cc: mike@smith.net.au, lli@ralvm6.rscs, vperis@watson.ibm.com, adamson@itd.nrl.navy.mil, freebsd-hackers@FreeBSD.ORG Subject: Re: High resolution timers Message-ID: <199905051214.OAA28848@labinfo.iet.unipi.it> In-Reply-To: <199905051137.HAA33622@rtpmail03.raleigh.ibm.com> from "Stephen Nadas" at May 5, 99 07:38:42 am
next in thread | previous in thread | raw e-mail | index | archive | help
> On a faster pentium (180mhz) repeated calls to gettimeofday suggest > that the gettimeofday() call takes about 6 usecs. But similar > measurements show that a select system call takes at least 20 > millisec. This 20msec is causing the application to send very bursty > traffic for higher packet rates because when it wakes up from select > there are many packets to send. This burstiness is undesirable in > our testing. So, my main question is: Why is this 20 millisec? > (there's quite a few older appends about this that don't resolve > much) What can I do to make it shorter? for sime reason it seems to be twice the HZ interval -- i suppose this is because you process gets scheduled at the beginning of a tick, goes to sleep on select, and is put in the ready queue at the beginning (or the end ?) of the next tick. I have no idea of the impact of HZ changing on ntp stuff.. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905051214.OAA28848>