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

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 against his -current
box, it would take several second for telnet localhost to actually

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


  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

Reply via email to