[Kea-users] Understanding how perfdhcp measures drops

[Andrei Pavel]

The one-second timeout is per packet. If a discover is not met with an 
offer within one second, the offer is considered lost or not sent.

The reason for the lack of responses in your perfdhcp run is that it 
sends 200 discovers as fast as it can and then immediately exits. 
Whatever responses it may have gathered during this time are all the 
responses it considers.

I think the best way to mitigate this last issue with the current 
implementation of perfdhcp is by lowering the rate i.e. at least 
specifying one in the first place. `-r 200` should yield a better 
response rate, probably a single lost response from the last request it 
sent. There is another flag to help with those few lost responses at the 
end which is `-W <microseconds`. It waits for any responses for the 
specified amount of time, but there's a drawback which is that the time 
also goes into the rate reported at the end, making it less accurate, so 
for this reason, it's not to always be included. However, it only seems 
to work correctly if the rate is also mentioned. I've opened a ticket[0].

Except for the problem in the mentioned ticket, the other limitations 
seem more universal to performance measurement in the client-server 
paradigm than subject to easy fixing.

[0] https://gitlab.isc.org/isc-projects/kea/-/issues/2397

On 01/05/2022 18:28, jarl wrote:
> Hello,
>
> This is probably a silly question, but I can't seem to be able to wrap my head around it.
>
> I'm testing perfdhcp 2.0.2 in Ubuntu 20.04.
>
> The perfdhcp documentation (https://kea.readthedocs.io/en/kea-2.0.2/man/perfdhcp.8.html) says:
>
> "By default, if there is no response received with 1 second, a response is considered lost and perfdhcp continues with other transactions."
>
> So, I would think that any run of perfdhcp would take, by default, at least 1 second to complete, because it needs at least 1 second to conclude that a request was dropped.
>
> However, I tested an example such as:
>
> perfdhcp -n 200 <DHCP_SERVER_IP>
>
> Yes, I realize that 200 requests is meaningless as a load test. But what confuses me is that this command takes well under 1 second to run, and it still reports dropped requests.
>
> Using different values in the -d command-line switch doesn't seem to make it take any longer to run.
>
> There is probably something simple that I'm misunderstanding.
>
> What am I missing?
>
> Thank you.