FTP snel maar Windows networking stuk trager

[_Thanatos_]

Ik heb hier twee bakken, een Vista SP1 x64, en een Windows 2008 SP1 x64. Ze zijn verbonden met cat6-bekabeling en een SMC 8-poorts netwerkswitch. In de Vista bak zit een onboard chip, te weten een Atheros AR8121. In de server zit een Intel PRO/1000 PT kaart. Beide zijn netjes op 1Gbps full-duplex verbonden met de switch.

Via FTP bestanden kopiëren gaat in beide richtingen op 80~90MB/s. Dat is wat je van gigabit mag verwachten. Maar via windows networking gaat het wat slomer. Nog steeds sneller dan 100Mb, maar toch een "magere" 30MBps van client naar server, en andersom zo'n 35MBps. Als het 10% langzamer was geweest dan FTP, had ik het geaccepteerd, want het SMB-protocol heeft vast meer overhead. Maar hier moet gewoon iets geks aan de hand zijn.

Ik heb al gekeken naar de instellingen van de netwerkkaarten. Alle offloading opties staan aan, en dat zou het sneller moeten maken. Wel zie ik op de client uitschieters van kernel time naar 25% (op een quadcore) in Total Commander en in de verkenner uitschieters naar 50%. Op de server is dit patroon nagenoeg gelijk, dus óók 25% en 50%, maar dan op een dualcore. Met FTP schommelen de kernel times op de client rond de 15% en op de server rond de 30% (en dat voor ruim het dubbele aan throughput).

Volgens mij zit er dus iets niet goed, maar ik heb geen idee waar ik het moet zoeken. Het lijkt me duidelijk dat het fysieke spul in orde is, anders zou FTP nooit zo snel kunnen. Maar of ik dit nou op de client(s?) of op de server moet fixen? En waar ik dan naar moet zoeken? Ja op google ben ik ook al geweest, maar het enige dat je vindt, zijn die duffe TCP windowsize-tweaks. Maarja, FTP gaat ook door TCP heen, dus dat gaat niet helpen.

Wie helpt me aan een goeie throughput?

[koekkoek]

Zit hier met hetzelfde probleem, maar heb een workaround gevonden door het programma teracopy te gebruiken. Kan nu met 50 MB/s bestanden overkopieren via de verkenner je kan ook de buffer size aanpassen tijdens het kopieeren, speel hier maar is mee.

[thegve]

Dit is inderdaad bekend. Het CIFS/SMB protocol is niet echt efficient.
Bij mijn vorige opdrachtgever hadden we een Gbit LAN met een degelijke backbone, en konden "wij" als developers sneller uploaden naar een FTP server in een colo via een met het hele kantoor (50 man) gedeelde 50Mbit pijp, dan dat we dat van de ene naar de andere konden.
De sysadmin aldaar was daar ook al eens mee bezig geweest, maar schijnt niets aan te doen te zijn.

[_Thanatos_]

Daar geloof ik dus niets van. Ik heb nml ook netwerken gezien van 100Mb die gewoon 10MBps trokken. Dus de volle bandbreedte zo'n beetje. Ik denk dus niet dat je het aan het SMB protocol kunt toerekenen dat alle verkeer 50% data en 50% overhead is, want dat is wat ik in mijn situatie zou meten.

Mijn stelling dat het geen overhead kan zijn, wordt overigens ondersteund door te kijken naar de ruwe throughput van de netwerkadapter: die komt overeen met de gemeten snelheid via windows networking. Het is dus gewoon alsof ie weigert de volle bandbreedte te pakken.

En dan, ik kan me wel voorstellen waarom ie dat weigert: die kerneltijden. Hij kan niet harder als de CPU maxxed out is. Maar hoe los je dat dan op? FTP bewijst dat netwerk throughput helemaal niet zoveel kernel op hoeft te slurpen, dus er moet ergens een fout zitten.