Re: Weird ping statistics...

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

On Wed, 19 Jan 2011, Johnny Billquist wrote:

> Thanks for the check. Interesting that it's not just on the VAX. But the 
> question remains, why...?
>
> Anyone who could test some other architecture?

  I do not see this on my amigas (m68k).

  It would look like it's likely related to scheduling, since the 200ms
delay seems suspiciously like two time slices.  On my 4000/60, I can
easily see them if I'm running openssl speed at the same time.  I haven't
had a chance to test with a slower 4000/VLC yet.  I've done a ktrace of 
the ping process, and that shows ~199ms betweel the poll() call and the 
return.

  It's almost as if the network software interrupt has to wait for the
current process to finish its 100ms time slice, then the software 
interrupt signal the ping process that it has data, but the other process 
gets scheduled for another 100ms time slice before the ping process is 
scheduled.  I don't know how this would happen though - the vax appears
to be using __HAVE_FAST_SOFTINTS, which I think should allow the software 
interrupt to run as soon as the network interrupt code finishes, which 
should then do what ever it does to wake up the poll() in the ping 
process.  The current interrupted process would run the rest of its 100ms 
time slice, and the ping process should run right after that, which should 
show at most a 100ms delay.  I would also think that I would also be 
seeing some 100ms delays on my amiga, but I haven't seen anything close to 
that so far.  It's also interesting that at least one mips port shows 
this.  I haven't tried any of my pmax systems yet, but I plan on trying 
that sometime.

--
Michael L. Hitch                        mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA