[Xorp-hackers] Some performance numbers

[Marko Zec]

On Thursday 23 February 2006 14:11, Hasso Tepper wrote:
> I have played with BGP full feed during last days and found out that
> unfortunately performance isn't acceptable for real world usage.
> Tests have been done with 1.8 Pentium M (speed-step off) laptop 512MB
> memory. One eBGP multihop peer announcing full table. For nexthop
> resolving static the default route is entered into Xorp.
>
> Peer up without static default route (no routes installed into RIB):
> ********************************************************************
> It takes about 4 seconds to receive full table, xorp_bgp takes about
> 90MB of memory after this. Not very bad IMHO.

Unfortunately at the moment we are roughly an order of magnitude slower 
than this, something must went wrong with your measurements.  On a 3.4 
GHz Pentium 4 receiving ~180k routes into xorp_bgp (while not 
propagating any of them to the RIB/FIB) lasts around 42 seconds.  The 
OS is FreeBSD 4.11 FWIW.

> Peer up with static default route (routes installed into RIB and
> FIB):
> *********************************************************************
>* It takes about 60 seconds to receive full table and to put routes
> into RIB/FIB, xorp_bgp takes about 100MB of memory after this. Memory
> usage is still acceptable, but 60 seconds is certainly very far from
> being acceptable.
>
> Peer down with static default route (routes removed from RIB and
> FIB):
> *********************************************************************
>* Just entered "disable: true" into peer config and committed. It
> takes about 4 minutes and 40 seconds to remove all routes from RIB
> and FIB. This isn't acceptable at all of course.
>
> I wouldn't expect from Xorp instant failover and peer up/down times
> like hardware router vendors can achieve. They have many tricks in
> use which are not available for software routers. But it should be
> certainly happen during max some seconds, not minutes.
>
> 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.

> 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.

Cheers,

Marko