Watching performance on a DHCP Server

[Blake Hudson]

>> I just read the thread and the disk IO indeed changes the game. ;)
>> Still, the gap between theoretical top performance and actual
>> performance seems extreme.
>> Even if you have the requirement that leases have to be committed to
>> disk before you respond to the client.
>>
>>   
>
> fsyncs are the most I/O intensive operation you can perform on 
> magnetic media. If I remember correctly it takes at least 2 full 
> rotations of the disk for an fsync to occur, although it may take 
> longer to commit more data. This is were solid state rules over 
> magnetic storage.
>
I also happen to be of the notion that the implementation of a protocol 
should be an exercise left open to the programmer, the API and 
interoperatibility should be defined more strictly in the RFC. The spec 
does say that the lease needs to be committed to persistent storage 
before being offered to a client. How persistent is magnetic media? Is 
battery backed up RAM in my RAID controller persistent enough? what 
about RAM in a battery backed up system?

This requirement seems like it would make most DHCP servers (windows, 
appliance routers, almost anything running on ATA disks) non-conforming 
to the spec. Just something for discussion, the specs leave very little 
open to interpretation on this one.

-Blake