Brian Utterback <brian.utterb...@oracle.com> wrote: > On 12/20/2012 6:25 AM, Ulf Samuelsson wrote: >> >>> Yes there is. The ntpd program has to set a timestamp in the outgoing >>> packet and then specify the launchtime when it writes the packet. The >>> goal here is to have the timestamp written in the packet exactly match >>> the time the packet actually hits the wire. So, the timestamp in the >>> packet must be a little in the future when it is written so that by the >>> time the controller gets it the packet can be delayed until the right >>> time. Since ntpd cannot access the clock in the controller, >> >> The Network controller will timestamp the message in H/W as it arrives >> and will add a CMESG with the timestamp, and this is supported in >> ntpd since some time. >> >> You add a small delay to the receive timestamp to make your launchtime. >> >> systime does not get involved at any stage, and can be way off. >> >> (Note that I am only interested in Stratum 1 server functionality) >> > > You have to guarantee that the actual processing delay from controller > to controller is never more than .5 seconds minus your "small delay", > otherwise the timestamp will be off. It would be a good idea to > synchronize the system clock so that you can detect that kind of situation. >
We found that an unoptimized system can handle about 50,000 packets per second. Have not digged that deep into ntpd, But so far, I have not seen any trace of multithreading operation, so I assume that this is a single core doing the job. Processing a packet should not take more than 1 second / 50,000 = 20 us in the normal case. Then again, if you send 100s of thousands of packets per second to the server, this will cause the system to basically halt. I measured the server replies to less than 100 per second in this case. This could cause false replies, unless the H/W drops a packet which is queued past its launchtime. > Also, if you are only going to be a stratum 1 server, from where are you > going to get the actual time? If you are only going to use the > controller timestamps then the controller better be disciplined to some > source of time. Some how something needs to be setting the time on the > controller. I am not 100 % clear on how it is planned to be done. If it can be accomplished, then the 1 PPS pulse should be synchronized with UTC. Then you only have to set the seconds counter in SYSTIM. This can easily be done from any source. Wait until you get the 1 PPS interrupts and then check time. You have one second until seconds counter is updated again. You will be in unsynchronized state until that happens, so your timestamps are not to be trusted. > > Brian. -- Best Regards, Ulf Samuelsson _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
