<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
-------- Original MessageĀ  --------<br>
Subject: Re: Watching performance on a DHCP Server<br>
From: David W. Hankins <a class="moz-txt-link-rfc2396E" href="mailto:David_Hankins@isc.org"><David_Hankins@isc.org></a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@isc.org">dhcp-users@isc.org</a><br>
Date: Monday, February 11, 2008 10:39:40 AM<br>
<blockquote cite="mid:20080211163940.GB12971@isc.org" type="cite">
  <pre wrap="">On Fri, Feb 08, 2008 at 05:44:39PM -0600, Blake Hudson wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">The pros of async are that I can spend much less on server hardware, the 
cons being that I might lose 5 seconds (default commit time for ext3) of 
leases (single digits?) if my server were to freeze (again making the 
same assumptions about hardware failure).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It's impossible to say what will go on in those 5 seconds; it could
have been only one client, it could have been _all of them_.  These
days if an ethernet switch gets power cycled, all the clients will
renew early as soon as they get link back.  It's impossible to say
what events will "coincidentally" lead up to a failure.

Once beyond the failure, you get into all sorts of client behaviour
resonance; clients start DECLINEing leases that are already in use,
if they are capable of that, and once a lease is DECLINEd it is never
used again unless reset by the operator or no other leases are
available.

  </pre>
  <blockquote type="cite">
    <pre wrap="">I'd love to see this available as an option left up to the server 
administrator. I'll take a gander at the source next week and see 
exactly what it might take. Any changes I make will probably not be as 
useful as I'd prefer to stick with the src rpm provided by my 
distribution (Fedora), which is currently 3.0.x based.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I don't think the sources in question have changed much at all between
3.0.x and 4.1.x, but if you could draw your diff against 4.1.0a1, that
would be appreciated.

  </pre>
</blockquote>
<br>
I reviewed the code in 3.0.x and it's very simple. The code in 4.1.x
changes a bit with the queuing of ACKs. Though it looks like some of
the framework I'm looking for may already be integrated, but not
configurable yet, in the 4.1 code.<br>
<br>
The 4.1 code takes care of my main concern, but I see a few questions:<br>
fflush then fsync or fflush and forget.<br>
If fsync, when? - based on number of leases (how many) or timer (how
long)?<br>
<br>
I'm guessing that the performance difference between no fsyncs and
fsyncs every n leases is fairly small, making my code largely
unnecessary. If you'd still like to see a diff made, I could certainly
dust off the C++ skills and make the modifications to the source. I'd
love to be able to contribute, though I don't know if this is the right
place given that someone else's code already solves the problem.<br>
<br>
-Blake<br>
</body>
</html>