[ntp:questions] Re: NTP clients not throttling back is this behaviour RFC compliant?

Terje Mathisen terje.mathisen at hda.hydro.com
Wed Dec 3 08:07:12 UTC 2003


Wolfgang S. Rupprecht wrote:

> "David L. Mills" <mills at udel.edu> writes:
> 
>>I just saw an advertisement where the maker of a NTP-in-a-box claimed
>>the server could handle 3000 packets per second, or about 1.2 MB/s just
>>for NTP. The mind boggles.
> 
> 
> It is amazing what you can do once you jettison all the baggage of
> thousands of instructions just to do one kernel call.
> 
> The question in my mind is would it be possible to do a wire-speed ntp
> server for 100base-TX or 1000base-T with a modern x86 motherboard?
> Cutting things down to the barest essentials, how many instructions
> would it take to unhook a packet from the RX queue, timestamp it, set
> the reference ID and stratum, swap the src/dst address (both ether and
> IP), reset the ttl and hook it into the TX queue.  I'm sure I'm
> forgetting something, but it is an interesting thought experiment.

This should be _easy_!

Novell's Netware had a fast path for 'File Read' requests that could 
take an incoming packet, parse it, verify the file handle, access rights 
etc, locate the data somewhere in cache, construct a reply packet, and 
hand that off to the network card again in just

   300 cycles

on a P6 (PentiumPro/PentiumII/PentiumIII) class machine.

This corresponded to being (theoretically) able to handle 1e6 packets 
per second on a 300 MHz state-of-the-past server.

Getting a time stamp is obviously _much_ less work, particularly as 
there's no real need to make any kernel calls at all if you handle NTP 
queries inside the kernel itself, close to the network stack.

If you don't want to do this, you should still be able to avoid kernel 
calls for the actual timestamping.

I.e. the timestamps would be handled with a user-level library function 
that uses the normal "extrapolate from the last timer tick using RDTSC 
or similar" approach.

Terje

-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list