1. For MTIE analysis G.8275.

1 mask for time and phase

delivery which is much more difficult to meet.
2. Test cases 1 - 6 all have similar results in terms of MTIE. The
reason is that there is no variable delay. All them exhibit a fixed
frequency offset of around 1 ppb for short observation windows
that saturates for larger observation windows. This saturation
value is larger when the fixed delay is very large. I do not have
a clear explanation for this effect but it is most probably caused
by Net.Storm. The impairment generator is asynchronous and
this fact could be more noticeable when it has to store packets
for longer periods of time as it happens when the delay is
configured to be in the range of milliseconds.
3. Test cases 7 - 9 represent uniformly distributed delay in the
forward or backward paths or in both at the same time. As
expected, MTIE is larger if there is variable delay in the
network. It is seen that a few tens of microseconds are enough
to generate a FAIL result. That means that any network
operator willing to deliver time over PTP has to control carefully
delay variation. There is a remarkable point: delay variation in
the backward path does not affect the MTIE result. We compute
MTIE only in the Sync packets and these go from the GM to the
slave only.
4. Test cases 10 - 12 are similar to cases 7 - 9 but with much
higher delay variations. I have not generated the MTIE graphics
for cases 10 and 12 because it is too large to have any
meaning. Test case 11 shows again that variable delay in the
backward path does not have any effect in the MTIE result. This
is a quite unnatural situation however.