Upload applet very slow with 9k jumbo frames

n0xlf

Joined: 2004-07-12
Posts: 17
Posted: Fri, 2008-07-25 02:04

I'm using the latest Gallery 2.x from SVN, running on Fedora 9, and the latest revision of Sun Java (v6, update 7). This may be a java issue more than a GR issue, but the upload applet runs at about 12kB/sec. over a LAN when running 9000 byte jumbo frames. If I change the server MTU to 8231 (or lower), it works at full speed. I have no idea why 8231 is the magic number, but 8232-9000 causes the problem. I have tested this on 3 different machines having 3 different gigabit NICs and with the latest drivers.

I used to have this problem with other programs such as FlashFXP, Openwebmail, and Outlook Express (all on the upstream side), but all of those went away with changing the LAN request buffer size (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q320829) and then by my transition to Vista. Adding the buffer size registry key to Vista has no effect on this issue, and all of the previously mentioned programs work fine without it.

This is more of a curiosity/annoyance than anything, but GR seems to be the only thing left that shows this behavior.

Any ideas?

 
oddroot

Joined: 2006-04-04
Posts: 4
Posted: Tue, 2009-07-28 20:36

This problem is actually still true. Jumbo frames causes abysmal performance on the upload (5-8k). After switching to 4500 MTU the issue goes away.

 
n0xlf

Joined: 2004-07-12
Posts: 17
Posted: Tue, 2009-07-28 20:44

Took me a long time to figure this out, but the problem has to do with blocking and non-blocking sockets when using jumbo frames. I posted this on some other forums, and it fixed the problem:

If you are running jumbo frames (9k MTU in my case on Vista and Win7) and have a local server that is also running jumbo frames, certain applications which use non-blocking sockets will be INCREDIBLY slow when used with your server. Examples include java apps, older versions of FlashFXP, Windows Mail/Outlook Express, and probably others. The details are here: »support.microsoft.com/kb/823764

The fix for me was this (nothing in the MS kb above says this, and their fixes did not work, but it is the underlying problem):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters]
"DefaultSendWindow"=dword:0000fc00
"DefaultReceiveWindow"=dword:0000fc00