Stable tag slipped

[Raphael Marmier]

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