Re: Stable tag slipped

[Raphael Marmier <raphael@xxxxxxxxxxx>]

Matthew Dillon wrote:
> :The machine doing the hammering is a Mac running MacOSX.
> :[pomme:~] raphael% sysctl net.inet.tcp.msl
> :net.inet.tcp.msl: 600
> :[pomme:~] raphael% sysctl kern.ipc.maxsockets
> :kern.ipc.maxsockets: 512
> :
> :Just keep in mind there is one loop running locally on the dfbsd machine 
> :being tested.
> :
> :Why should the portrange be adjusted?
> :
> :Raphael
>
>     The portrange is used to select the port number to use for an outgoing
>     connection (it doesn't apply to incoming connections).  Most programs
>     use the standard first - last range, which is typically around 4000 ports.
>
>     This is usually not a problem but if an originating machine is making a
>     lot of rapid outgoing tcp connections to the same target (e.g. the MacOSX
>     box making connections to a single web server), it can run out of ports
>     because sockets often need a cool-down time (2*MSL = 60 seconds typ)
>     before they can be reused.  I don't know what the MSL default is on
>     the Mac.
>
>     Only one side of a TCP connection needs to go through the cooldown,
>     but another issue is that the side chosen depends on which side 
>     disconnects first.  And if both sides disconnect at the same time both 
>     can wind up in TIME_WAIT.
>
>     So, for example, my own test program (which I am about to commit in
>     /usr/src/test/stress/webstress) is causing over 5600 sockets to be
>     in a TIME_WAIT state on the client and 300ish sockets in a TIME_WAIT
>     state on the web server.  That's with the MSL reduced to 15000 mS
>     and net.inet.ip.portrange.last bumped up to 30000.
>
>     Under normal circumstances an HTTP session uses the HTTP/1.1 protocol
>     and the client does the disconnect, so TIME_WAIT sockets do not usually
>     build up on the server.  HTTP/1.0 (old style) connections often result
>     in the server doing the disconnect first which often leaves it saddled
>     with the TIME_WAIT socket.  SMTP connections to a mail server almost
>     universally leave the mail server saddled with the TIME_WAIT socket.

Thanks for the detailed explanation Matt.

So far, no hint of a problem on that machine, but I haven't tested the 
scenario of long running tcp connections moving big files. (I have no 
clue if this is relevant, I'm just guessing)

I am now looking for a way to do that without stressing too much the 
disks, not to mention them being a bottleneck. I'm thinking of doing 
that from a ramdisk.

by the way, will I be able to compile your webstress on MacOSX?

but for now I'm going to bed ;)

Raphael