linuxptp-users — Open discussion on using the linuxptp software.

[Linuxptp-users] IEEE802.1AS support?

[Eliot B. <ebl...@au...>]

Greetings,

Seeing the commit of raw ethernet transport, I wonder if there are any
plans to support 802.1AS (aka gPTP)?

Section 7.5 of the standard[1] covers differences between gPTP and PTP

Very basic ways that gPTP is different from PTP
* layer 2 only, PTPv2 only
* only uses the peer to peer multicast address
* 4-bit transportSpecific field in PTP header is 0x1
* most other differences are ways in which gPTP is a subset of PTP


(Aside: I followed the links from http://linuxptp.sourceforge.net/ to
linuxptp-devel archives, but they appear to be empty - is that mailing
list active, or is this list being used instead?)

regards

-- 
Eliot Blennerhassett
AudioScience Inc.

[1] http://standards.ieee.org/getieee802/download/802.1AS-2011.pdf

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Takahiro S. <tsh...@gm...>]

>
> > > BTW David Miller already applied your first driver patches. So, you
> > > should submit any changes as patches on top of that.
> > >
> > >
> > I see. I will send the new patch in V.3.4-rc? window.
>
> I would send them ASAP.
>
> Since the patches will be bug fixes, I think David Miller will apply
> them any time from now until the last v3.4-rc.
>
>
OK. I got the next-linux (next-20120314) from git.
It includes ptp_pch and modified pch_gbe.
I will make the patch using  it and send it soon.

Thanks,
Takahiro Shimizu

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Richard C. <ric...@gm...>]

On Thu, Mar 15, 2012 at 04:00:09PM +0900, Takahiro Shimizu wrote:
> > BTW David Miller already applied your first driver patches. So, you
> > should submit any changes as patches on top of that.
> >
> >
> I see. I will send the new patch in V.3.4-rc? window.

I would send them ASAP.

Since the patches will be bug fixes, I think David Miller will apply
them any time from now until the last v3.4-rc.

Thanks,
Richard

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Takahiro S. <tsh...@gm...>]

Hello,


Yes, I agree. This makes sense as a workaround for testing.
> But I think we should do the following to be correct.
>
> driver:
>
>  switch (rx_filter) {
>  case HWTSTAMP_FILTER_PTP_V2_EVENT:
>      return ERANGE;
>  case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
>      SA = 01:00:5e:00:01:81;
>  case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
>      SA = 01:1b:19:00:00:00;
>  }
>
>
I see. I will do like the above in the next patch.


>  Also, the driver's Kconfig needs a statment that the hardware only
>  supports the end-to-end mechanism and that the peer-to-peer
>  mechanism is not supported.
>
>
OK.


> ptp4l:
>
>  try (HWTSTAMP_FILTER_PTP_V2_EVENT);
>  if (errno == ERANGE) {
>      if (transport_is_L2)
>          try (HWTSTAMP_FILTER_PTP_V2_L2_EVENT);
>      else
>          try (HWTSTAMP_FILTER_PTP_V2_L4_EVENT);
>  }
>
>
Thank you very much.


> I will work on the ptp4l code. Can you please fix the driver?
>
> BTW David Miller already applied your first driver patches. So, you
> should submit any changes as patches on top of that.
>
>
I see. I will send the new patch in V.3.4-rc? window.

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Richard C. <ric...@gm...>]

On Thu, Mar 15, 2012 at 08:48:10AM +0900, Takahiro Shimizu wrote:
> HWTSTAMP_FILTER_PTP_V2_L4_EVENT  SA = 01:00:5e:00:01:81 (E2E mechanism only)
> HWTSTAMP_FILTER_PTP_V2_L2_EVENT  SA = 01:1b:19:00:00:00 (E2E mechanism only)
> HWTSTAMP_FILTER_PTP_V2_EVENT     The same as HWTSTAMP_FILTER_PTP_V2_L4_EVENT
> 
> I want that the user uses linuptp and EG20T driver by default.
> It seems that the current linuxptp does not use SA = 01:1b:19:00:00:00 by
> default.
> If so, I want to implement like the above.
> It is the limitation of the EG20T ptp driver.

Yes, I agree. This makes sense as a workaround for testing.
But I think we should do the following to be correct.

driver:

  switch (rx_filter) {
  case HWTSTAMP_FILTER_PTP_V2_EVENT:
      return ERANGE;
  case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
      SA = 01:00:5e:00:01:81;
  case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
      SA = 01:1b:19:00:00:00;
  }

  Also, the driver's Kconfig needs a statment that the hardware only
  supports the end-to-end mechanism and that the peer-to-peer
  mechanism is not supported.

ptp4l:

  try (HWTSTAMP_FILTER_PTP_V2_EVENT);
  if (errno == ERANGE) {
      if (transport_is_L2)
          try (HWTSTAMP_FILTER_PTP_V2_L2_EVENT);
      else
          try (HWTSTAMP_FILTER_PTP_V2_L4_EVENT);
  }

I will work on the ptp4l code. Can you please fix the driver?

BTW David Miller already applied your first driver patches. So, you
should submit any changes as patches on top of that.

Thanks,
Richard

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Takahiro S. <tsh...@gm...>]

Hello,

> Yes, I agree. You will have to live with a work around. Your hardware
> > > really cannot support IEEE Std 1588-2008. For peer delay mechanism via
> > > L2, you must accept two *different* MAC addresses.
> > >
> > > Your driver will have to program the correct multicast MAC address
> > > based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain
> > > values for rx_filter:
> > >
> > >  HWTSTAMP_FILTER_PTP_V2_L4_EVENT  SA = 01:00:5e:00:01:81 (E2E mechanism
> > > only)
> > >  HWTSTAMP_FILTER_PTP_V2_L2_EVENT  SA = 01:1b:19:00:00:00 (E2E mechanism
> > > only)
> > >  HWTSTAMP_FILTER_PTP_V2_EVENT     not supported!
> > >
> > >
> > I have some question.
> > 1. If SA means Distination MAC address (Station Address register 1-6),
> > could you tell me the usage of the above ioctl?
>
> Sorry for the confusion. I meant SA = Station Address.
>
> > Now linuxptp uses HWTSTAMP_FILTER_PTP_V2_EVENT. If I implement the driver
> > like the above, I modify the linuxptp using
> HWTSTAMP_FILTER_PTP_V2_L4_EVENT
> > or HWTSTAMP_FILTER_PTP_V2_L2_EVENT and test them?
>
> Yes that is right.
>
> > I can accept two *different * Source MAC address for Rx message. I can
> not
> > accept two *different* Destination MAC address for RX message.
>
> Yes, and that is why the hardware will not fully support PTPv2.
>
> How about the following implementation?

HWTSTAMP_FILTER_PTP_V2_L4_EVENT  SA = 01:00:5e:00:01:81 (E2E mechanism only)
HWTSTAMP_FILTER_PTP_V2_L2_EVENT  SA = 01:1b:19:00:00:00 (E2E mechanism only)
HWTSTAMP_FILTER_PTP_V2_EVENT     The same as HWTSTAMP_FILTER_PTP_V2_L4_EVENT

I want that the user uses linuptp and EG20T driver by default.
It seems that the current linuxptp does not use SA = 01:1b:19:00:00:00 by
default.
If so, I want to implement like the above.
It is the limitation of the EG20T ptp driver.

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Richard C. <ric...@gm...>]

On Wed, Mar 14, 2012 at 07:26:42PM +0900, Takahiro Shimizu wrote:
> Hello,
> 
> I get IEEE1588-2008 specification.
> My understanding about your saying is;
> 1. "HWTSTAMP_FILTER_PTP_V2_L4_EVENT  SA = 01:00:5e:00:01:81" means
> "PTP-primary All except peer delay mechanism messages 224.0.1.129" in Table
> D.1 IPv4 multicast addresses in the standard.

Yes.

> 2. "HWTSTAMP_FILTER_PTP_V2_L2_EVENT  SA = 01:1b:19:00:00:00" means "All
> except peer delay mechanism messages 01-1B-19-00-00-00" in Table F.1
> Multicast MAC addresses in the standard.

Yes.

> 3. HWTSTAMP_FILTER_PTP_V2_EVENT means supports L2 event and L4 event at the
> same time. This means we should support both addresses in Table D.1 or F.1
> at the same time.

Yes.

> 4. "How can you support the peer delay mechanism?" means we should support
> "PTP-primary All except peer delay mechanism messages 224.0.1.129" and
> "PTP-pdelay Peer delay mechanism messages 224.0.0.107" or "All except peer
> delay mechanism messages 01-1B-19-00-00-00" and "Peer delay mechanism
> messages 01-80-C2-00-00-0E".
> Is my understanding correct?

Yes, that is correct.

In order to support the peer-to-peer (P2P) mechanism, you need to
accept Ethernet packets with two different destination MAC addresses.

The ptp4l does not yet implement P2P, but I will add this eventually.

Richard

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Richard C. <ric...@gm...>]

On Wed, Mar 14, 2012 at 05:26:18PM +0900, Takahiro Shimizu wrote:
> Yes, I agree. You will have to live with a work around. Your hardware
> > really cannot support IEEE Std 1588-2008. For peer delay mechanism via
> > L2, you must accept two *different* MAC addresses.
> >
> > Your driver will have to program the correct multicast MAC address
> > based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain
> > values for rx_filter:
> >
> >  HWTSTAMP_FILTER_PTP_V2_L4_EVENT  SA = 01:00:5e:00:01:81 (E2E mechanism
> > only)
> >  HWTSTAMP_FILTER_PTP_V2_L2_EVENT  SA = 01:1b:19:00:00:00 (E2E mechanism
> > only)
> >  HWTSTAMP_FILTER_PTP_V2_EVENT     not supported!
> >
> >
> I have some question.
> 1. If SA means Distination MAC address (Station Address register 1-6),
> could you tell me the usage of the above ioctl?

Sorry for the confusion. I meant SA = Station Address.

> Now linuxptp uses HWTSTAMP_FILTER_PTP_V2_EVENT. If I implement the driver
> like the above, I modify the linuxptp using HWTSTAMP_FILTER_PTP_V2_L4_EVENT
> or HWTSTAMP_FILTER_PTP_V2_L2_EVENT and test them?

Yes that is right.

> I can accept two *different * Source MAC address for Rx message. I can not
> accept two *different* Destination MAC address for RX message.

Yes, and that is why the hardware will not fully support PTPv2.

Richard

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Takahiro S. <tsh...@gm...>]

Hello,

I get IEEE1588-2008 specification.
My understanding about your saying is;
1. "HWTSTAMP_FILTER_PTP_V2_L4_EVENT  SA = 01:00:5e:00:01:81" means
"PTP-primary All except peer delay mechanism messages 224.0.1.129" in Table
D.1 IPv4 multicast addresses in the standard.
2. "HWTSTAMP_FILTER_PTP_V2_L2_EVENT  SA = 01:1b:19:00:00:00" means "All
except peer delay mechanism messages 01-1B-19-00-00-00" in Table F.1
Multicast MAC addresses in the standard.
3. HWTSTAMP_FILTER_PTP_V2_EVENT means supports L2 event and L4 event at the
same time. This means we should support both addresses in Table D.1 or F.1
at the same time.
4. "How can you support the peer delay mechanism?" means we should support
"PTP-primary All except peer delay mechanism messages 224.0.1.129" and
"PTP-pdelay Peer delay mechanism messages 224.0.0.107" or "All except peer
delay mechanism messages 01-1B-19-00-00-00" and "Peer delay mechanism
messages 01-80-C2-00-00-0E".
Is my understanding correct?

Thanks,
Takahiro Shimizu
2012/3/14 Takahiro Shimizu <tsh...@gm...>

> Hello,
>
> Thank you very much for the response.
>
> Yes, I agree. You will have to live with a work around. Your hardware
>> really cannot support IEEE Std 1588-2008. For peer delay mechanism via
>> L2, you must accept two *different* MAC addresses.
>>
>> Your driver will have to program the correct multicast MAC address
>> based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain
>> values for rx_filter:
>>
>>  HWTSTAMP_FILTER_PTP_V2_L4_EVENT  SA = 01:00:5e:00:01:81 (E2E mechanism
>> only)
>>  HWTSTAMP_FILTER_PTP_V2_L2_EVENT  SA = 01:1b:19:00:00:00 (E2E mechanism
>> only)
>>  HWTSTAMP_FILTER_PTP_V2_EVENT     not supported!
>>
>>
> I have some question.
> 1. If SA means Distination MAC address (Station Address register 1-6),
> could you tell me the usage of the above ioctl?
> Now linuxptp uses HWTSTAMP_FILTER_PTP_V2_EVENT. If I implement the driver
> like the above, I modify the linuxptp using HWTSTAMP_FILTER_PTP_V2_L4_EVENT
> or HWTSTAMP_FILTER_PTP_V2_L2_EVENT and test them?
> 2. Or you mean that SA is source address?
> If so, my hardware does not filter about source address.
> It filter only Destination address using Station Address registers1-6.
> I can accept two *different * Source MAC address for Rx message. I can not
> accept two *different* Destination MAC address for RX message.
>
> Thanks and Best regards,
> Takahiro Shimizu
>

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Takahiro S. <tsh...@gm...>]

Hello,

Thank you very much for the response.

Yes, I agree. You will have to live with a work around. Your hardware
> really cannot support IEEE Std 1588-2008. For peer delay mechanism via
> L2, you must accept two *different* MAC addresses.
>
> Your driver will have to program the correct multicast MAC address
> based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain
> values for rx_filter:
>
>  HWTSTAMP_FILTER_PTP_V2_L4_EVENT  SA = 01:00:5e:00:01:81 (E2E mechanism
> only)
>  HWTSTAMP_FILTER_PTP_V2_L2_EVENT  SA = 01:1b:19:00:00:00 (E2E mechanism
> only)
>  HWTSTAMP_FILTER_PTP_V2_EVENT     not supported!
>
>
I have some question.
1. If SA means Distination MAC address (Station Address register 1-6),
could you tell me the usage of the above ioctl?
Now linuxptp uses HWTSTAMP_FILTER_PTP_V2_EVENT. If I implement the driver
like the above, I modify the linuxptp using HWTSTAMP_FILTER_PTP_V2_L4_EVENT
or HWTSTAMP_FILTER_PTP_V2_L2_EVENT and test them?
2. Or you mean that SA is source address?
If so, my hardware does not filter about source address.
It filter only Destination address using Station Address registers1-6.
I can accept two *different * Source MAC address for Rx message. I can not
accept two *different* Destination MAC address for RX message.

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Richard C. <ric...@gm...>]

On Wed, Mar 14, 2012 at 01:51:35PM +0900, Takahiro Shimizu wrote:
> Hello
> 
> I confirmed it to the engineer.
> It seems the mistake of EG20T datasheet.
> Destination MAC address is compared with station address registers.

Wow, your hardware really, really stinks.

How then can you support IPv4 on one port and L2 on another?

How can you support the peer delay mechanism?

> I will use the same station address as linuxptp in EG20T ptp driver like
> below.
> 
> #define DEFAULT_MULTICAST_MAC_ADDR "01:00:5e:00:01:81" // This is the same
> as "224.0.1.129".
> 
> pch_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> :
> pch_set_station_address(DEFAULT_MULTICAST_MAC_ADDR, pdev);
> 
> I think this is simple and good way now.

Yes, I agree. You will have to live with a work around. Your hardware
really cannot support IEEE Std 1588-2008. For peer delay mechanism via
L2, you must accept two *different* MAC addresses.

Your driver will have to program the correct multicast MAC address
based on the SIOCSHWTSTAMP ioctl. Your driver can only support certain
values for rx_filter:

 HWTSTAMP_FILTER_PTP_V2_L4_EVENT  SA = 01:00:5e:00:01:81 (E2E mechanism only)
 HWTSTAMP_FILTER_PTP_V2_L2_EVENT  SA = 01:1b:19:00:00:00 (E2E mechanism only)
 HWTSTAMP_FILTER_PTP_V2_EVENT	  not supported!

Sorry,

Richard

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Takahiro S. <tsh...@gm...>]

Hello

I confirmed it to the engineer.
It seems the mistake of EG20T datasheet.
Destination MAC address is compared with station address registers.

However there are no interface between linuxptp and ptp driver.
I will use another solution.

I will use the same station address as linuxptp in EG20T ptp driver like
below.

#define DEFAULT_MULTICAST_MAC_ADDR "01:00:5e:00:01:81" // This is the same
as "224.0.1.129".

pch_probe(struct pci_dev *pdev, const struct pci_device_id *id)
:
pch_set_station_address(DEFAULT_MULTICAST_MAC_ADDR, pdev);

I think this is simple and good way now.

Thanks and Best regards,
Takahiro Shimizu

2012/3/14 Takahiro Shimizu <tsh...@gm...>

> Hello,
>
> Thank you for the response.
>
> However, if I set the station address as 0, I can not get the timestamp...
> I will ask it to the EG20T hardware engineer.
>
> Thanks and Best regards,
> Takahiro Shimizu
>
> 2012/3/13 Richard Cochran <ric...@gm...>
>
>> On Tue, Mar 13, 2012 at 04:27:54PM +0900, Takahiro Shimizu wrote:
>> > EG20T ieee1588 hardware needs destination MAC address to capture the ptp
>> > message.
>> > I implement it in ptp_pch_probe function now.
>> > The usage is like below:
>> > insmod ptp_pch.ko station="01:00:5e:00:01:81"
>> > This is good if the MAC address is unicast. Because it is known already.
>> > However it is NG if the MAC address is multicast. Because it is decided
>> > when the linuxptp is started.
>>
>> Why do you need to set the station address?
>>
>> According to the EG20T Datasheet (Intel 3242111-006US), the station
>> address fields are not used. In Table 617, page 523, "PTP Frame
>> Identification", the MAC addresses are not used at all.
>>
>> Just leave the station address registers as zero.
>>
>> > So, I want to add the new command between ptp driver and linuxptp.
>> > One possibility is to define the new ioctl of socket interface.
>> > However it needs to change gbe, ptp driver and linuxptp.
>> > Another possibility is to use the interface between ptp driver and
>> linuxptp.
>> > It seems simple.
>> > However I can not see any direct interface between ptp driver and
>> linuxptp.
>> >
>> > Question:
>> > 1. Which is better to add the new command for ptp driver?
>> > 2. Is it possible to add new interface between ptp driver and linuxptp
>> > (e.g. ioctl)?
>> > 3. Does anyone have other better idea?
>>
>> I don't see any need for such an interface.
>>
>> Richard
>>
>
>

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Takahiro S. <tsh...@gm...>]

Hello,

Thank you for the response.

However, if I set the station address as 0, I can not get the timestamp...
I will ask it to the EG20T hardware engineer.

Thanks and Best regards,
Takahiro Shimizu

2012/3/13 Richard Cochran <ric...@gm...>

> On Tue, Mar 13, 2012 at 04:27:54PM +0900, Takahiro Shimizu wrote:
> > EG20T ieee1588 hardware needs destination MAC address to capture the ptp
> > message.
> > I implement it in ptp_pch_probe function now.
> > The usage is like below:
> > insmod ptp_pch.ko station="01:00:5e:00:01:81"
> > This is good if the MAC address is unicast. Because it is known already.
> > However it is NG if the MAC address is multicast. Because it is decided
> > when the linuxptp is started.
>
> Why do you need to set the station address?
>
> According to the EG20T Datasheet (Intel 3242111-006US), the station
> address fields are not used. In Table 617, page 523, "PTP Frame
> Identification", the MAC addresses are not used at all.
>
> Just leave the station address registers as zero.
>
> > So, I want to add the new command between ptp driver and linuxptp.
> > One possibility is to define the new ioctl of socket interface.
> > However it needs to change gbe, ptp driver and linuxptp.
> > Another possibility is to use the interface between ptp driver and
> linuxptp.
> > It seems simple.
> > However I can not see any direct interface between ptp driver and
> linuxptp.
> >
> > Question:
> > 1. Which is better to add the new command for ptp driver?
> > 2. Is it possible to add new interface between ptp driver and linuxptp
> > (e.g. ioctl)?
> > 3. Does anyone have other better idea?
>
> I don't see any need for such an interface.
>
> Richard
>

Re: [Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Richard C. <ric...@gm...>]

On Tue, Mar 13, 2012 at 04:27:54PM +0900, Takahiro Shimizu wrote:
> EG20T ieee1588 hardware needs destination MAC address to capture the ptp
> message.
> I implement it in ptp_pch_probe function now.
> The usage is like below:
> insmod ptp_pch.ko station="01:00:5e:00:01:81"
> This is good if the MAC address is unicast. Because it is known already.
> However it is NG if the MAC address is multicast. Because it is decided
> when the linuxptp is started.

Why do you need to set the station address?

According to the EG20T Datasheet (Intel 3242111-006US), the station
address fields are not used. In Table 617, page 523, "PTP Frame
Identification", the MAC addresses are not used at all.

Just leave the station address registers as zero.

> So, I want to add the new command between ptp driver and linuxptp.
> One possibility is to define the new ioctl of socket interface.
> However it needs to change gbe, ptp driver and linuxptp.
> Another possibility is to use the interface between ptp driver and linuxptp.
> It seems simple.
> However I can not see any direct interface between ptp driver and linuxptp.
> 
> Question:
> 1. Which is better to add the new command for ptp driver?
> 2. Is it possible to add new interface between ptp driver and linuxptp
> (e.g. ioctl)?
> 3. Does anyone have other better idea?

I don't see any need for such an interface.

Richard

[Linuxptp-users] Is there any interface between ptp driver and linuxptp for controlling the ptp hardware?

[Takahiro S. <tsh...@gm...>]

Hello,

I am using ptp4l with hardware clock.
The ieee1588 hardware is Intel EG20T.

EG20T ieee1588 hardware needs destination MAC address to capture the ptp
message.
I implement it in ptp_pch_probe function now.
The usage is like below:
insmod ptp_pch.ko station="01:00:5e:00:01:81"
This is good if the MAC address is unicast. Because it is known already.
However it is NG if the MAC address is multicast. Because it is decided
when the linuxptp is started.

So, I want to add the new command between ptp driver and linuxptp.
One possibility is to define the new ioctl of socket interface.
However it needs to change gbe, ptp driver and linuxptp.
Another possibility is to use the interface between ptp driver and linuxptp.
It seems simple.
However I can not see any direct interface between ptp driver and linuxptp.

Question:
1. Which is better to add the new command for ptp driver?
2. Is it possible to add new interface between ptp driver and linuxptp
(e.g. ioctl)?
3. Does anyone have other better idea?

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] ptp4l stop with ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES message.

[Takahiro S. <tsh...@gm...>]

Hello,


>
> You have a hardware (or driver) bug.
>
>
Yes. I had a bug in a EG20T GbE driver and it was resolved now.
Now I can sync even if there are many data copying.

Thank you very much.
Takahiro Shimizu

Re: [Linuxptp-users] ptp4l stop with ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES message.

[Takahiro S. <tsh...@gm...>]

Hello,

The issue was resolved.
The issue was in EG20T GbE driver.
Now I can sync even if there are many data copying.

Thanks and Best regards,
2012/3/13 Takahiro Shimizu <tsh...@gm...>

> Hello,
>
> Yes, EG20T MAC drops UDP multicast in the situation. I think linuxptp
> seems starting with promiscuous mode and leaves the promiscuous mode in the
> situation.
>
> However I can not see the any code about promiscuous mode in the linuxptp
>> source code.
>>
>> I want that linuxptp re-start automatically getting new announce message
>> after ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES.
>>
>>
> I found the issue in EG20T GbE driver. It does not support
> set_multicast_list. Therefore EG20T GbE driver did not get multicast
> message without promiscuous mode.
> I am implementing the feature now.
> After that I will try the test again.
>
> Thank you for the advice.
>
> Thanks and Best regards,
> Takahiro Shimizu
>

Re: [Linuxptp-users] ptp4l stop with ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES message.

[Richard C. <ric...@gm...>]

On Tue, Mar 13, 2012 at 08:58:36AM +0900, Takahiro Shimizu wrote:
> > Wireshark places the MAC into promiscuous mode. Maybe your MAC is
> > dropping UDP multicasts?
> >
> >
> Yes, EG20T MAC drops UDP multicast in the situation. I think linuxptp seems
> starting with promiscuous mode and leaves the promiscuous mode in the
> situation.
> However I can not see the any code about promiscuous mode in the linuxptp
> source code.

The ptp4l program calls setsockopt(IP_ADD_MEMBERSHIP), and this makes
the networking stack do what it needs to (eg. set the multicast
filter) in order to make it happen at the Ethernet level.

> I want that linuxptp re-start automatically getting new announce message
> after ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES.

Well, if the master stops transmitting, then there is nothing linuxptp
can do about it.

You have a hardware (or driver) bug.

Richard

Re: [Linuxptp-users] ptp4l stop with ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES message.

[Takahiro S. <tsh...@gm...>]

Hello,

Yes, EG20T MAC drops UDP multicast in the situation. I think linuxptp seems
starting with promiscuous mode and leaves the promiscuous mode in the
situation.

However I can not see the any code about promiscuous mode in the linuxptp
> source code.
>
> I want that linuxptp re-start automatically getting new announce message
> after ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES.
>
>
I found the issue in EG20T GbE driver. It does not support
set_multicast_list. Therefore EG20T GbE driver did not get multicast
message without promiscuous mode.
I am implementing the feature now.
After that I will try the test again.

Thank you for the advice.

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] ptp4l stop with ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES message.

[Takahiro S. <tsh...@gm...>]

Hello,

> ptp4l[4305]: port 1: bad message
>
> Here you have a problem. Your hardware (or driver) is dropping time
> stamps. You need to fix this.
>
>
I understand. EG20T GbE hardware drop the packet automatically if the
RxFIFO is overflowed.
So this is happened in high load condition.


> > ptp4l[4305]: port 1: SLAVE to LISTENING on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
>
> This means that no announce message from the master clock arrived
> within the expected time.
>
>
I see.


> > port_set_announce_tmo is called infintely.
>
> This is normal. This should only happen once every
>
>   announceReceiptTimeout * 2^logAnnounceInterval
>
> seconds.
>
> For some reason, the ptp4l program is not receiving any more announce
> messages.
>
>
OK. I think the same.


> > This continues after stopping data copy.
> >
> > However, if I start Wireshark to see the packet exchange, ptp4l re-start
> > the sync.
>
> Wireshark places the MAC into promiscuous mode. Maybe your MAC is
> dropping UDP multicasts?
>
>
Yes, EG20T MAC drops UDP multicast in the situation. I think linuxptp seems
starting with promiscuous mode and leaves the promiscuous mode in the
situation.
However I can not see the any code about promiscuous mode in the linuxptp
source code.

I want that linuxptp re-start automatically getting new announce message
after ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES.

Thanks,
Takahiro Shimizu

Re: [Linuxptp-users] ptp4l stop with ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES message.

[Richard C. <ric...@gm...>]

On Mon, Mar 12, 2012 at 07:37:51PM +0900, Takahiro Shimizu wrote:
> Hello,
> 
> I am using ptp4l with hardware clock.
> The ieee1588 hardware is Intel EG20T.
> The sync is fine.
> However ptp4l stop sometimes when we copy many data like following.
> 
> I connect 2 CrownBay(Intel E6xx CPU + Intel PCH EG20T) boards and 1 PC in
> the same network.
> I installed Linux kernel 3.3-rc6 on 2 CrownBays.
> I installed Windows 7 on PC.
> CrownBay-1 is a PTP master.
> CrownBay-2 is a PTP slave.
> Samba server is running on the CrownBay-2.
> The ptp4l is running on the both CrownBay.
> I mount the directory of CrownBay-2 on PC.
> I copied many files between PC and CrwonBay-2 when I am running ptp4l.

So you generate a lot of non-PTP traffic. In theory, this should not
affect the operation of the PHC hardware, PHC driver, or PTP stack.

> 
> The ptp4l log is as follows:
> 
> :
> ptp4l[4305]: master offset       -502 s2 adj  -10566 path delay       3062
> ptp4l[4305]: received SYNC without timestamp
> ptp4l[4305]: port 1: bad message
> ptp4l[4305]: received SYNC without timestamp
> ptp4l[4305]: port 1: bad message

Here you have a problem. Your hardware (or driver) is dropping time
stamps. You need to fix this.

> ptp4l[4305]: port 1: SLAVE to LISTENING on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

This means that no announce message from the master clock arrived
within the expected time.

> :
> :
> 
> I put debug message to see what is happened after
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES.
> 
> :
> ptp4l[4305]: port 1: SLAVE to LISTENING on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[4305]: port_set_announce_tmo
> ptp4l[4305]: port_set_announce_tmo
> 
> port_set_announce_tmo is called infintely.

This is normal. This should only happen once every

   announceReceiptTimeout * 2^logAnnounceInterval

seconds.

For some reason, the ptp4l program is not receiving any more announce
messages.

> This continues after stopping data copy.
> 
> However, if I start Wireshark to see the packet exchange, ptp4l re-start
> the sync.

Wireshark places the MAC into promiscuous mode. Maybe your MAC is
dropping UDP multicasts?

HTH,
Richard

[Linuxptp-users] ptp4l stop with ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES message.

[Takahiro S. <tsh...@gm...>]

Hello,

I am using ptp4l with hardware clock.
The ieee1588 hardware is Intel EG20T.
The sync is fine.
However ptp4l stop sometimes when we copy many data like following.

I connect 2 CrownBay(Intel E6xx CPU + Intel PCH EG20T) boards and 1 PC in
the same network.
I installed Linux kernel 3.3-rc6 on 2 CrownBays.
I installed Windows 7 on PC.
CrownBay-1 is a PTP master.
CrownBay-2 is a PTP slave.
Samba server is running on the CrownBay-2.
The ptp4l is running on the both CrownBay.
I mount the directory of CrownBay-2 on PC.
I copied many files between PC and CrwonBay-2 when I am running ptp4l.

The ptp4l log is as follows:

:
ptp4l[4305]: master offset       -502 s2 adj  -10566 path delay       3062
ptp4l[4305]: received SYNC without timestamp
ptp4l[4305]: port 1: bad message
ptp4l[4305]: received SYNC without timestamp
ptp4l[4305]: port 1: bad message
ptp4l[4305]: port 1: SLAVE to LISTENING on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
:
:

I put debug message to see what is happened after
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES.

:
ptp4l[4305]: port 1: SLAVE to LISTENING on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[4305]: port_set_announce_tmo
ptp4l[4305]: port_set_announce_tmo

port_set_announce_tmo is called infintely.

This continues after stopping data copy.

However, if I start Wireshark to see the packet exchange, ptp4l re-start
the sync.

Did anyone face the similar issue?

Thanks and Best regards,
Takahiro Shimizu

Re: [Linuxptp-users] master offset is increased in some condition

[Takahiro S. <tsh...@gm...>]

Hello Richard,


Yes, you are right, for 32 bit machines.
>
> The problem is that the PHC driver API has the max_adj in ppb, but the
> NTP adjtime API has the frequency adjustment field as ppm with a 16
> bit fractional part.
>
> In the PHC driver API the field is four bytes (type s32), but in the
> NTP adjtime API the field is either four or eight bytes (type long),
> depending on the machine architecture.
>
>
OK. I understand.


> > If I chage the EG20T ptp driver, the result seems OK.
> >
> > static struct ptp_clock_info ptp_pch_caps = {
> > .owner = THIS_MODULE,
> > .name = "PCH timer",
> > // .max_adj = 50000000,
> > .max_adj = 32767999, // Changed the max_adj by TS.
> >
> > (Question)
> > 1. Is my modification correct ?
> > 2. Is it better to correct it in another part?
>
> I think we should change ptp4l to limit the max_adj according to
> the driver's max_adj and sizeof(long).
>
>
I will use the original EG20T ptp driver and modify ptp4l as follows
temporarily.

int phc_max_adj(clockid_t clkid)
{
 int fd = CLOCKID_TO_FD(clkid);
 struct ptp_clock_caps caps;

 if (ioctl(fd, PTP_CLOCK_GETCAPS, &caps)) {
  perror("PTP_CLOCK_GETCAPS");
  return 0;
 }

 if (caps.max_adj > 32767999) // TS Add here.
  caps.max_adj = 32767999;   // TS Add here.

 return caps.max_adj;
}

Thanks,
Takahiro Shimizu

Re: [Linuxptp-users] master offset is increased in some condition

[Richard C. <ric...@gm...>]

On Mon, Mar 12, 2012 at 02:42:10PM +0900, Takahiro Shimizu wrote:
> Hello,
> 
> I faced the issue that the master offset is increased in some condition.

...
 
> This issue is happened when adj is -50000000 or 50000000.
> If the adj is -50000000 with s2(SERVO_LOCKED), clock_ppb is called with
> -adj.
> 
> enum servo_state clock_synchronize(struct clock *c,
> :
> :
> case SERVO_LOCKED:
> clock_ppb(c->clkid, -adj);
> :
> 
> 
> static void clock_ppb(clockid_t clkid, double ppb)
> {
> struct timex tx;
> memset(&tx, 0, sizeof(tx));
> tx.modes = ADJ_FREQUENCY;
> tx.freq = (long) (ppb * 65.536);
> if (clock_adjtime(clkid, &tx) < 0)
> pr_err("failed to adjust the clock: %m");
> }
> If ppb is 50000000, then the result is 50000000 * 65.536 = 3276800000.
> tx.freq = (long)3276800000 = -1018167296.
> I think the tx.freq is overflowed. This is unexpected result.
> 
> I think tx.freq should be under 0x7fffffff.
> If so, the max adh should be 0x7fffffff/65.536 = 32767999.9847...

Yes, you are right, for 32 bit machines.

The problem is that the PHC driver API has the max_adj in ppb, but the
NTP adjtime API has the frequency adjustment field as ppm with a 16
bit fractional part.

In the PHC driver API the field is four bytes (type s32), but in the
NTP adjtime API the field is either four or eight bytes (type long),
depending on the machine architecture.
 
> If I chage the EG20T ptp driver, the result seems OK.
> 
> static struct ptp_clock_info ptp_pch_caps = {
> .owner = THIS_MODULE,
> .name = "PCH timer",
> // .max_adj = 50000000,
> .max_adj = 32767999, // Changed the max_adj by TS.
> 
> (Question)
> 1. Is my modification correct ?
> 2. Is it better to correct it in another part?

I think we should change ptp4l to limit the max_adj according to
the driver's max_adj and sizeof(long).

Thanks,
Richard

[Linuxptp-users] master offset is increased in some condition

[Takahiro S. <tsh...@gm...>]

Hello,

I faced the issue that the master offset is increased in some condition.

The log is like below:
ptp4l[4597]: master offset -337052518 s2 adj -50000000 path delay    9249190
ptp4l[4597]: master offset -369835430 s2 adj -50000000 path delay    9249190
ptp4l[4597]: master offset -402770356 s2 adj -50000000 path delay    9402100
ptp4l[4597]: master offset -435105809 s2 adj -50000000 path delay    8954993
ptp4l[4597]: master offset -468838529 s2 adj -50000000 path delay    9904481
ptp4l[4597]: master offset -501932158 s2 adj -50000000 path delay   10212862
ptp4l[4597]: master offset -534480670 s2 adj -50000000 path delay    9979646
ptp4l[4597]: master offset -567281355 s2 adj -50000000 path delay    9997963
ptp4l[4597]: master offset -600064139 s2 adj -50000000 path delay    9997963
ptp4l[4597]: master offset -633393240 s2 adj -50000000 path delay   10544184
ptp4l[4597]: master offset -666177880 s2 adj -50000000 path delay   10544184
ptp4l[4597]: master offset -698614796 s2 adj -50000000 path delay   10198444
ptp4l[4597]: master offset -730351808 s2 adj -50000000 path delay    9152352
ptp4l[4597]: master offset -763135840 s2 adj -50000000 path delay    9152352

This issue is happened in the latest linuxptp too.

This issue is happened when adj is -50000000 or 50000000.
If the adj is -50000000 with s2(SERVO_LOCKED), clock_ppb is called with
-adj.

enum servo_state clock_synchronize(struct clock *c,
:
:
case SERVO_LOCKED:
clock_ppb(c->clkid, -adj);
:


static void clock_ppb(clockid_t clkid, double ppb)
{
struct timex tx;
memset(&tx, 0, sizeof(tx));
tx.modes = ADJ_FREQUENCY;
tx.freq = (long) (ppb * 65.536);
if (clock_adjtime(clkid, &tx) < 0)
pr_err("failed to adjust the clock: %m");
}
If ppb is 50000000, then the result is 50000000 * 65.536 = 3276800000.
tx.freq = (long)3276800000 = -1018167296.
I think the tx.freq is overflowed. This is unexpected result.

I think tx.freq should be under 0x7fffffff.
If so, the max adh should be 0x7fffffff/65.536 = 32767999.9847...

If I chage the EG20T ptp driver, the result seems OK.

static struct ptp_clock_info ptp_pch_caps = {
.owner = THIS_MODULE,
.name = "PCH timer",
// .max_adj = 50000000,
.max_adj = 32767999, // Changed the max_adj by TS.

(Question)
1. Is my modification correct ?
2. Is it better to correct it in another part?

Thanks and Best regards,
Takahiro Shimizu