[ntp:questions] Testing throughput in NTP servers

Ulf Samuelsson 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
>> ideal.
>> 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.
>>
...

>
> Terje



More information about the questions mailing list