496934 - Allow a configuration option to set the starting sndBufferSize to max on session start

Status: RESOLVED INCOMPLETE

(Firefox :: General, enhancement)

Description

[Raymond Mills]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090427 WildBrowser/3.6a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090427 WildBrowser/3.6a1pre

In nsSocketTransport2.cpp
                 nsSocketTransport::InitiateSocket()
 We would like the option to override the OS initial sndBufferSize and 
 set a fixed value from a parameter.  This is relevant to Windows Vista 
 where the size starts at 8K and ramps up.
 There is a variable already "network.tcp.sendbuffer integer 131072"  
 that does not affect this module under Windows Vista.

 Currently in our testing we set sndBufferSize = 131072; after
     PRInt32 sndBufferSize;
     gSocketTransportService->GetSendBufferSize(&sndBufferSize);
     if (sndBufferSize > 0) {
         opt.option = PR_SockOpt_SendBufferSize; to force the 
 buffersize under windows.
 Potentially another variable in the about:config to force this value to be used under windows?


Reproducible: Always

Comment 1

[Jason Duell]

We essentially added exactly what you're asking for in bug 454990 (see this patch: https://bugzilla.mozilla.org/attachment.cgi?id=361174&action=diff).

This patch was added specifically for Vista and other Windows versions.  Are you saying you're not seeing the buffer size preference honored on your system, and you need to hand-code a manual setting of sndBufferSize = 131072 in order to get better performance?

Comment 2

[Raymond Mills]

From the packet captures I did in Vista the ramp up of 8k -> 130k was still happening even with network.tcp.sendbuffer=131072.  I'll try to get some captures today that I can include.  

This is what I did to force it.
  // if the network.tcp.sendbuffer preference is set, use it to size SO_SNDBUF
  // The Windows default of 8KB is too small and as of vista sp1, autotuning
  // only applies to receive window
  PRInt32 sndBufferSize;
  gSocketTransportService->GetSendBufferSize(&sndBufferSize);
  if (sndBufferSize > 0) {
      opt.option = PR_SockOpt_SendBufferSize;
      sndBufferSize = 131072;
      opt.value.send_buffer_size = sndBufferSize;
      PR_SetSocketOption(fd, &opt);
  }

It did not appear to me that nsSocketTransportService2.cpp is actually returning the config value.  I was not able to debug though and step through the values being returned.

Comment 3

[Raymond Mills]

Jason, I was not able to reproduce the issue I had captured before in the packet capture when we started looking at the sendbuffer size, but I did do a simple test.  I set the value in the config to 1 on a clean install of 3.5b4.  No noticeable difference in loading a page.  This was on a windows XP pc.  I did try various values between 1 and 1024 with no change.

I would have expected a significant reduction in window sizes and/or multiple retransmits.

Comment 4

[Raymond Mills]

I did some further testing with the modified version and hardcoded it to a very low value and there was no affect there either.  This value may be overridden elsewhere somehow.

Comment 5

[Jason Duell]

I wouldn't be surprised if the TCP stack will only go below a certain size, i.e you can tell "set_sockopt" 1 byte for the sendBuf, but if you check with getsockopt, you'll find that a minimum size is returned that's 512 or 1K or something, at least IIRC.

So the more pressing issue is what difference you see when you hand-code in the 131072 value.  Can you attach a network trace (with ethereal or tcpdump, etc) both with and without the hard-coded 131072? 

Are you sure you're not just seeing the usual slow-start TCP algorithm?  I.e. you can set your sndBuf to be big, but that doesn't mean TCP is going to just start using that size on a new connection.

It would also be nice to know that you're seeing these differences repeatedly and predictably;  you're using a satellite network, and I assume packets can get lost pretty easily, which wreaks havoc on the bandwidth startup curve.  Have you tested this at least 10 times with/without the hand-coded setting, and seen consistent differences? 

Thanks.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Even more simply, since you can change the code, can you add a printf to the current code and see what value GetSendBufferSize() is returning?

Comment 7

[Raymond Mills]

It appears that this code is not being called.  I'm trying to figure out why not right now.  It may be that since we enable http pipelining that it's going somewhere else to establish the connection.

Comment 8

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.11 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

Comment 9

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.