<!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">
The known clients are mainly wireless or cable modems. I agree that
management of each CPE device by MAC can be tedious, though generally
we use a web based front end which makes the process much more simple
and scalable as far as management is concerned.<br>
<br>
If I understood the 3.0.x code, a write (fflush) as well as an fsync
occurred anytime the lease was written (offer, ack) and the entire
leases database is re-written on restart.<br>
<br>
I hadn't even considered the fluctuation as people turn PC's on/off
based on the work day. Though our leases have generally remained stable
in the past with a 1 day lease timer. Same goes with PPP sessions,
though those are typically managed in modem.<br>
<br>
-Blake<br>
<br>
-------- Original Message  --------<br>
Subject: Re: Watching performance on a DHCP Server<br>
From: Barr Hibbs <a class="moz-txt-link-rfc2396E" href="mailto:rbhibbs@pacbell.net"><rbhibbs@pacbell.net></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 11:07:43 AM<br>
<blockquote cite="mid:EJEFKKCLDBINLKODAFMDIEBCLJAA.rbhibbs@pacbell.net"
 type="cite">
  <title></title>
  <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
  <meta content="MSHTML 6.00.2800.1605" name="GENERATOR">
  <div><span class="691144016-11022008"><font color="#0000ff"
 face="Arial" size="2">in the case I reported, the clients were
entirely within a single enterprise, and while it was certainly
possible for NICs to be replaced from time to time, the client
population was remarkably stable.  For us, a 7 day or even 31 day lease
would have been appropriate.  Our users were instructed to shut down
the clients every day at close of business, then to restart them the
following business day, so we effectively had 100% of the clients doing
an INIT-REBOOT at least once each business day, with well over 90%
rebooting at 8:00 AM -- talk about a spike in network traffic!  Over
time, with changing workload requirements, expansion of working
shifts, and the realization that considerable time could be saved at
the beginning of each shift (not just mornings any longer) by utilizing
sleep mode for power saving, the in-rush of init-reboot requests
dropped significantly.</font></span></div>
  <div><span class="691144016-11022008"></span> </div>
  <div><span class="691144016-11022008"><font color="#0000ff"
 face="Arial" size="2">There is one last point I forgot to mention in
my previous response...  our modification of the ISC server updated the
leases file for each and every message processed that modified the
lease.  Our server was based on version 2, so there were no DNS updates
as part of the lease assignment and renewal process.</font></span></div>
  <div><span class="691144016-11022008"></span> </div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="691144016-11022008">Basically, the more volatile your client
population, the shorter the lease time should be, though that is not an
absolute.  Consider operational hours, predictions of network traffic,
number of routers/relay agents and their placement, and typical use
patterns of the clients before deciding.</span></font></font></font></div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="691144016-11022008"></span></font></font></font> </div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="691144016-11022008">I've never been a fan of permitting only
known MAC addresses, as the daily maintenance of the server
configuration in very large environments is a major pain, and what of
NIC replacement without prior notice?  Just a few of my biases based on
experience with programmable NICs, frequent moves, adds, and changes,
and cheaply made NICs with high failure rates.</span></font></font></font></div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="691144016-11022008"></span></font></font></font> </div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="691144016-11022008">--Barr Hibbs</span></font></font></font></div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="691144016-11022008"></span></font></font></font> </div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="691144016-11022008"></span></font></font></font> </div>
  <div><font face="Arial"><font color="#0000ff"><font size="2"><span
 class="691144016-11022008"> </span></font></font></font><font
 face="Tahoma" size="2">-----Original Message-----<br>
  <b>From:</b> <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users-bounce@isc.org">dhcp-users-bounce@isc.org</a>
[<a class="moz-txt-link-freetext" href="mailto:dhcp-users-bounce@isc.org">mailto:dhcp-users-bounce@isc.org</a>]<b>On Behalf Of </b>Blake Hudson<br>
  <b>Sent:</b> Monday, February 11, 2008 07:51<br>
  <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@isc.org">dhcp-users@isc.org</a><br>
  <b>Subject:</b> Re: Watching performance on a DHCP Server<br>
  <br>
  </font></div>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;">Thanks
Barr, it is always interesting to hear relative practical experiences.
This is exactly the kind of problem I would like to prepare/plan for.
I've read that Microsoft defaults to an 8 day lease time. ISC uses a
default lease time of 10 minutes, with a max of 2 hours in their sample
config included with 4.1.x.<br>
    <br>
We have successfully used 1 day leases in the past. Though I know some
larger ISPs use 5 day, 7 day or even longer lease times.<br>
    <br>
I'm assuming that the main advantage to a short lease time is that
hosts that join and leave a network give their leases up more rapidly
(keeping IP pool usage as low as possible). The main advantage to
longer lease times being load on the DHCP server. If I have a
relatively stable network (only known macs are allowed) then it seems
like a longer lease time (say 7-14 days) is more appropriate. And on a
relatively stable cable or DSL network anything between 5-7 days seems
acceptable? Volatile networks (wifi hotspots?) would probably benefit
from a 1 hour or shorter lease time.<br>
    <br>
Does it sound like I am in the right ballpark with these figures?<br>
    <br>
-Blake<br>
    <br>
    <br>
-------- Original Message  --------<br>
Subject: Re: Watching performance on a DHCP Server<br>
From: Barr Hibbs <a moz-do-not-send="true"
 class="moz-txt-link-rfc2396E" href="mailto:rbhibbs@pacbell.net"><rbhibbs@pacbell.net></a><br>
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:dhcp-users@isc.org">dhcp-users@isc.org</a><br>
Date: Sunday, February 10, 2008 4:35:37 PM<br>
    <blockquote
 cite="mid:EJEFKKCLDBINLKODAFMDKEABLJAA.rbhibbs@pacbell.net" type="cite">
      <pre wrap="">this experience is with a derivative of version 2 of the
server, but as the basic functionality has not changed
significantly for IPv4, it may be instructive....

at the time, our environment had about 12,000 clients split
roughly 55/45 between two servers...  each server was
connected by two links to each of approximately 120 remote
subnets, each link diversely routed to minimize disruption
due to network problems, but also delivering 2 copies of
every client message to the servers

we suffered a massive regional power failure that lasted
2-1/2 days before complete restoration...  our clients
received 7-day leases, largely grouped with their renewal
times between 8 am and 6 pm, so in a 2-1/2 day outage, we
could expect renewal requests to come from about half of our
clients, and certainly init-reboot requests to come from
all...  so, that is roughly 18,000 requests to be serviced
as power is restored....

of course, the power restoral didn't occur all at once, but
was somewhat randomly distributed over a period of roughly
32 hours

entirely by coincidence, we had instrumented the server to
capture detailed message arrival rates and response times,
expecting a normal, boring weekend...  but then the power
failed, and...  we got lots more data than we expected!

the real-time clock on our computers was capable of only 1
millisecond resolution, so I must extrapolate....  our
servers survived a nearly CONTINUOUS load of more than 1,000
requests per second for 32 hours...

of course, your mileage may vary, but by choosing an
appropriate lease lifetime, you will probably see similar or
better performance.

--Barr Hibbs


  </pre>
      <blockquote type="cite">
        <pre wrap="">-----Original Message-----
From: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:dhcp-users-bounce@isc.org">dhcp-users-bounce@isc.org</a>
[<a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="mailto:dhcp-users-bounce@isc.org">mailto:dhcp-users-bounce@isc.org</a>]On
Behalf Of David W. Hankins
Sent: Friday, February 08, 2008 08:55
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
 href="mailto:dhcp-users@isc.org">dhcp-users@isc.org</a>
Subject: Re: Watching performance on a DHCP Server


On Thu, Feb 07, 2008 at 06:07:51PM -0600, Blake
Hudson wrote:
    </pre>
        <blockquote type="cite">
          <pre wrap="">By default in my distribution the leases file
      </pre>
        </blockquote>
        <pre wrap="">is stored in
    </pre>
        <blockquote type="cite">
          <pre wrap="">/var/lib/dhcpd/dhcpd.leases. This happens to be
      </pre>
        </blockquote>
        <pre wrap="">on a RAID1 array with
    </pre>
        <blockquote type="cite">
          <pre wrap="">15k scsi disks and iostat shows the array as
      </pre>
        </blockquote>
        <pre wrap="">being maxed out once it
    </pre>
        <blockquote type="cite">
          <pre wrap="">reaches ~ 300 I/O's per second. DHCP logging is
      </pre>
        </blockquote>
        <pre wrap="">done asynchronously to
    </pre>
        <blockquote type="cite">
          <pre wrap="">the same array (which normally experiences ~ 50
      </pre>
        </blockquote>
        <pre wrap="">I/O ops). With CPU and
    </pre>
        <blockquote type="cite">
          <pre wrap="">memory barely breaking a sweat, this leads me
      </pre>
        </blockquote>
        <pre wrap="">to believe that the
    </pre>
        <blockquote type="cite">
          <pre wrap="">limitation is with the disks (lots of tiny writes).

I could move the leases file to a different
      </pre>
        </blockquote>
        <pre wrap="">array, or to tmpfs, but
    </pre>
        <blockquote type="cite">
          <pre wrap="">before I do I just want to know if these
      </pre>
        </blockquote>
        <pre wrap="">results are typical and that I
    </pre>
        <blockquote type="cite">
          <pre wrap="">have interpreted the test data correctly and
      </pre>
        </blockquote>
        <pre wrap="">made the correct
    </pre>
        <blockquote type="cite">
          <pre wrap="">determination as to the bottleneck.
      </pre>
        </blockquote>
        <pre wrap="">those results are typical for that kind of
hardware, and you have
interpreted the test data correctly: fsync() is
the biggest
bottleneck.

in 4.1.0a1, you will find a feature, however,
which was provided to
us in a patch by Christof Chen.  it permits the
server to queue
multiple ACKs behind a single fsync(); default 28
(576 byte DHCP
packets filling default socket buffer send
sizes).  the burst of acks
are sent presently if the sockets go dry, and
shortly will be backed
up with a sub-second timeout.

it has some bugs we're working on, particularly
with failover, but
we'll address those in alpha.

you may find that it provides some form of
multiplicative benefit to
your performance stats, since fsync() is the
bottleneck, and now there
are 28 acks per fsync max.

so if you are only pushing 50 requests/s
currently, you may live
comfortably in a 250 request/s buffer for some
months until the
4.1.x code is stable?

    </pre>
        <blockquote type="cite">
          <pre wrap="">Also, I would appreciate any anecdotal evidence
      </pre>
        </blockquote>
        <pre wrap="">with regards to how many
    </pre>
        <blockquote type="cite">
          <pre wrap="">requests are typical in a large network under
      </pre>
        </blockquote>
        <pre wrap="">normal (or abnormal)
    </pre>
        <blockquote type="cite">
          <pre wrap="">conditions. If 10,000 users all of a sudden
      </pre>
        </blockquote>
        <pre wrap="">came online, how many
    </pre>
        <blockquote type="cite">
          <pre wrap="">requests would they really generate per second?
      </pre>
        </blockquote>
        <pre wrap="">there have been a few folks who suffered mass
power outages, i don't
know what search query to use, but you can find
them on the old
dhcp-server mailing list.  they did not report
problems, rather the
surprise at the lack of problem.

--
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?
    </pre>
      </blockquote>
      <pre wrap=""><!----><a moz-do-not-send="true"
 class="moz-txt-link-freetext"
 href="https://secure.isc.org/store/t-shirt/">https://secure.isc.org/store/t-shirt/</a>
--
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


  </pre>
    </blockquote>
    <br>
  </blockquote>
</blockquote>
<br>
</body>
</html>