Watching performance on a DHCP Server

[Simon Hobson]

Enrique Perez-Terron wrote:

>  > Now consider the case (the normal case for a server that's been
>>  installed for a while on a busy network) that there are NO unused
>>  leases at all.
>
>What happens if somebody connects a new PC to such a network?
>
>>  Also consider that in the situations mentioned (long
>>  term power outage), nearly all the clients will have had prior leases.
>
>Don't the leases expire?

This is NOT a Micro$oft DHCP server !

Yes leases expire, but they are NOT deleted - they are marked as 
expired and available for re-use.

Initially, with a fresh config and fresh leases file, clients will be 
allocated from a pool of "never previously used" addresses. Leases 
that expire get marked as free but are NOT re-allocated at this stage.

Once there are no "not previously used addresses", then the server 
will start to re-use addresses that have been allocated before - and 
it does this on a least recently used basis. Ie, the address whose 
lease expired the longest ago will be re-used.

This means that a client can leave the network for a long period, and 
when it returns it may get the same address back - if the size of the 
pools, number of clients, and churn rate are such that it's old 
address hasn't been reused for another client.

What does NOT happen (with the ISC server, it does with the non-rfc 
complaint Micro$oft server) is that a client returning to the network 
after it's lease has expires gets a new random address (unless the 
address has already been reassigned).

>  > In both these cases, there is no list of unused leases to
>>  pre-allocate - if you go ahead and pre-allocate expired leases, then
>>  you risk violating the protocol by pre-allocating an address that a
>>  client later wants to come back and use.
>
>ISPs use DHCP to assign addresses to N computers from a pool of M
>addresses with M < N. When a client comes back and wants an address, it
>gets a different address because the previous address has been
>reassigned to a different client.

Not usually true any more - with always on connections like ADSL, the 
size of the pool needs to be considerably larger.

>  > But the main issue is that
>>  when these clients with expired leases come back online - do you a)
>>  give them their old lease back (your method has gained nothing),
>
>I fail to see the connection. Why has my method gained nothing?
>The point was to avoid fsync for each transaction.

The client won't be given one of your pre-selected addresses, it gets 
it's old address back. Thus your pre-selecting of addresses to lease 
has done nothing useful in this case.

There are easier ways to avoid the fsync after every transaction - 
like simply not calling fsync each time as is already being 
done/planned in V4.

>The advantage of my proposed scheme over turning off fsync alltogether,
>is that after a crash you know that the addresses in the lost leases -
>if any - belong to a small set that you can dispense with, having a few
>more addresses than computers.

OK, I see where you are coming from now, but to be perfectly honest 
it does sound a complicated system for something that I think we've 
already agreed has simpler workarounds. The simplest seems to be to 
enable the write-back cache in a battery backed raid controller - 
then the fsync doesn't actually involve a physical write to disk 
there and then. My personal opinion is that a raid controller with 
battery backup should be no less reliable than a single disk - if you 
raid controller dies then your server is screwed anyway and quite 
possibly your whole leases database.



>Or, perhaps there is yet another way: delay responses to the clients,
>process other incoming request, and upon timeout (a few milliseconds),
>send all the offers to the log in a single transaction, fsync(), then
>send out all the offers to the clients. However, this may require a far
>bigger rewrite of the server.

It would indeed.