In some email I received from Frank van der Linden, sie wrote:
> I profiled a kernel while doing a series of lat_connect runs
> (from lmbench), and the first line was:
> 
> Each sample counts as 0.00390625 seconds.
>   %   cumulative   self              self     total           
>  time   seconds   seconds    calls  us/call  us/call  name    
>  13.33      0.28     0.28      724   388.47   388.47  in_pcblookup_port
> 
> Connect speed may not seem the most important benchmark, but I can
> imagine that something like a webserver would like to have these
> numbers a lot lower. The connect latency, as I measured it on
> the same hardware with hbench, doubled between NetBSD 1.3
> and NetBSD 1.4, and I think we should get back to the old
> numbers.
> 
> Anyway.. it would appear that in_pcblookup_port is a plain linear
> search on a linked list, which soaks up a lot of time even
> on the machine where I ran the test (which isn't listening to
> a whole lot of ports). FreeBSD, for example, made this a hash
> lookup. It may be worthwhile to do the same.
> 
> Comments?

For a web server, the appropriate system call to benchmark is accept,
not connect, unless I'm mistaken ?  Is hbench using two different
machines to measure this ?  Otherwise, how do know if you're doing
a connect from A to A which half the delay is really in ?

Darren