httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 14:34:08 GMT
rbb@covalent.net writes:

> The reason it shouldn't do any coalescing, is that it really doesn't know
> enough about the network type to do the coalescing.  Assume we can swap
> out the filter that does the writing for a new filter that uses an ATM
> network.  The packet sizes on ethernet and ATM should probably be
> different.  If we coalesce above the core, this becomes a harder problem
> to solve.

I think the best we can do is give the TCP stack a nice bit of data to
work with at a time (8K-9K)...  For a modern stack, what is more
interesting is not the interface MTU but the PMTU.  Suppose we know
the PMTU (not gonna happen)...  This isn't too helpful because the
PMTU is almost always going to be much smaller than the amount of data
we'd want to pass the stack at once, so we're back to just giving the
stack a bunch of data at once.  

Yeah, we can go faster in contrived benchmark situations and a small
percentage of real world scenarios if the size of bunch-of-data is
close to the MTU of somebody's favorite medium, but that isn't going
to have any effect on normal data transmission.  And if the size of
bunch-of-data is a multiple of the MTU of a common medium that's cool
too because it will often help a little, but the point of this is that
we aren't really going to know how to adjust the size of bunch-of-data
on a connection-by-connection basis. 
-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message