Packet loss every 30.999 seconds

David G Lawrence dg at dglawrence.com
Wed Dec 19 07:19:28 PST 2007


> On Tue, 18 Dec 2007, David G Lawrence wrote:
> 
> >>>I got an almost identical delay (with 64000 vnodes).
> >>>
> >>>Now, 17ms isn't much.
> >>
> >>   Says you. On modern systems, trying to run a pseudo real-time 
> >>   application
> >>on an otherwise quiescent system, 17ms is just short of an eternity. I 
> >>agree
> >>that the syncer should be preemptable (which is what my bandaid patch
> >>attempts to do), but that probably wouldn't have helped my specific 
> >>problem
> >>since my application was a user process, not a kernel thread.
> 
> FreeBSD isn't a real-time system, and 17ms isn't much for it.  I saw lots

   I never said it was, but that doesn't stop us from using FreeBSD in
pseudo real-time applications. This is made possible by fast CPUs and
dedicated-task systems where the load is carefully controlled.

> of syscall delays of nearly 1 second while debugging this.  (With another

   I can make the delay several minutes by pushing the reset button.
 
> Debugging shows that the problem is like I said.  The loop really does
> take 125 ns per iteration.  This time is actually not very much.  The

   Considering that the CPU clock cycle time is on the order of 300ps, I
would say 125ns to do a few checks is pathetic.

   In any case, it appears that my patch is a no-op, at least for the
problem I was trying to solve. This has me confused, however, because at
one point the problem was mitigated with it. The patch has gone through
several iterations, however, and it could be that it was made to the top
of the loop, before any of the checks, in a previous version. Hmmm.

-DG

David G. Lawrence
President
Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500
The FreeBSD Project - http://www.freebsd.org
Pave the road of life with opportunities.


More information about the freebsd-stable mailing list