<HTML dir=ltr><HEAD><TITLE>Re: DHCP Queue</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText14050 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>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. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>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. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Brad </FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> dhcp-users-bounces@lists.isc.org on behalf of David W. Hankins<BR><B>Sent:</B> Thu 2/12/2009 11:41 AM<BR><B>To:</B> Users of ISC DHCP<BR><B>Subject:</B> Re: DHCP Queue<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On Thu, Feb 12, 2009 at 09:26:07AM -0800, Brad Dameron wrote:<BR>> You can increase the lease per second substantually by going with 3.1.x<BR>> and using the hash adjustment I have posted on this list before. I have<BR>> gotten it into the 400 lps range with this. And I also tested with DHCPperf<BR>> tool as well as some other in house generated perl scripts. Search the<BR>> archive for my name.<BR><BR>Some day I will get back to making the hash sizes dynamically (re)size<BR>themselves rather than needing to be tweaked by hand.<BR><BR>We also have quite a few sorted linear lists in DHCP, and I'm pondering<BR>moving those to heaps now that we have a heap implementation in the<BR>common library. The trick is sometimes we really do want to pull both<BR>from the head and the tail of the list at different times, so I'm<BR>debating it.<BR><BR>There's an experimental 'delayed ack' feature in 4.1.0 by Christof Chen,<BR>I couldn't make it work with failover in time for release :( so I made<BR>it compile-out by default. It should work fine right now in a single-<BR>server situation, if you enable it at configure time.<BR><BR>It queues multiple requests behind a single fsync and transmits all<BR>the pending acks at once.<BR><BR>It would be interesting to compare 3.1.2<->4.1.0 with this change<BR>enabled. It should significantly decouple the server's performance<BR>from hard drive/fsync performance, I'm imagining multiplicative<BR>benefits.<BR><BR>--<BR>David W. Hankins "If you don't do it right the first time,<BR>Software Engineer you'll just have to do it again."<BR>Internet Systems Consortium, Inc. -- Jack T. Hankins<BR></FONT></P></DIV></BODY></HTML>