Proposed DHCP Benchmarking Design

The IDs in requests sent to the server are made unique (i.e., using a random generator with good statistical properties) as necessary to track responses (using hash tables keyed by the transaction ID). In order to calculate response latency, either a table of transmitted packet IDs with transmit-times or some means of mapping ID to transmit time is used (note: using hash table and queue of sent messages). For a 4-way exchange, the tables would separately record the times for the initial and secondary exchanges. For simplicity, the IDs used for the two exchanges may have a fixed relationship (even for initial exchange, odd for the secondary exchange).

Transmission of requests and receipt of responses are multiplexed via pselect(). If necessary for performance, the program may be converted to multithreaded operation (note: as the limit is the kernel and the network, multithreading will not really help).

The program will generate diagnostics if it is unable to send requests at the requested rate (due to either CPU-resource or network limitations. Note: in fact it is more a kernel interface issue, and currently the local limits (ENOMEM/ENOBUF) were never reached?).

The default output will begin with the utility version number and the options the utility was invoked with, to aid in interpretation of results when they are captured and sent to others for analysis.

Note: additional parameters to control the contents of requests may be useful. This will be decided after experience with use. (note: provided template files and some offsets to interesting parameters)

The client variation is done by adding an uniform random value from 0 to <range> to the base(s). (uniform: if you draw a number <n> between 0 and 3, n mod 3 does not provide a value with the same probability for 0, 1 and 2...)

Last modified 6 years ago Last modified on May 8, 2012, 8:25:42 AM