On 1/14/17 7:46 AM, Bob Camp wrote:
Hi
Ok, what I see is that every few hours, I get a “rogue delay” on a single ping.
How
would NTP help me spot a single transit with a 250 ms round trip and identify
the
time it occured? Keep in mind that NTP is going to throttle back to a very low
level
of “chat” quite quickly…..
While this *is* getting far more into my WiFi (which I had no real intention of
doing) it
does apply to timing and running audio over WiFi as well. The basic transport
as it
runs up through the various layers is *not* very good time wise. There is
indeed a
real need for some sort of overlay to take care of that issue. I’d still love
to know if
this magic protocol is simply giant buffers and some sort of tagging or if they
do
something more interesting.
This is the thing about the OSI stack and similar models.. It works ok
for some levels of conceptualization, but quickly breaks when you have
something at a top layer that needs information from a lower layer.
Consider something like adaptive data rate and adaptive routing with
links that come and go, but are to a certain extent predictable, but
require on the fly negotiation of rate. To make "intelligent" decisions
at the top layer, there needs to be a flow of management information
that goes up and down the stack, independent of the data flow.
This also arises when something that is notionally a communications link
gets used for something else (time transfer, ranging, etc.).
We face this all the time in spacecraft: back in the day, when 10 bps
is your basic rate, having narrow band receivers with very good close in
phase noise was part of the system. So using that same really pure
carrier to do ranging to centimeters was not that big a deal. Now, when
your comm link is running at 100 Mbps, maybe the 1 Hz out phase noise
isn't important.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
