Re: [Samba] Re: Unusable performance over WAN (part 2)
On 10/12/07, James Lamanna <[EMAIL PROTECTED]> wrote: > On 10/8/07, James Lamanna <[EMAIL PROTECTED]> wrote: > > On 10/8/07, Mike Eggleston <[EMAIL PROTECTED]> wrote: > > > On Mon, 08 Oct 2007, James Lamanna might have said: > > > > > > > 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. > > > > > > Great. For hysterical porpoises please document what specific changes > > > you made on the windows boxes and what specific changes you made on > > > your router. > > > > > > Mike > > > > > > > The only change I made on the routers was I added the global > > configuration command (both Cisco routers btw) > > ip tcp window-size 75 > > > > -- James > > > > Apparently this was 'temporary'. > I had to power cycle one of the routers, and lo and behold, the old, > slow behavior is back even with the window-size being set. > > Now I'm clueless again. > > -- James Are you sure there is no other underlying issues with the frame circuit? Are you taking CRC errors on the T1 interface at either end, etc.? Chris -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
On 10/8/07, James Lamanna <[EMAIL PROTECTED]> wrote: > On 10/8/07, Mike Eggleston <[EMAIL PROTECTED]> wrote: > > On Mon, 08 Oct 2007, James Lamanna might have said: > > > > > 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. > > > > Great. For hysterical porpoises please document what specific changes > > you made on the windows boxes and what specific changes you made on > > your router. > > > > Mike > > > > The only change I made on the routers was I added the global > configuration command (both Cisco routers btw) > ip tcp window-size 75 > > -- James > Apparently this was 'temporary'. I had to power cycle one of the routers, and lo and behold, the old, slow behavior is back even with the window-size being set. Now I'm clueless again. -- James -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
James Lamanna wrote: On 10/8/07, Mike Eggleston <[EMAIL PROTECTED]> wrote: On Mon, 08 Oct 2007, James Lamanna might have said: 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. Great. For hysterical porpoises please document what specific changes you made on the windows boxes and what specific changes you made on your router. Mike The only change I made on the routers was I added the global configuration command (both Cisco routers btw) ip tcp window-size 75 -- James Is 75 a good value. My router says the valid range is 0-65535. Stu -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
On 10/8/07, Mike Eggleston <[EMAIL PROTECTED]> wrote: > On Mon, 08 Oct 2007, James Lamanna might have said: > > > On 10/8/07, Mike Eggleston <[EMAIL PROTECTED]> wrote: > > > On Mon, 08 Oct 2007, James Lamanna might have said: > > > > > > > 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. > > > > > > Great. For hysterical porpoises please document what specific changes > > > you made on the windows boxes and what specific changes you made on > > > your router. > > > > > > Mike > > > > > > > The only change I made on the routers was I added the global > > configuration command (both Cisco routers btw) > > ip tcp window-size 75 > > > > -- James > > And the change on the windows box? > > Mike > Actually no changes to the windows box. They seem to behaving well now. Most of my tests were done with smbclient from a linux box anyways. -- James -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
On Mon, 08 Oct 2007, James Lamanna might have said: > On 10/8/07, Mike Eggleston <[EMAIL PROTECTED]> wrote: > > On Mon, 08 Oct 2007, James Lamanna might have said: > > > > > 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. > > > > Great. For hysterical porpoises please document what specific changes > > you made on the windows boxes and what specific changes you made on > > your router. > > > > Mike > > > > The only change I made on the routers was I added the global > configuration command (both Cisco routers btw) > ip tcp window-size 75 > > -- James And the change on the windows box? Mike -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
On 10/8/07, Mike Eggleston <[EMAIL PROTECTED]> wrote: > On Mon, 08 Oct 2007, James Lamanna might have said: > > > 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. > > Great. For hysterical porpoises please document what specific changes > you made on the windows boxes and what specific changes you made on > your router. > > Mike > The only change I made on the routers was I added the global configuration command (both Cisco routers btw) ip tcp window-size 75 -- James -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Eggleston wrote: > On Mon, 08 Oct 2007, James Lamanna might have said: > >> 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. > > Great. For hysterical porpoises please document what specific changes > you made on the windows boxes and what specific changes you made on > your router. > > Mike Yes, I wanted to say myself: I have not necessarily had this problem (I really haven't checked since we have local SMB servers), but the path to solving it has been fascinating, and is helpful for not just SMB troubleshooting. - -- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II |$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHCn78mb+gadEcsb4RAvWmAKCwKLOHSWnEhv9nFmIN7vEuy+DjXwCfdEtQ 3hhK2I1uN0Uhq7pTzRMbGAs= =ojhq -END PGP SIGNATURE- -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
On Mon, 08 Oct 2007, James Lamanna might have said: > 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. Great. For hysterical porpoises please document what specific changes you made on the windows boxes and what specific changes you made on your router. Mike -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
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 2 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 RecvServer 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
Re: [Samba] Re: Unusable performance over WAN (part 2)
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 2 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 RecvServer 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 :) -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
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 2 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 RecvServer 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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
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 2 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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
On 10/7/07, Doug VanLeuven <[EMAIL PROTECTED]> wrote: > > James Lamanna 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 2 milliseconds > closing remote file > (3.9 kb/s) (average 3.9 kb/s > I notice the WAN client is negotiating an MSS of 1316 for an MTU of 1356. > That used to be an issue with FreeSwan, but I haven't used the IPSEC > replacements recently. > > I've switched to OpenVPN which in their FAQ document several issues > surrounding MTU size and MSS. Most VPN providers provide similar FAQ's with > their products. > > One of the previous posts recommended changing the MTU. That might work, > but without knowing what kind if VPN you're using and the topology, it's > difficult to comment intelligently. > > Regards, Doug > > The VPN is Cisco (PIX). However, the VPN does not cause the issue. It just so happens that I'm not at the office today, so VPN is the only access I have right now. Tomorrow I'll get tcpdump traces when I'm physically on either side of the WAN, removing VPN from the equation. -- James -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
James Lamanna 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 2 milliseconds closing remote file (3.9 kb/s) (average 3.9 kb/s I notice the WAN client is negotiating an MSS of 1316 for an MTU of 1356. That used to be an issue with FreeSwan, but I haven't used the IPSEC replacements recently. I've switched to OpenVPN which in their FAQ document several issues surrounding MTU size and MSS. Most VPN providers provide similar FAQ's with their products. One of the previous posts recommended changing the MTU. That might work, but without knowing what kind if VPN you're using and the topology, it's difficult to comment intelligently. Regards, Doug -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
James Lamanna 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 James, Volker, See: http://www.linuxarkivet.se/mlists/mandrake-expert/0309/msg00162.html -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
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 2 milliseconds closing remote file (3.9 kb/s) (average 3.9 kb/s) -- James -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
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 pgpx5Au2b06uJ.pgp Description: PGP signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Re: Unusable performance over WAN (part 2)
James Lamanna pisze: On 10/6/07, James Lamanna <[EMAIL PROTECTED]> wrote: Hi all, Disregard my previous posts, I've consolidated everything here. I'm having terrible performance issues with samba over a WAN (point-to-point T1 link). Doing a copy of a 2MB file from a samba server to a linux client running smbclient takes over 5 minutes. SCPing the same file takes seconds. The server is running samba version 3.0.25c with kernel 2.6.16.18. I've put up a set of debugging logs at: http://emagiccards.com/james/sambalogs.tar.bz2 Inside are 3 files: smb.conf - the configuration of the samba server log.agard - the level 10 debug log of the copy from samba samba-tcpdump.log - a tcpdump log from the client side of the copy Any help to fix this issue would be greatly appreciated since the file server is pretty unusuable over the WAN. If you need any more information, please let me know. It is imperative that I find out what's happening here. Thanks. -- James Lamanna One of the other things that I've noticed is that the pattern of Data / Acks is different based on where I connect from. If I connect on the server side of the T1 link, the data / ack pattern seems to be: Server sends 1500 byte packet Server sends 1500 byte packet Server sends 1500 byte packet etc...(to 64k) Client sends 52 byte ACK Client sends 52 byte ACK Client sends 52 byte ACK etc... If I connect from the other side of the T1, the data and acks are interleaved: 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? MTU of T1 link ? Try decrease it. Irens Thanks. -- James -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] Re: Unusable performance over WAN (part 2)
On 10/6/07, James Lamanna <[EMAIL PROTECTED]> wrote: > Hi all, > Disregard my previous posts, I've consolidated everything here. > I'm having terrible performance issues with samba over a WAN > (point-to-point T1 link). > Doing a copy of a 2MB file from a samba server to a linux client > running smbclient takes over 5 minutes. > SCPing the same file takes seconds. > > The server is running samba version 3.0.25c with kernel 2.6.16.18. > > I've put up a set of debugging logs at: > http://emagiccards.com/james/sambalogs.tar.bz2 > > Inside are 3 files: > smb.conf - the configuration of the samba server > log.agard - the level 10 debug log of the copy from samba > samba-tcpdump.log - a tcpdump log from the client side of the copy > > Any help to fix this issue would be greatly appreciated since the file > server is pretty unusuable over the WAN. > If you need any more information, please let me know. It is imperative > that I find out what's happening here. > > Thanks. > > -- James Lamanna > One of the other things that I've noticed is that the pattern of Data / Acks is different based on where I connect from. If I connect on the server side of the T1 link, the data / ack pattern seems to be: Server sends 1500 byte packet Server sends 1500 byte packet Server sends 1500 byte packet etc...(to 64k) Client sends 52 byte ACK Client sends 52 byte ACK Client sends 52 byte ACK etc... If I connect from the other side of the T1, the data and acks are interleaved: 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? Thanks. -- James -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
