Let me try this again - as the pictures didn't seem to come through, and I 
resubmitted with a PDF file but it was too large ... :-(. Here are links to the 
pictures (thanks Samuli for your help!)

 

1) No OpenVPN - just a direct link

<http://build.openvpn.net/image007.jpg>

 

2) OpenVPN, keepalive = 10 120

<http://build.openvpn.net/image008.jpg>

 

3) OpenVPN, keepalive = 20 120

<http://build.openvpn.net/image009.jpg>

 

Thoughts?

 

Thanks,

... Russell



On Sun, 07/10/2011 08:58 AM, Russell Morris <open...@rkmorris.us> wrote:


> 



> 





 * 
 * 
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}


 * 
 * 



Hi,

 

My apologies in advance for the large pictures below - but I wanted to capture 
some data to help demonstrate this issue (and so we can perhaps determine what 
is causing it).

 

Some ping (RTT) data, between the same two machines (endpoints) - with and 
without OpenVPN running. In the OpenVPN case I edited the routing table to 
force the traffic over the OpenVPN link (same physical link, and no 
intermediate machines ... just the two endpoints). In all cases the sample 
interval is 500 ms. Here's the data ...

 

1) No OpenVPN - just a direct link.

  

 

2) OpenVPN, keepalive = 10 120

  

 

3) OpenVPN, keepalive = 20120




>  

So it doesn't look like keepalive is the culprit (or at least not all of it). 
Any thoughts?

 

Thanks!

 

... Russell

 


> On Fri, 07/08/2011 10:39 PM, Daniel <ktd...@gmail.com> wrote:

> 

Not sure if this would be the cause, but if openvpn ping is the
> culprit, what would be the correct measure to take?
> Increase the openvpn ping interval?
> Change MTU?
> Or its a bug and something should be done from the openvpn point of view?
> 
> Dan.
> 
> On 9 July 2011 10:42, Jan Just Keijser <janj...@nikhef.nl> wrote:
> > Russell Morris wrote:
> >> Hi,
> >>
> >> I have been measuring data throughput and RTT on my OpenVPN link (client 
> >> to server), and while data throughput has been quite consistent (in the 
> >> 25-30 Mb/s range), RTT (ping) has shown a strange artifact.
> >>
> >> If I run ping continuously (1 second interval), I may see 10 or 20 very 
> >> consisten runs, at ~ 10 ms ... but then a single point at 200-250 ms. If I 
> >> let it keep running this keeps happening - not with a consistent pattern, 
> >> but about this rate.
> >>
> >> Has anyone else seen a similar artifact?
> >>
> >
> > ping RTT times over a VPN link can vary quite a bit, as I've noticed,
> > esp after a lack of activity for some time. If the spikes happen every
> > 10 to 20 seconds , however, then I suspect the openvpn pings are getting
> > in the way - try changing the 'ping' (or 'keepalive') options to
> >  ping 20
> > or
> >  keepalive 20 120
> > if the spikes now occur very 20 to 40 seconds then you've found the culprit.
> >
> > HTH,
> >
> > JJK
> >
> >
> > ------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously valuable.
> > Why? It contains a definitive record of application performance, security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> > _______________________________________________
> > Openvpn-users mailing list
> > openvpn-us...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openvpn-users
> >
> 
> 
> 
> --
> Daniel
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2 
_______________________________________________
Openvpn-users mailing list
openvpn-us...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to