Hi all,
Sorry for the delay forwarding this email, but I don't find time to
breath lately (and thus Oxygen does not make it to my brain :)
Hope it's an easy one.
- Forwarded message from Robert de Bath -
From: Robert de Bath
Reply-To: Robert de Bath , 182...@bugs.debian.org
To: sub
Aaron,
I've found that the linux scheduler on 2.4 does a fairly good job at giving
openvpn the CPU that it needs, even on a more heavily loaded system. When
openvpn is forwarding tunnel packets, it is essentially i/o bound, and as such
gets a priority boost. When TLS keys are being negotiated, h
Download:
http://sourceforge.net/projects/openvpn/
Release Notes:
This release adds options for persistence of replay protection information
across sessions, pass through of IPv4 TOS bits from the TUN/TAP device to the
UDP link, some advanced MTU control options, moderate revamping of the build
One of the things that I just thought about is, that we can probably have
openvpn call sched_setscheduler() using something like SCHED_RR. This
might be of more use than just renicing the process. Considering we are
in a fairly performance critical path for a userspace process this would
seem to
