From: Dave Taht <dave.taht@gmail.com>
To: bismark-devel@lists.bufferbloat.net
Subject: Re: [Bismark-devel] initial openvpn results on capetown
Date: Mon, 30 May 2011 12:12:26 -0600 [thread overview]
Message-ID: <BANLkTimg83NmY5zk+eMnhSufQHScwm0zww@mail.gmail.com> (raw)
In-Reply-To: <BANLkTikhKMd3POrEwG8wwBk9z5PW6kAixQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]
On Mon, May 30, 2011 at 8:52 AM, Srikanth Sundaresan <srikanth@gatech.edu>wrote:
>
> On May 30, 2011, at 6:58 PM, Dave Taht wrote:
>
> > After running overnight, the openvpn server grew to about 8MB in size,
> and seems to have stabilized there.
>
> That's a lot, isn't it?
No. The server should run on a far more capable host than the router, which
would hardly notice.
More important is that I'm not observing unbounded memory growth, which is
important for long running processes.
The server size is also a function of the number of connected clients. There
are only two connected now.
The client (after much less abuse than I put the server through last night)
weighs in at
12932 1 root S 4548 7% 0% /usr/sbin/openvpn --syslog
openvpn(cu
Note that using VSZ as per either of these measurements do is a bad idea in
that it inaccurately accounts for stack size and shared library usage.
But as a rough measure, it's not bad, and we currently have over 32MB of ram
to spare, even after openvpn is running. dnsmasq, after some usage, will
grow larger than it is at present.
I'll put the client through some abuse in a bit.
As a client, openvpn has the ability to take a list of addresses, and ports,
to try an outgoing connection on.
As a server, multiple servers can listen also on multiple ports, on multiple
machines as well, so it is theoretically scalable to thousands of users.
My principal problem (long term) with openvpn, is as a user space daemon it
cannot take advantage of hardware acceleration on the client side, where
available (of the hardware projected to be in use for cerowrt, the only
thing that does hardware crypto is the dreamplug). I would also like to try
a heavier crypto algo than blowfish.
That said, once I got through the 'generate a cert setup hassle', it's nice
to be able to get to port 81 through the vpn, as well as see snmp stuff.
[-- Attachment #2: Type: text/html, Size: 2361 bytes --]
next prev parent reply other threads:[~2011-05-30 17:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-29 21:01 Dave Taht
2011-05-30 13:28 ` Dave Taht
2011-05-30 18:12 ` Dave Taht [this message]
2011-05-30 20:02 ` Walter de Donato
2011-05-30 22:43 ` Dave Taht
2011-05-30 23:06 ` Dave Taht
2011-05-31 14:52 ` Walter de Donato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTimg83NmY5zk+eMnhSufQHScwm0zww@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bismark-devel@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox