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)
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
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 runn
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 viol
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, 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 o
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 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 p
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 "s
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 technic
10 matches
Mail list logo