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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
