Hi,
OK, I've decided to code up an "experiment" to quantify the behaviour that I might expect from protocols *like* PTP, NTP, etc. in an "uncontrolled" environment (i.e., I place *no* restrictions on the network fabric or topology).
It appears that I don't need much in the way of OS services to support the protocol. Just a crude timing service to drive the generation of requests (and a precise timing service within which to measure packet delivery times).
It appears that I need to either put some hooks into the stack to *guarantee* some minimal QoS (i.e., so the time protocol itself has some minimum guarantees on network availability) but those should be easy.
I plan to implement at least two different approaches for each protocol:
- protocol sits in user land *above* the network stack
- (parts of) protocol sits in the stack itself The latter will allow me to remove the latency and attendant jitter associated with the stack's performance.
For each of these, I plan on:
- using hardware timestamps
- ignoring hardware timestamps (i.e., just sample microtime) The latter will tell me what support for hardware timestamps is really *worth* (hardware and software costs).
The "audio client" (discussed else-thread) seems like a nice quick way of prototyping this as it is a trivial project and, by design, doesn't have the bloat of typical network implementations (because it is resource starved :> )
I *think* this will also give me a nice "hook" to measure the degree of synchronization and how that changes over time (i.e., by turning off the filtering loop in the protocols). E.g., play a "synchronized" tone through each client and measure phase differences. Variations in phase (i.e., protocol jitter) would manifest as short term FM.
OK so far?
Problem I foresee is coming up with a suitablly aggressive environment to stress the protocols! The obvious weakness is the switches. Keeping traffic backed up on specific (switch) ports should allow me to increase the delay
*through* that port to the "targeted" node that lies beyond. Likewise, *starving* traffic to other nodes will keep their latencies at a minimum.But, I would expect the protocols to easily adapt to any steady state condition like this (though assymetric Tx and Rx times -- possible on HDX *or* FDX -- might confound). Likewise, I would expect good behaviour in systems (NoW) with lots of entropy -- owing to the averaging characteristics of the protocols.
I guess I need to study the time constants involved to determine what the pathological case would be and then control the environment to synthesize that condition?
Yet another case where the testing effort far exceeds the design/coding effort! :<