[Xorp-hackers] Some performance numbers

Hasso Tepper hasso@linux.ee
Sat, 25 Feb 2006 09:29:13 +0200


Marko Zec wrote:
> On Thursday 23 February 2006 14:11, Hasso Tepper wrote:
> > Questions ... Is anyone aware of problem? Is it BGP or RIB or IPC or
> > ... problem? Is it worth of effort to open bugreport regarding this?
>
> While it looks like our IPC is quite inefficient at the moment and
> contributes most to the overall system slowness, there's also
> significant room for improvement inside the BGP implementation itself,
> such as path attributes handling code.  We have some minor tweaks in
> the pipeline waiting for a stable release to be rolled out first, but
> are just starting to track down the IPC issues.

After writing this I realised that there were some IPC performance numbers 
in the NSDI paper. So yes, inefficient IPC explains 60 seconds "put into 
RIB/FIB" time. And while looking at it, all - bgp, rib and fea - are 
equally busy during this 60 seconds. In "peer down" case bgp itself is 
the only process which is really busy though.

> > Can I help with something? I'm not familiar enough with design of
> > XORP and C++ coding yet to solve design related problems though yet.
> > But I have environment and can profile (direction, please?), test
> > patches etc.
>
> Just for the begining could you tell us more about your testing
> environment and methodology, since I'm regularly obtaining
> significantly worse results than what you reported.

Just guess - because I'm using optimised binaries without debug info? I 
have modified configure script to use -O3 instead of -O2 and configured 
with --disable-debug --enable-optimize. -O3 isn't probably significantly 
better than -O2, I just wanted to be sure that it works (no warnings) 
with release. I'm using gcc-4.1 (in release candidate state) in Debian 
unstable.


regards,

-- 
Hasso