Paul Sobey wrote:
Gbit and low jitter is not quite compatible: 100 Mbit switches were
using cut-through, while (afaik) all Gbit and up switches use store &
forward, leading to higher latency and jitter.
There are several varieties of cut-through gig/10GB switch available now
- but noting that store and forward adds latency is a good point.
Presumably layer 3 switching (routing) is always store and forward since
we're effectively writing a new packet. It's all done in hardware though
- negligible jitter.
Negligible only in a statistical way, when running on a lightly loaded
network (close to zero collisions/arbitration for access to the same port)
You can use ntpd's internal numbers to verify the maximum possible
offset (half the round trip time), you should be able to use
statistics to show that the jitter is quite low as well.
At the risk of pushing my luck, can you expand on this?
NTPD statistics will easily give you an order of magnitude better
accuracy than that defined by half the RTT, so if you have ping times
well below 1 ms, you should get actual offsets in the dual-digit us range.
The best (and probably only possible) solution that does give you
single-digit us is to route a PPS signal to each and every server,
then use the network for approximate (~100 us) timing, with the PPS
doing the last two orders of magnitude.
Our problem will be that running coax around many sites to lots of
machines, many of which don't have serial ports (think blades), is both
highly time consuming and maintenance intensive. If we have to do it
then we will but I'd like a clear idea as to the whys before I start
down that particular path.
In particular at this stage I'm trying to understand more about the
theoretical accuracies obtainable under ideal conditions, and most
important, how to independently verify the results of any tweaks we
might apply. Say I have coalesence turned on a nic and I disable it -
That is just one of the things you _have_ to do in order to get rid of
jitter.
If you have ethernet cards that support hw time sync (I don't remember
the spec number), then you can indeed get low us over network links, but
that isn't ntp any longer, and you'll still have to replace the blade
infrastructure.
I'd like to be able to determine the effect, if any of that change. Is
it possible for ntpd (or ptpd) to accurately determine its own accuracy,
if that makes sense? If not what techniques might I use to independently
measure?
On a related note, I'm aware that there are various methods for querying
the system time, some of which involve a context switch, and some of
which can be done cheaply in userspace. I'm not sure whether the same is
A fast system time query will load the time as of the last hw clock
tick, along with the corresponding RDTSC (or similar, constant-rate
highres clock source), load the current RDTSC value, then re-read the OS
tick.
If the OS tick has been updated in the meantime, restart the process.
Finally, scale the RDTSC delta by the (OS-provided) frequency and add to
the tick time: The result is the current system time in ~100 clock
cycles, with sub-us precision.
true for setting the time. Is anyone aware of how much ntpd operation
involves context switches, which obviously would place quite a high
ceiling on accuracy since we're at the mercy of the OS scheduler?
NTP does not set the time, it just tells the OS how much the tick rate
should be tuned by, i.e. effectively how short/long each tick really is.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
