[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Bug in status.c when building with VC


  • Subject: Re: [Openvpn-users] Bug in status.c when building with VC
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Thu, 9 Dec 2004 21:39:50 -0700 (MST)

On Thu, 9 Dec 2004, Blaine Fleming wrote:

> 
> >I tried the ICL non-static build.  It's nearly an order of magnitude slower
> >than my MinGW build (which is rc1 + a few inconsequential patches).  I'm not
> >totally clear what's going on, but one guess might be that in your ICL build,
> >the msg() and dmsg() functions in error.h are getting defined as functions,
> >not macros.  If this happens you will see a huge performance penalty -- on par
> 
> I never even thought about this.  None of the MS compilers support these 
> C99 features so ICL inherited this trait.  To verify this problem, I 
> replaced "#define msg x_msg" in error.h with "#define msg __noop" and the 
> performance went through the roof.  I was able to move about 18Mbps without 
> the VPN (direct), 11Mbps with the VC builds and 16Mbps with the ICL 
> build.  These were all using the default cipher and auth settings.  Running 
> with no auth or cipher improved the speed by a pretty flat 2Mbps.

That's more like what I would expect to see, and it's on par with what I 
am seeing with the MinGW build.

> However, the MINGW build still performs very low.  Even the binaries you 
> provide in the installer run less than 500Kbps.  Is it just me?  All tests 
> are performed between 2 windows boxes.

There must be something else going on here because such a huge performance 
difference cannot be explained by mere differences in optimization.

When you are running the MinGW build, what's the CPU utilization?

Are you using a TCP or UDP tunnel?  I did all of my tests with a UDP 
tunnel?

> >with what we are seeing here.  And because VC apparently doesn't support
> >#warning, you won't even be warned about it at compile time.  (Doesn't VC have
> >  it's own version of #warning, like maybe #warn? -- if so I'd like to fix 
> > that
> >place in error.h where the warning is ifdefed out for VC.)
> 
> The replacement for warning I use is #pragma message("your comment here").

Ok, I'll put that in error.h so people don't get bit by this in the 
future.

> >With the ICL build, the XP box is hitting 99% CPU usage in the openvpn process
> >while the linux server end of the connection is only seeing the openvpn daemon
> >hit 2 or 3% of CPU utilization.
> 
> Even with the same build you tested, I never saw my CPU usage hit above 
> 10%.  IPerf made it top out at about 8%, and these are some fairly old 
> processors being used.
> 
> Does anyone know of a C99 capable preprocessor that will support macros 
> with varargs?  I would like to keep the VC/ICL builds going but don't want 
> to completely rewrite the msg() routines.

Probably it would be possible to write a perl or python preprocessor that 
could deal with this.

One way it could be done is writing a perl script which would replace msg 
with msg1, msg2, msg3, etc. based on the number of arguments.

Vararg macros are so extremely useful and efficient for getting debugging 
messages into the code -- What is the VC-way of thinking about this, i.e. 
how do you do debugging output in such a way that the debugging printf 
statement's arguments are not evaluated unless debugging output is 
enabled?

The reason why turning msg() into a function kills performance is that the 
arguments to the debugging printf call are needlessly evaluated even if 
debugging is disabled.

James


____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users