Jan: > The only thing you can do, is to run something like Traffic Control (tc) > on the link to prioritize low latency traffic compared to bulk downloads
Yes, I thought about it... the problem is that I usually transfer files with scp and work over ssh, so it won't be as easy as simply prioritizing one port over another... but prioritizing based on a packet size seems doable. Greg: > The universal sign of a congested link is latencies going up by, easily, > an order of magnitude, and little or no packet loss. [i.e. 30ms to > 300ms, or even more] Once a connection reaches very high levels of > utilization, latencies increase dramatically. > > So, the fact that OpenVPN does similar things seems unremarkable to me. > [But perhaps I missed something more in the thread that does make it > more remarkable...] The problem is that my link is never "100% full", as ping times over the Internet to the same host (and from the server to other, TCP and UDP connected clients) during this "100% full load" are normal or only slightly larger. I suspect (but haven't tested it yet) that if I used another instance of OpenVPN to handle low-latency traffic, it would work fine despite other instances being fully loaded. Now I remember that definitely it worked this way when I had two machines on the same network, connected over TCP. When I fully loaded the connection from one client to the server, it was impossible to work remotely and ping was huge, but the second connection (another machine, same network) was mostly unaffected and still had both low latency and plenty of bandwidth available. Gert, Jan: > I just re-ran the test and in one direction I've got the latency spikes > under control (ping time < 70 ms). This is achieved by adding > "--sndbuf 32000" on the client and "--rcvbuf 36000 --tcp-queue-limit 8" > on the server. Great, it helped! Now the ping time jumped from ~30ms to ~350ms, but it's acceptable. Thank you! I'll experiment with these options to further increase throughput. David: > Port sharing is a feature for the server side to "hide" OpenVPN behind > an existing SSL/TLS based service (typically https). So packets which > carries an OpenVPN signature will be processed by the OpenVPN process. > Anything else will be sent to the provided IP address and port and the > OpenVPN process will just act as a proxy. > > This happens on _all_ packets - OpenVPN packets and anything else, not > just some or just during the initial handshake. Strange. Are you sure about it? What would be a reason for this with TCP? With UDP I perfectly see why (despite port-sharing being a TCP-only feature), but with TCP? Once a connection is established and it's known that it was an OpenVPN client thas has connected? This seems consistent with this code from socket.c (stream_buf_added()): #if PORT_SHARE if (sb->port_share_state == PS_ENABLED) { if (!is_openvpn_protocol (&sb->buf)) { msg (D_STREAM_ERRORS, "Non-OpenVPN client protocol detected"); sb->port_share_state = PS_FOREIGN; sb->error = true; return false; } else sb->port_share_state = PS_DISABLED; } #endif To summarize: - if port sharing state is ENABLED - if the protocol is not openvpn, we set state to FOREIGN - if the protocol is openvpn, we set state to DISABLED So it seems it works only on a first data packet, and I guess that states are: - ENABLED - we don't know yet if we're port-sharing, decision is to be made - FOREIGN - we know that the first packet wasn't openvpn one, so from now we're forwarding - DISABLED - we know that the first packet was our, so from now we don't forward ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users