NOTE: I'm not on -current, so if you trim committers, please cc me.
I believe I have discovered a problem w/ -current... I would like more
data points to see if this is a problem... when I run
http://people.FreeBSD.org/~jmg/bench.py against a -current box (so far
I have tested against builder and kris's -current box) I find that it
has a very high time to establish the connection and return the data..
Durning this time, the box sometimes sits at 80% idle which it shouldn't
be... other times it pegs the cpu, but it cycles between the two...
when I run it against keichii's -stable box or my 3.4-R box I peg the
cpu load at 100% used and it does not exhibt the delayed connection
response...
I also see that sometimes it takes 15 seconds for a connection to be
established and all the data (all of 5 bytes or so) to be read off
the connection)...
kris has experienced that when running bench.py against his -current
box, it would take several second for telnet localhost to actually
connect...
I run this test using a line like this in inetd.conf:
nntp stream tcp nowait nobody /bin/echo echo blah
you don't have to modify your /etc/inetd.conf to run it, you can simply
make nobody yourself change nntp to a service like wnn6 which is >1024,
stick it in somefile, and run inetd as:
inetd -R 50000 somefile
you need the -R to make sure that inetd doesn't rate limit the connections
per minute and kill the service durning the test...
I didn't see anything but a small reorder of a call to callout_reset that
jlemon commited in rev 1.41 but didn't mention in the log... (unless this
is part of enabling NewReno)
I would appreciate to find out if someone else sees this problem, or
doesn't on both -stable and -current...
Thanks....
--
John-Mark Gurney Voice: +1 408 975 9651
Cu Networking "I say all sorts of useless things." -- cmc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
