[ntp:questions] Testing throughput in NTP servers
ulf at invalid.com
Mon Sep 17 14:29:58 UTC 2012
>> Part of the requirement, is that the dependencies on the underlying O/S
>> should be minimized. If an FPGA can handle everything, then this is
>> Currently the FPGA will split incoming packets into streams with one
>> stream per thread.
> Why can't your FPGA do the entire NTP processing, for all regular
> request packets?
> Grab the current timestamp, fill it into the T1 & T2 fields, along with
> leap indicator etc., then return the packet.
Because noone wrote the HDL for it (yet).
This is the alternative solution, if the first solution does not work.
>> The first FPGA H/W has some limitations, in that the reading the
>> timestamp counter from the CPU is really not recommended, since you kill
>> the PCIe performance.
> If the FPGA can do everything, then it (obviously) require a board-local
> clock source as well...
>> Instead the ntp code adds a delay to the incoming packet timestamp,
>> and the FPGA H/W sends out the packet at the correct time.
> OK, this still means that the host CPU must be involved in every packet.
Yes, in the current implementation.
>>> That's more than 100 M requests/second!
>> Line speed is 10M+ packets/second.
> That should be easy. (Famous last words!)
SMOP = Small Matter Of Programming.
> With a 1000 cycles/packet processing budget, 3 cores of a 3GHz quad core
> cpu would be more or less sufficient.
More information about the questions