DHCP Queue

[Greg.Rabil at ins.com]

Because the Vital QIP DHCP server uses a multithreaded architecture, which bears no resemblance to the ISC DHCP code.

Regards,
Greg

From: dhcp-users-bounces at lists.isc.org [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Brad Dameron
Sent: Thursday, February 12, 2009 3:25 PM
To: Users of ISC DHCP
Subject: RE: DHCP Queue

So speaking of this. I am looking at Altec-Lucent Vital QIP which has a DHCP offering that can do 6400+ leases per second. Those are 4-way handshakes on a dual dual-core 2.33Ghz machine with mirrored 120GB SATA1 drives running on a Red Hat 5 linux. I just don't see why this can't be accomplished with ISC DHCP as well.
The fastest I have seen with ISC is about 1200 per second. And that was with the fastest machine we could get using a ramdisk for leases and turning logging completely off. I'm baffeled by that.

Brad

________________________________
From: dhcp-users-bounces at lists.isc.org on behalf of David W. Hankins
Sent: Thu 2/12/2009 11:41 AM
To: Users of ISC DHCP
Subject: Re: DHCP Queue

On Thu, Feb 12, 2009 at 09:26:07AM -0800, Brad Dameron wrote:
> You can increase the lease per second substantually by going with 3.1.x
> and using the hash adjustment I have posted on this list before. I have
> gotten it into the 400 lps range with this. And I also tested with DHCPperf
> tool as well as some other in house generated perl scripts. Search the
> archive for my name.

Some day I will get back to making the hash sizes dynamically (re)size
themselves rather than needing to be tweaked by hand.

We also have quite a few sorted linear lists in DHCP, and I'm pondering
moving those to heaps now that we have a heap implementation in the
common library.  The trick is sometimes we really do want to pull both
from the head and the tail of the list at different times, so I'm
debating it.

There's an experimental 'delayed ack' feature in 4.1.0 by Christof Chen,
I couldn't make it work with failover in time for release :( so I made
it compile-out by default.  It should work fine right now in a single-
server situation, if you enable it at configure time.

It queues multiple requests behind a single fsync and transmits all
the pending acks at once.

It would be interesting to compare 3.1.2<->4.1.0 with this change
enabled.  It should significantly decouple the server's performance
from hard drive/fsync performance, I'm imagining multiplicative
benefits.

--
David W. Hankins        "If you don't do it right the first time,
Software Engineer                    you'll just have to do it again."
Internet Systems Consortium, Inc.               -- Jack T. Hankins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090212/2019b313/attachment.html>