Re: PPTPD upload speed bottleneck
Gustavo Homem <[email protected]> Sun, 17 Nov 2013 12:33:11 -0000 (WET)
| Newsgroups | gmane.network.poptop |
|---|---|
| Message-ID | <[email protected]> |
Hi Christoph, > [ re-sent ] > > Gustavo Homem wrote... > > > Command line scp transfer performance between end points WITHOUT > > using the VPN is: > > > > up ~ 700KB/s > > down ~ 1100MB/s > > That should be "KB" I presume (but it shouldn't matter). Exactly. > > (...) > > > So, either the PPPD client or PPTPD is limiting the traffic rate to > > something way below the connection rate and, therefore, queuing > > happens. Which one would it be and why? > > Wild guessing: Some rate limiting is still in effect. Either on the > client, hidden deeply in an ip-up script, or in the network, applied > to ecapsulated (i.e. GRE) traffic and in client->server direction > only. > No, the traffic shaping was off in the router, which is the pptp client, during the tests. I tried the transfers both directly from the router and also from two network machines that go through the router to connect to a VPN host. Those machines have no rate limiting either. Unless you are suggesting that the ISP is targeting GRE packets specifically, which would seem very odd. > To find out, I'd run tcpdump on both sides and compare the latency > for > encapsulated and other packets under load. If there's no significant > difference, it might be local. Then comparing the timestamps on > client > side's dumps (when did a packet leave ppp0, when the related one > eth1?) should give an indication. > I did compare the latency: the latency for direct network to network pings is perfect (7-15 ms) whereas the latency for encapsulated packets fluctuates between 7 and 700ms. So the virtual pipe for VPN packets gets congested at 160KB/s whereas the real pipe has lots of room available. At 160KB/s there is no relevant load in the real connection. Buffers must be filling up somehwere. Following your suggestion I ran tcpdump on ppp0 and eth1 at the same time and compared to the ping console output: http://pastebin.com/RZNNSTTj It would seem that the delay is not local to the pptp client router. > FWIW, I was not able to reproduce your scenario. I am however quite > sure that pppd, pptpd and pptp-client are innocent. Blaming the > network instead is always a good start :-> > Network related problems are usually not obvious. I suspected of pptp or pptpd because there are lots of people complaining about similar situations. But you may be right. Let's see what else I can discover. Cheers Gustavo -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ Poptop-server mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/poptop-server