Virtual clients

[inkdot7]

The commits makes it possible to have more clients available without using a large netmask for the source IP.

The virtual client number is encoded in the local_id, i.e. the transmit timestamp.

The virtual client bits are used to extended the number of available clients.

Note: not tested for PTP or interleave mode.

See it as WIP:

Should perhaps more masks be precalculated?

Some checks against too-large virtual bit numbers are needed as well.

[mlichvar]

What is the use case? Testing in a network where routing cannot be configured, or testing if the server performance degrades if all requests come from a single address (possibly matching a single NIC queue)? I'm wondering if this could be simplified to a special case with one IP address.

[inkdot7]

Initially it was for the reason of network which I did not want to reconfigure, but now that you say it, it would actually also be nice to have this capability in order to test various rate-limiting measures. And then I think it would be useful to keep the ability to have multiple clients as well.

Would it be a reasonable start to precalculate things like 1U << (32 - config->src_bits) into num_sources (or something such) variable? If so, inside the struct config, or as some global variable?

[oittaa]

IMHO it would be useful if ntpperf could be used to test NTP servers as a single local IP, without configuring ip route add 172.18.0.0/16 via 192.168.123.2 dev eth0 on the server. And trying to auto detect as much as possible would be another nice addition.

At the moment the simplest way to run a test is something like this:

./ntpperf -i eth0 -m AA:BB:CC:DD:EE:FF -d 192.168.123.1 -s 172.18.0.0/16 -B 

It would be extremely helpful if you could just run something like this (it would be coming from a single IP only)

./ntpperf -d 192.168.123.1 -B