On Tue, Feb 18, 2014 at 07:08:41PM +0100, Delio Brignoli wrote:
>
> I also assumed the peer delay had to be non-negative to be meaningful.
> Would you be OK with a patch that introduced a minimum acceptable peer
> delay configuration option?
I think even for gPTP, the measured mean peer propagat
On 19 Feb 2014, at 09:50, Richard Cochran wrote:
> On Tue, Feb 18, 2014 at 07:08:41PM +0100, Delio Brignoli wrote:
>>
>> I also assumed the peer delay had to be non-negative to be meaningful.
>> Would you be OK with a patch that introduced a minimum acceptable peer
>> delay configuration option?
On Wed, Feb 19, 2014 8:27 AM Richard Cochran wrote:
> On Wed, Feb 19, 2014 at 12:38:59AM +0100, Holzinger, Axel (ALC
> NetworX GmbH) wrote:
> >
> > So this means using the UDS Interface I guess. But does it
> > really make sense to use UDS for reading a precise time.
> > Is it fast enough?
>
> No
On Wed, Feb 19, 2014 at 10:40:11AM +0100, Delio Brignoli wrote:
>
> Preventing the port from being labelled asCapable and avoid calculating
> neighborRateRatio is exactly what I want to do. I am working with specs
> layered on top of 802.1AS-2011 which require me to flag a port as
> non-asCapable
Hello Richard,
On 19 Feb 2014, at 12:23, Richard Cochran wrote:
> On Wed, Feb 19, 2014 at 10:40:11AM +0100, Delio Brignoli wrote:
>>
>> Preventing the port from being labelled asCapable and avoid calculating
>> neighborRateRatio is exactly what I want to do. I am working with specs
>> layered on
On Wed, Feb 19, 2014 at 12:44:28PM +0100, Delio Brignoli wrote:
>
> I spent some time yesterday reading the relevant bits of the 802.1AS standard
> and I agree with you: the gPTP standard does not forbid negative peer delay.
> In fact, as long as neighborRateRatio can be calculated (i.e.
> neighbo
