[ntp:questions] Asymmetric Delay and NTP
magnus at rubidium.dyndns.org
Sat Mar 29 23:43:54 UTC 2014
On 24/03/14 14:38, Joe Gwinn wrote:
> In article <532FA47B.7060204 at rubidium.dyndns.org>, Magnus Danielson
> <magnus at rubidium.dyndns.org> wrote:
>> On 23/03/14 23:20, Joe Gwinn wrote:
>>> In article <532E45DB.5000902 at rubidium.dyndns.org>, Magnus Danielson
>>> <magnus at rubidium.dyndns.org> wrote:
>>>> On 21/03/14 17:04, Joe Gwinn wrote:
>>>>> It is interesting. I've now read it reasonably closely.
>>>>> The basic approach is to express each packet flight in a one-line
>>>>> equation (a row) in a linear-system matrix equation, where the system
>>>>> matrix (the A in the traditional y=Ax+b formulation, where b is zero in
>>>>> the absence of noise), where A is 4 columns wide by a variable number
>>>>> of rows long (one row to a packet flight), and show that one column of
>>>>> A can always be computed from the two other columns that describe who
>>>>> is added and subtracted from who. In other words, these three columns
>>>>> are linearly dependent on one another. The forth column contains
>>>>> measured data.
>>>>> This dependency means that A is always rank-deficient no matter how
>>>>> many packets (including infinity) and no matter the order, so the
>>>>> linear system cannot be solved.
>>>> It is just another formulation of the same equations I provided.
>>>> For each added link, one unknown and one measure is added.
>>>> For each added node, one unknown is added.
>>> True, but there is more.
>> Let's come back to that.
>>>> As you do more measures, you will add information about variations the
>>>> delays and time-differences between the nodes, but you will not disclose
>>>> the basic offsets.
>>> Also true. The advantage of the matrix formulation is that one can
>>> then appeal to the vast body of knowledge about matrixes and linear
>>> systems. It's not that one cannot prove it without the matrixes, it's
>>> that the proof is immediate with them - less work.
>>> And the issue was to prove that no such system could work.
>> As much as I like matrix formulation, it ain't giving you much more in
>> this case, rather than a handy notation. The trouble is that beyond the
>> properties of the noise, there is no information leakage about the
>> static time-errors and asymmetries. You end up having free variables.
> Yes. You correctly noted the mathematical equivalence of the two
> approaches, and I agree. My point was that the matrix approach is less
> work to get to the desired proof because by formulation as a linear
> solution with matrixes, one immediately inherits lots of properties and
>> The problem is that the unknown and the relationships builds up in an
>> uneven rate, and the observations only relate to two unknowns. The only
>> trustworthy fact we get is the sum of the delays, but no real hint about
>> its distribution. If you do more observations along the same paths, you
>> can do some statistics, but you won't get un-biased result without
>> adding a prior knowledge one way or another. Formulate it as you wish,
>> but as you add more observations, those will be reduced to by their
>> linear properties to equations existing and noise. You need to add
>> observations which does not fully reduce in order for your equation
>> system to grow to such size that you can solve it.
> Yes, this is a good statement of the consequences of the proof.
>> Show me how you achieve it, and I listen.
> I don't understand the challenge. There is no dispute.
It's not a personal challenge, it's a wide-spread challenge. If someone
worked something out I'm really keen to learn about it. I've spent quite
some time about figuring these things out as I need to understand them.
The *one* thing you can figure out with more measurements is how
non-zero-mean noise such as network traffic contribute to asymmetry.
You can do pretty good approximations of that contribution. However, if
there is an underlying asymmetry in static delay sources, they won't
disclose themselves with more measurements of the set measurements.
What you *can* do is bring a precise time to the first slave, measure
the time-error, compensate for it and then step-by-step calibrate a
path. The trouble is that you know adds the a prior assumption of stable
asymmetry, which may not be true. I've experienced it not to be true.
>>>> It is only "by cheating" that you can overcome the limits of the system.
>>> Is GPS cheating? That's our usual answer, but GPS isn't always
>>> available or possible.
>> If you are trying to solve it within a network, it is. You can convert
>> your additional GPS observation into an a prior knowledge, and once you
>> done enough of those, then you can solve it completely. The estimated
>> variables better stay static thought, or you have to start over again.
> GPS is the usual answer, but isn't always available or useful.
I know, I know.
> Recall that the original question was random asymmetry due to
> asymmetric background traffic in a PTP network. If the network is
> controllable, a lab experiment is to simply turn the background traffic
> off and see how much the clocks change with respect to one another.
> But this tells one how much trouble one is in, but does not solve the
> problem. The solution will be found in better choice of hardware, and
> better top-level design.
If you look closely to the traffic, you can use statistical tools to
remove much of the noise of the traffic, but it's an approximation and
comes at the cost of high traffic loads. That way you can reduce the
impact of traffic load impairment to asymmetry. Works really well.
> The PTP field has not yet achieved maturity, and we will be the
Well, some of it have already been addressed in NTP, some in PTP and
some in other systems.
More information about the questions