On 10/8/07, James Lamanna <[EMAIL PROTECTED]> wrote: > On 10/8/07, James Lamanna <[EMAIL PROTECTED]> wrote: > > On 10/8/07, James Lamanna <[EMAIL PROTECTED]> wrote: > > > On 10/7/07, James Lamanna <[EMAIL PROTECTED]> wrote: > > > > On 10/7/07, James Lamanna <[EMAIL PROTECTED]> wrote: > > > > > On 10/7/07, Volker Lendecke <[EMAIL PROTECTED]> wrote: > > > > > > On Sun, Oct 07, 2007 at 09:31:23AM -0700, James Lamanna wrote: > > > > > > > > > > > > > Server sends 1500 byte packet > > > > > > > Client sends 52 bye ACK > > > > > > > Server sends 1500 byte packet > > > > > > > Client sends 52 byte ACK > > > > > > > etc.. > > > > > > > > > > > > > > Can anyone think of a reason for this? > > > > > > > > > > > > I did not find a link spontaneously, but Windows sometimes > > > > > > falls back to something that we call "rabbit pellet" > > > > > > mode. Maybe google shows up something for you. > > > > > > > > > > > > Volker > > > > > > > > > > > > > > > > > > > > > > I actually see that behavior using smbclient from a linux machine, so > > > > > its not necessarily Windows related. > > > > > > > > > > -- James > > > > > > > > > > > > > I've put some tcpdump logs from my macbook up at: > > > > http://emagiccards.com/james/tcpdump-vpn-logs.tar.bz2. > > > > It contains 2 files: > > > > > > > > vpn-wan.log - Transferring a file from my macbook over the WAN (logged > > > > in through VPN) > > > > vpn-nowan2.log - Transferring a file from my macbook not over the WAN > > > > (logging through VPN) > > > > (I have separate VPN servers on each size of the WAN). > > > > > > > > Here are the smbclient outputs: > > > > > > > > No WAN: > > > > getting file \Jun07.xls of size 2321920 as Jun07.xls (23.8 kb/s) > > > > (average 23.8 kb/s) > > > > > > > > Using WAN: > > > > getting file \Jun07.xls of size 2321920 as Jun07.xls Short read when > > > > getting file \Jun07.xls. Only got 1032192 bytes. > > > > Error Call timed out: server did not respond after 20000 milliseconds > > > > closing remote file > > > > (3.9 kb/s) (average 3.9 kb/s) > > > > > > > > -- James > > > > > > > > > > I've put up more logs this morning sans VPN. > > > They are in: > > > http://emagiccards.com/james/tcpdump-novpn-logs.tar.bz2 > > > > > > Both of these logs are from being directly plugged in on either side of > > > the WAN. > > > The 'nowan' log is the normal, fast transfer, whereas the 'wan' log is > > > over the WAN and has the unusable throughput. > > > > > > -- James > > > > > > > Another point of information: > > > > Samba (and only Samba, other protocols work fine) seems to drop a lot > > of packets. > > Looking at simultaneous tcpdump traces from both the server and client > > side, I see that lots of packets are dropped that are going from the > > samba server to the client. > > The sequence numbers look like this in some cases: > > > > Client Recv Server Send > > 1150 1150 > > 1152 1152 > > 1154 > > 1156 > > 1158 > > 1160 > > 1162 > > 1164 1164 > > 1166 1166 > > 1168 1168 > > 1170 1170 > > > > So in that case, a whole 5 packets were missed. > > I'm going to assume this isn't normal behavior, and other protocols > > (scp / ftp) don't seem to suffer from this problem. > > > > -- James > > > > Of course, it could also be tcpdump dropping packets too :) >
So as it turns out, apparently it was a window scaling issue. Turning on an excessively large window size on the routers (thereby enabling dynamic TCP window scaling) seems to have fixed the issue. I now get transfer rates around 130-160k/s. -- James -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba