On Wed, Jan 30, 2019 at 11:50:00AM +0100, Jiri Benc wrote:
> I don't see reason why linuxptp should put hacks in place to workaround
> broken hardware that knowingly violates the spec. I don't even see a
> reason why the standard should be changed to accommodate such hardware
> with no real
Le 30/01/2019 à 14:42, Miroslav Lichvar a écrit :
> On Wed, Jan 30, 2019 at 12:02:28PM +, FUSTE Emmanuel wrote:
>> Hello,
>>
>> When I lost communication with my grandmaster clock, my local ptp clock
>> is free running and becoming local grandmaster (the port is still slave
>> because of the
On Wed, Jan 30, 2019 at 12:02:28PM +, FUSTE Emmanuel wrote:
> Hello,
>
> When I lost communication with my grandmaster clock, my local ptp clock
> is free running and becoming local grandmaster (the port is still slave
> because of the "slaveOnly" option).
That doesn't sound right. If the
Hello,
When I lost communication with my grandmaster clock, my local ptp clock
is free running and becoming local grandmaster (the port is still slave
because of the "slaveOnly" option).
In this case, I would like phc2sys stop feeding the ntpshm to allow the
ntp daemon (chrony in this case) to
On Wed, Jan 30, 2019 at 11:23:45AM +, Vincent Li X wrote:
>
> Ok. Thanks Jiri!
> How do you think about our case? We run 1.6 on raw ethernet. This is a
> normal FOLLOW-UP received with one-zero padding of 6 octets. Then ptp4l take
> the padding as TLV.
One-zero padding sounds like beginning
Ok. Thanks Jiri!
How do you think about our case? We run 1.6 on raw ethernet. This is a
normal FOLLOW-UP received with one-zero padding of 6 octets. Then ptp4l take
the padding as TLV.
-Original Message-
From: Jiri Benc
Sent: Wednesday, January 30, 2019 11:50 AM
To: Miroslav Lichvar
On Wed, 30 Jan 2019 11:34:25 +0100, Miroslav Lichvar wrote:
> Are there other vendors than Qulsar that do this? If it's a common
> issue, it might need to be specified. IIRC there are few other cases
> where the spec had to be adjusted to follow what existing HW was doing.
The Qulsar hardware
On Wed, Jan 30, 2019 at 05:33:58AM +, Sun, Steven (NSB - CN/Qingdao) wrote:
> Vincent,
>
> We saw similar issue when co-work with Qulsar's PTP master clock. Qulsar
> master clock added 4 extra bytes after the PTP payload in UDP payload. Bad
> message error was reported by ptl4l which is
On Tue, Jan 29, 2019 at 08:07:49AM -0800, Richard Cochran wrote: > On Tue, Jan
29, 2019 at 10:00:37AM +0100, Miroslav Lichvar wrote:
> > Isn't that negligible when compared to the sync/announce traffic?
>
> Not to the master or to the network itself. I might have 1000 slaves
> renewing every 30
Hi Steven,
Do you run with latest release? I think the problem is ptp4l takes the
length as recvmsg() - carrierHeaderLen, instead of m->header. messageLength.
Or is it the drivers responsibility to remove padding before socket?
Thanks,
Vincent
From: Sun, Steven (NSB - CN/Qingdao)
10 matches
Mail list logo
