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

Re: [Linuxptp-users] issue with NetXtreme II BCM57810

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

On Tue, Oct 04, 2016 at 10:49:46AM +0000, Luke Bigum wrote:
> If I do some simple tests with linux/Documentation/ptp/testptp.c, it
> appears the PHC is spinning at about half the Hz it should be doing
> (it takes roughly 2 real seconds for the PHC to advance 1
> second). While it is an anecdotal observation, half as fast seems
> rather uniform a problem, like there's a /2 somewhere gone wrong in
> the driver code...  If I wanted to dig into the bnx2x source, any
> pointers on where to start looking?

I don't have this card nor was I involved in reviewing the driver.
The file, drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c, contains
the PHC stuff.

Looking at bnx2x_init_cyclecounter(), they have mult = shift = 1.
That implies that

  nanoseconds = ticks / 2

and that their internal clock runs at 2 GHz!

Maybe they meant to have shift=0, or maybe your card has a (model
specific 1 GHz clock).

Anyhow, the testptp result is clear enough.  You should take this up
with the driver maintainers.

Thanks,
Richard

[Linuxptp-users] issue with NetXtreme II BCM57810

[Luke B. <luk...@lm...>]

Hello,

I have a hardware timestamping issue with a Broadcom NIC that I'd like a few opinions on. I'm 95% sure it's a NIC / driver problem, but I need some expert opinions before I go down the vendor / manufacturer route.

Both ptp4l and a build of ptpd using the PHC subsystem exhibit similar problems - either daemon continuously thinks the PHC needs to be stepped forward, anywhere from 1 - 1.5 seconds for each second of wall clock time.

If I do some simple tests with linux/Documentation/ptp/testptp.c, it appears the PHC is spinning at about half the Hz it should be doing (it takes roughly 2 real seconds for the PHC to advance 1 second). While it is an anecdotal observation, half as fast seems rather uniform a problem, like there's a /2 somewhere gone wrong in the driver code...  If I wanted to dig into the bnx2x source, any pointers on where to start looking?



The rest of this email are log file + relevant details about the OS and NIC...


Oct  3 15:38:36 isptpsl01 ptp4l: [14201.187] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
Oct  3 15:38:37 isptpsl01 ptp4l: [14202.185] master offset -1453645423 s0 freq -31000000 path delay 142741226
Oct  3 15:38:37 isptpsl01 ptp4l: [14202.185] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
Oct  3 15:38:38 isptpsl01 ptp4l: [14203.185] master offset -1938178522 s0 freq -31000000 path delay 142741226
Oct  3 15:38:39 isptpsl01 ptp4l: [14204.185] master offset -2422706382 s1 freq -31000000 path delay 142741226
Oct  3 15:38:41 isptpsl01 ptp4l: [14206.185] master offset -962038200 s2 freq -31000000 path delay 135714969
Oct  3 15:38:41 isptpsl01 ptp4l: [14206.187] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
Oct  3 15:38:42 isptpsl01 ptp4l: [14207.185] master offset -1446569992 s0 freq -31000000 path delay 135714969
Oct  3 15:38:42 isptpsl01 ptp4l: [14207.185] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
Oct  3 15:38:43 isptpsl01 ptp4l: [14208.185] master offset -1931098770 s0 freq -31000000 path delay 135714969
Oct  3 15:38:44 isptpsl01 ptp4l: [14209.185] master offset -2422655704 s1 freq -31000000 path delay 142741226
Oct  3 15:38:45 isptpsl01 ptp4l: [14210.185] master offset -484531919 s2 freq -31000000 path delay 142741226
Oct  3 15:38:45 isptpsl01 ptp4l: [14210.187] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
Oct  3 15:38:46 isptpsl01 ptp4l: [14211.185] master offset -969076973 s2 freq -31000000 path delay 142741226
Oct  3 15:38:47 isptpsl01 ptp4l: [14212.185] master offset -1446579628 s0 freq -31000000 path delay 135714969
Oct  3 15:38:47 isptpsl01 ptp4l: [14212.185] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
Oct  3 15:38:48 isptpsl01 ptp4l: [14213.185] master offset -1925293801 s0 freq -31000000 path delay 129888779
Oct  3 15:38:49 isptpsl01 ptp4l: [14214.186] master offset -2370870770 s1 freq -31000000 path delay  90938984
Oct  3 15:38:51 isptpsl01 ptp4l: [14216.186] master offset -969077157 s2 freq -31000000 path delay  90938984


The controller is:

01:00.7 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet Multi Function (rev 10)
        Subsystem: Dell Device 0636


Tried two kernels and drivers:

kernel: 3.18.14
driver: bnx2x
version: 1.710.51-0
firmware-version: FFV7.12.15 bc 7.12.4

kernel: 4.6.5
driver: bnx2x
version: 1.712.30-0
firmware-version: FFV7.12.15 bc 7.12.4



And apparent capabilities of the NIC:

Time stamping parameters for em2_1:

Capabilities:
	hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
	software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
	hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
	software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
	software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
	hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
	off                   (HWTSTAMP_TX_OFF)
	on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
	none                  (HWTSTAMP_FILTER_NONE)
	ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
	ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
	ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
	ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
	ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
	ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
	ptpv2-l2-event        (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)
	ptpv2-l2-sync         (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
	ptpv2-l2-delay-req    (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
	ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
	ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
	ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)



ptp4l config file (I put in stupidly big step thresholds just to see what happens):

[global]
#
# Default Data Set
#
twoStepFlag		1
slaveOnly		1
priority1		128
priority2		128
domainNumber		0
clockClass		248
clockAccuracy		0xFE
offsetScaledLogVariance	0xFFFF
free_running		0
freq_est_interval	1
#
# Port Data Set
#
logAnnounceInterval	1
logSyncInterval		0
logMinDelayReqInterval	0
logMinPdelayReqInterval	0
announceReceiptTimeout	3
syncReceiptTimeout	0
delayAsymmetry		0
fault_reset_interval	4
neighborPropDelayThresh	20000000
#
# Run time options
#
assume_two_step		0
logging_level		6
path_trace_enabled	0
follow_up_info		0
hybrid_e2e		0
tx_timestamp_timeout	1
use_syslog		1
verbose			0
summary_interval	0
kernel_leap		1
check_fup_sync		0
#
# Servo Options
#
pi_proportional_const	0.0
pi_integral_const	0.0
pi_proportional_scale	0.0
pi_proportional_exponent	-0.3
pi_proportional_norm_max	0.7
pi_integral_scale	0.0
pi_integral_exponent	0.4
pi_integral_norm_max	0.3
step_threshold		1.0
first_step_threshold	1.0
max_frequency		900000000
clock_servo		pi
sanity_freq_limit	1000000000
ntpshm_segment		0
#
# Transport options
#
transportSpecific	0x0
ptp_dst_mac		01:1B:19:00:00:00
p2p_dst_mac		01:80:C2:00:00:0E
udp_ttl			8
udp6_scope		0x0E
uds_address		/var/run/ptp4l
#
# Default interface options
#
network_transport	UDPv4
delay_mechanism		E2E
time_stamping		hardware
tsproc_mode		filter
delay_filter		moving_median
delay_filter_length	10
egressLatency		0
ingressLatency		0
boundary_clock_jbod	0
#
# Clock description
#
productDescription	;;
revisionData		;;
manufacturerIdentity	00:00:00
userDescription		;
timeSource		0xA0


-- 
Luke Bigum
Senior Systems Engineer

Information Systems
---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

Recognised by the most prestigious business and technology awards
 
2016 Best Trading & Execution, HFM US Technology Awards
2016, 2015, 2014, 2013 Best FX Trading Venue - ECN/MTF, WSL Institutional Trading Awards

2015 Winner, Deloitte UK Technology Fast 50
2015, 2014, 2013, One of the UK's fastest growing technology firms, The Sunday Times Tech Track 100
2015 Winner, Deloitte EMEA Technology Fast 500
2015, 2014, 2013 Best Margin Sector Platform, Profit & Loss Readers' Choice Awards

---

FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved.

This message and its attachments are confidential, may not be disclosed or used by any person other than the addressee and are intended only for the named recipient(s). This message is not intended for any recipient(s) who based on their nationality, place of business, domicile or for any other reason, is/are subject to local laws or regulations which prohibit the provision of such products and services. This message is subject to the following terms (http://lmax.com/pdf/general-disclaimers.pdf), if you cannot access these, please notify us by replying to this email and we will send you the terms. If you are not the intended recipient, please notify the sender immediately and delete any copies of this message.

LMAX Exchange is the trading name of LMAX Limited. LMAX Limited operates a multilateral trading facility. LMAX Limited is authorised and regulated by the Financial Conduct Authority (firm registration number 509778) and is a company registered in England and Wales (number 6505809).

LMAX Hong Kong Limited is a wholly-owned subsidiary of LMAX Limited. LMAX Hong Kong is licensed by the Securities and Futures Commission in Hong Kong to conduct Type 3 (leveraged foreign exchange trading) regulated activity with CE Number BDV088.

Re: [Linuxptp-users] one-shot alarm

[Kieran T. <ki...@si...>]

Thanks Richard and Dale for the fast replies.

I see that it should be possible to use the ptp_feature_enable function to pass in an alarm time, and then when the alarm fires, use the EXTTS event mechanism to pass a notification/event back to the app. Hopefully this will suffice for our application.

Thanks, Kieran.

> On 22 Aug 2016, at 17:39, Dale Smith <dal...@gm...> wrote:
> 
> 
> On Mon, Aug 22, 2016 at 11:34 AM, Richard Cochran <ric...@gm... <mailto:ric...@gm...>> wrote:
> > So my questions:
> > - is the one-shot alarm functionality of the PHC actually implemented in any driver?
> 
> No.
> 
> > - how can I implement this in the freescale FEC driver without
> >   having to modify the kernel? (ptp_clock_kernel.h and
> >   drivers/ptp/ptp_clock.c)
> 
> You can't implement this without changing the kernel.
> 
> There are (currently) unused flag bits and the structures are padded out with extra reserved fields.  It's possible to abuse these fields to implement whatever you need.  You still need to modify the FEC (or whatever) driver, but at least you don't need to plumb the changes all throughout the whole kernel.
> 
> I'm not really recommending you do this, especially if this is for general purpose use.  But if you really need to have a HW alarm go off with ns resolution, this is one way to make it happen.  (Yes, I needed to to exactly that)
> 
> Richard, thanks for having the forethought to add those extra fields!
> 
> -Dale
> 

Re: [Linuxptp-users] one-shot alarm

[Dale S. <dal...@gm...>]

On Mon, Aug 22, 2016 at 11:34 AM, Richard Cochran <ric...@gm...>
wrote:

> > So my questions:
> > - is the one-shot alarm functionality of the PHC actually implemented in
> any driver?
>
> No.
>
> > - how can I implement this in the freescale FEC driver without
> >   having to modify the kernel? (ptp_clock_kernel.h and
> >   drivers/ptp/ptp_clock.c)
>
> You can't implement this without changing the kernel.
>

There are (currently) unused flag bits and the structures are padded out
with extra reserved fields.  It's possible to abuse these fields to
implement whatever you need.  You still need to modify the FEC (or
whatever) driver, but at least you don't need to plumb the changes all
throughout the whole kernel.

I'm not really recommending you do this, especially if this is for general
purpose use.  But if you really need to have a HW alarm go off with ns
resolution, this is one way to make it happen.  (Yes, I needed to to
exactly that)

Richard, thanks for having the forethought to add those extra fields!

-Dale

Re: [Linuxptp-users] one-shot alarm

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

> So my questions:
> - is the one-shot alarm functionality of the PHC actually implemented in any driver?

No.

> - how can I implement this in the freescale FEC driver without
>   having to modify the kernel? (ptp_clock_kernel.h and
>   drivers/ptp/ptp_clock.c)

You can't implement this without changing the kernel.
 
> Hopefully I’m missing something and there is a simple way to get the
> alarm functionality working.

Unfortunately, you understood the kernel sources well enough.  There
is a non-trivial amount of work to implement the timer in the PHC core
code.  I decided some time ago that the possible benefit is not worth
the effort required.  I would say most use cases can be adequately
covered by:

1. using a PREEMPT_RT kernel
2. synchronizing the system time from the PHC using phc2sys
3. programming a normal high resolution timer using CLOCK_MONOTONIC or
   CLOCK_REALTIME.

Sorry,
Richard

[Linuxptp-users] one-shot alarm

[Kieran T. <ki...@si...>]

Hi,

I would like to use the one-shot alarm feature of the PHC on an i.MX6. The i.MX6 hardware can support this, but I notice it’s not supported by the Freescale/NXP drivers.

testptp -c reports 0 programmable alarms, and the source code confirms this.

I have been looking through the Freescale fec driver sources and linux kernel sources with a view to implementing this, but came up against a block because at the kernel level struct ptp_clock_info (ptp_clock_kernel.h) doesn’t contain a function pointer for a ‘set one shot timer’ function, and drivers/ptp/ptp_clock.c doesn’t seem to do anything with the PTP_CLOCK_ALARM event anyway (the ptp_clock_event function just has a stubbed switch statement for PTP_CLOCK_ALARM).

So my questions:
- is the one-shot alarm functionality of the PHC actually implemented in any driver?
- how can I implement this in the freescale FEC driver without having to modify the kernel? (ptp_clock_kernel.h and drivers/ptp/ptp_clock.c)

Hopefully I’m missing something and there is a simple way to get the alarm functionality working.

Thanks,

Kieran.

Re: [Linuxptp-users] Failed synchronization

[Daniel Le <dan...@ex...>]

Hi Richard,

It's a new hardware platform and newer 3.x Linux kernel, however the integration approach is same.

I changed to rely on software timestamps instead and synchronization works fine.

When our FPGA team will make our NIC 1588 aware and implement a PHC, I will use hardware timestamping.

Regards,
Daniel

-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...] 
Sent: Friday, August 05, 2016 3:41 AM
To: Daniel Le <dan...@ex...>
Cc: lin...@li...
Subject: Re: [Linuxptp-users] Failed synchronization

On Thu, Aug 04, 2016 at 10:13:35PM +0000, Daniel Le wrote:
> You didn't tell us what hardware your are using: platform, NIC, driver?
> [DL] It's an embedded system with proprietary FPGA based NIC and driver.

Sigh.

This is the same system you were asking us about back in April 2015.
If you have HW time stamping, then you should implement a proper PHC.
The fact that you are using SW time stamping in the application is a sure sign that you have it all wrong.
 
> After stepping the clock, the offset remains the same.  Your system clock or the MAC driver is somehow broken.
> [DL] Is tsproc_update_offset function a good place where to check t1, t2, t3, t4 values
>          in order to see which timestamp(s) may cause the offset to remain the same?

Try looking in your driver.

> [DL] In this function, are master timestamps (t1, t4) TAI and slave timestamps (t2, t3) UTC?

Just how are we supposed to know?

You have some kind of weird custom system in which you abuse the whole PHC subsystem.  We can't help you with that.
 
Sorry,
Richard

Re: [Linuxptp-users] Failed synchronization

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

On Thu, Aug 04, 2016 at 10:13:35PM +0000, Daniel Le wrote:
> You didn't tell us what hardware your are using: platform, NIC, driver?
> [DL] It's an embedded system with proprietary FPGA based NIC and driver.

Sigh.

This is the same system you were asking us about back in April 2015.
If you have HW time stamping, then you should implement a proper PHC.
The fact that you are using SW time stamping in the application is a
sure sign that you have it all wrong.
 
> After stepping the clock, the offset remains the same.  Your system clock or the MAC driver is somehow broken.
> [DL] Is tsproc_update_offset function a good place where to check t1, t2, t3, t4 values
>          in order to see which timestamp(s) may cause the offset to remain the same?

Try looking in your driver.

> [DL] In this function, are master timestamps (t1, t4) TAI and slave timestamps (t2, t3) UTC?

Just how are we supposed to know?

You have some kind of weird custom system in which you abuse the whole
PHC subsystem.  We can't help you with that.
 
Sorry,
Richard

Re: [Linuxptp-users] Failed synchronization

[Daniel Le <dan...@ex...>]

Hi Richard, please see follow-up comments and questions inline.

-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...] 
Sent: Thursday, August 04, 2016 4:34 PM
To: Daniel Le <dan...@ex...>
Cc: lin...@li...
Subject: Re: [Linuxptp-users] Failed synchronization

On Thu, Aug 04, 2016 at 07:36:45PM +0000, Daniel Le wrote:
> I have frequent synchronization issue on a PTP ordinary clock which 
> has Linux kernel 3.18.12 and LinuxPTP v1.6. It runs in slave mode with 
> software timestamping.

You didn't tell us what hardware your are using: platform, NIC, driver?
[DL] It's an embedded system with proprietary FPGA based NIC and driver.

> To force the problem to occur every time, I change the system clock to 
> be approximately 5 minutes ahead of PTP Grandmaster clock. In the 
> following, the (enhanced) log messages show ptp4l correctly steps the 
> system clock with the observed offset, then transitions into 
> SERVO_LOCKED state, however the master offset as seen by ptp4l keeps 
> increasing afterwards. The slew and PI reset operations seem not to be 
> able to keep up.

After stepping the clock, the offset remains the same.  Your system clock or the MAC driver is somehow broken.
[DL] Is tsproc_update_offset function a good place where to check t1, t2, t3, t4 values
         in order to see which timestamp(s) may cause the offset to remain the same?
[DL] In this function, are master timestamps (t1, t4) TAI and slave timestamps (t2, t3) UTC?

Also, the frequency estimation that occurs between UNCALIBRATED and SLAVE runs off the scale.  Is your local oscillator really that bad?
[DL] I can't explain why... but if the system is rebooted then synchronization works fine, while a restart of ptp4l doesn't make a difference.

No idea how your computer could be so messed up.

Sorry,
Richard

Re: [Linuxptp-users] Failed synchronization

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

On Thu, Aug 04, 2016 at 07:36:45PM +0000, Daniel Le wrote:
> I have frequent synchronization issue on a PTP ordinary clock which
> has Linux kernel 3.18.12 and LinuxPTP v1.6. It runs in slave mode
> with software timestamping.

You didn't tell us what hardware your are using: platform, NIC, driver?

> To force the problem to occur every time, I change the system clock
> to be approximately 5 minutes ahead of PTP Grandmaster clock. In the
> following, the (enhanced) log messages show ptp4l correctly steps
> the system clock with the observed offset, then transitions into
> SERVO_LOCKED state, however the master offset as seen by ptp4l keeps
> increasing afterwards. The slew and PI reset operations seem not to
> be able to keep up.

After stepping the clock, the offset remains the same.  Your system
clock or the MAC driver is somehow broken.

Also, the frequency estimation that occurs between UNCALIBRATED and
SLAVE runs off the scale.  Is your local oscillator really that bad?

No idea how your computer could be so messed up.

Sorry,
Richard

[Linuxptp-users] Failed synchronization

[Daniel Le <dan...@ex...>]

Hello,

I have frequent synchronization issue on a PTP ordinary clock which has Linux kernel 3.18.12 and LinuxPTP v1.6. It runs in slave mode with software timestamping.

To force the problem to occur every time, I change the system clock to be approximately 5 minutes ahead of PTP Grandmaster clock. In the following, the (enhanced) log messages show ptp4l correctly steps the system clock with the observed offset, then transitions into SERVO_LOCKED state, however the master offset as seen by ptp4l keeps increasing afterwards. The slew and PI reset operations seem not to be able to keep up.

Any help is appreciated.
Daniel

ptp4l[137.667]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[137.667]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[137.864]: port 1: new foreign master 00b0ae.fffe.02d104-1
ptp4l[141.864]: selected best master clock 00b0ae.fffe.02d104
ptp4l[141.864]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[143.090]: port 1: minimum delay request interval 2^-7
ptp4l[143.801]: master offset 292990930284 s0 freq      +0 path delay    255286
....................................
ptp4l[158.800]: master offset 292990192008 s0 freq      +0 path delay      2970
ptp4l[159.799]: master offset 292989435868 s1 freq  -93410 path delay    255430
ptp4l[159.800]: ***Before step*** system time = Thu Aug  4 18:59:45 2016 839875 micros
ptp4l[159.800]: clockadj_step clkid=0 offset=-292989435868
ptp4l[159.800]: ***After step*** system time = Thu Aug  4 18:54:51 2016 850548 micros
ptp4l[160.799]: master offset 292989436892 s2 freq +100000000 path delay    255430          <<<=========
ptp4l[160.799]: clockadj_set_freq
ptp4l[160.800]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[160.945]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[160.945]: pi_reset
....................................
ptp4l[161.700]: master offset 292989691148 s0 freq +100000000 path delay      2778
ptp4l[161.700]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
ptp4l[161.792]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[161.792]: pi_reset
....................................
ptp4l[162.600]: master offset 292989692174 s0 freq +100000000 path delay      2904
ptp4l[162.650]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[162.650]: pi_reset
....................................
ptp4l[163.500]: master offset 292989693962 s0 freq +100000000 path delay      2748
ptp4l[163.586]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[163.586]: pi_reset
....................................
ptp4l[164.400]: master offset 292989694906 s0 freq +100000000 path delay      2888
ptp4l[164.431]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[164.431]: pi_reset
....................................
ptp4l[165.300]: master offset -147127914636 s0 freq +100000000 path delay 146705873134
ptp4l[165.382]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[165.382]: pi_reset
....................................
ptp4l[166.200]: master offset -422042768 s0 freq +100000000 path delay      2870
ptp4l[166.231]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[166.231]: pi_reset
....................................
ptp4l[167.100]: master offset -422041762 s0 freq +100000000 path delay      2980
ptp4l[167.180]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[167.180]: pi_reset
....................................
ptp4l[167.999]: master offset -422040068 s0 freq +100000000 path delay      2886
ptp4l[168.031]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[168.031]: pi_reset
....................................
ptp4l[168.899]: master offset -422039004 s0 freq +100000000 path delay      2910
ptp4l[168.966]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[168.966]: pi_reset
....................................
ptp4l[169.799]: master offset -422037260 s0 freq +100000000 path delay      2770
ptp4l[170.001]: clockcheck: clock jumped forward or running faster than expected!
ptp4l[170.001]: pi_reset
ptp4l[170.699]: master offset -585402570 s0 freq +100000000 path delay  51353036
ptp4l[171.599]: master offset -746676648 s0 freq +100000000 path delay  69771338
ptp4l[172.499]: master offset -887764240 s0 freq +100000000 path delay  68002674
....................................

Re: [Linuxptp-users] PTP follow up

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

On Wed, Aug 03, 2016 at 09:50:46AM -0400, Dale Smith wrote:
> Perhaps you should submit the discrepancy?

I think the "interpretations" are closed for 1588.  The v3 version is
well under way, or so I heard.

Thanks,
Richard

Re: [Linuxptp-users] PTP follow up

[Dale S. <dal...@gm...>]

On Wed, Aug 3, 2016 at 6:32 AM, Richard Cochran <ric...@gm...>
wrote:

> On Tue, Aug 02, 2016 at 07:02:12PM +0200, Richard Cochran wrote:
> > struct dataset {
> >       UInteger8            priority1;     // GM, from the announce
> message
> >       struct ClockIdentity identity;      // GM, from the announce
> message
> >       struct ClockQuality  quality;       // GM, from the announce
> message
> >       UInteger8            priority2;     // GM, from the announce
> message
> >       UInteger16           stepsRemoved;  // announce message
> >       struct PortIdentity  sender;        // sourcePortIdentity (of the
> announce)
> >       struct PortIdentity  receiver;      // parentDS.portIdentity
> (upstream port ID)
>
> NOT! ......................................... ^^^^^^^^
>
> There is a typo in 1588.  They wrote parentDS when they really meant
> portDS.  Comparing with 802.1AS, the latter standard leaves out the
> clockIdentity part of the portIdentity, using only the portNumber.
>

Are you talking about Table 12 on page 83,  Section 9.3.4?   I don't see
that listed in the "Interpretations"  at
http://standards.ieee.org/findstds/interps/1588-2008.html

Perhaps you should submit the discrepancy?

Thanks,
   -Dale

Re: [Linuxptp-users] PTP follow up

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

On Tue, Aug 02, 2016 at 07:02:12PM +0200, Richard Cochran wrote:
> struct dataset {
> 	UInteger8            priority1;     // GM, from the announce message
> 	struct ClockIdentity identity;      // GM, from the announce message
> 	struct ClockQuality  quality;       // GM, from the announce message
> 	UInteger8            priority2;     // GM, from the announce message
> 	UInteger16           stepsRemoved;  // announce message
> 	struct PortIdentity  sender;        // sourcePortIdentity (of the announce)
> 	struct PortIdentity  receiver;      // parentDS.portIdentity (upstream port ID)

NOT! ......................................... ^^^^^^^^

There is a typo in 1588.  They wrote parentDS when they really meant
portDS.  Comparing with 802.1AS, the latter standard leaves out the
clockIdentity part of the portIdentity, using only the portNumber.

Anyhow, the code is wrongly using parentDS.  There is another bug, I
think, in that we don't consider the sender/receiver fields when
detecting a change that triggers the BMC.  We might overlook a
topology change that affects the MASTER/PASSIVE choice.

I'll be fixing these issues "real soon".

Thanks,
Richard

Re: [Linuxptp-users] PTP follow up

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

On Mon, Aug 01, 2016 at 10:02:04AM -0400, Vanderpool, Clyde wrote:

> The left side of the diagram is synchronized first, with the Ground Gateway
> assuming the Grand Master role.  Then the right side of the diagram is
> brought up.  On the right side link 1-A (which has no direct connection to
> the left side) and the Air Gateway will always pick link 3-A as it's parent
> boundary clock (despite the order in which they are synced to the LAN).  I
> find this strange due to the fact that the path to the Grand Master needs
> to go over a radio (3-A-->3-G-->Ground Gateway) instead of going through a
> direct Ethernet connection (2-A-->2-G-->Ground Gateway).

Don't run PTP over wireless.  The performance will be awful.  You are
better off using NTP over wireless.
 
> I then tried to take link 3-G offline.  This caused links 1-A, 3-A, and the
> Air Gateway to pick 2-A as their parent boundary clock.  This makes sense,
> as 2-A offers the only connection to the Grand Master.  When I bring back
> link 3-G, link 3-A picks it as it's parent boundary clock.  This makes
> sense to me as it requires less steps to get to the Grand Master.  What
> does not make sense to me is that both link 1-A and the Air Gateway drop
> link 2-A as their parent and once again sync to link 3-A despite the fact
> that the steps removed from the Grand Master remains the same.

On the right hand side of your network, the PTP spanning tree depends
on the roles decided by the BMC for the two eth0 ports on nodes 2-A
and 3-A.  You can follow the BMC algorithm in the file bmc.c.

Since both nodes have the same GM, one port will take the MASTER role
and the other will take the PASSIVE role (line 152).  If the paths are
the same length, then you fall through to dscmp2().  Here the port
identities (MAC address) act as a tie breaker.  That means the role
assignment should always turn out the same way.

When reading the dataset comparison algorithm, it is important to
remember where the fields of the dataset come from.  For the case of
clock_best and port_best, the origin of the fields is as follows.

struct dataset {
	UInteger8            priority1;     // GM, from the announce message
	struct ClockIdentity identity;      // GM, from the announce message
	struct ClockQuality  quality;       // GM, from the announce message
	UInteger8            priority2;     // GM, from the announce message
	UInteger16           stepsRemoved;  // announce message
	struct PortIdentity  sender;        // sourcePortIdentity (of the announce)
	struct PortIdentity  receiver;      // parentDS.portIdentity (upstream port ID)
};

BTW, using vde_switch I simulated a redundant network similar to your
setup.  I discover a bug.  Depending on the timing of the announce
messages, the port that should become PASSIVE may instead stay in the
MASTER state.  I will post a fix as soon as I have it.

(Your issue is not related to the bug, but it is rather the expect behavior.)
 
> I was just wondering why the two machines with no direct connection to the
> Grand Master would consistently choose the longer pathway (time wise) to
> the Grand Master.  Is there something about the Best Master Clock Algorithm
> that makes this so?

The time plays no role in the BMC algorithm.

HTH,
Richard

Re: [Linuxptp-users] PTP4L originTimestamp question

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

On Wed, Jul 27, 2016 at 05:09:04PM +0800, 劉邦慈 wrote:
> Why does the
> ​​
> Slave
> ​
> (PTP4L)​
> ​​
> originTimestamp capture 0?

This is in accordance with the standard.
See Section 11.3.2 in IEEE 1588.

Thanks,
Richard

[Linuxptp-users] PTP4L ​originTimestamp ​question

[劉邦慈 <b10...@gm...>]

​
Hello​ linuxptp-users,

Please could anyone​ ​from​ ​you​ help me answer this
​​
question.

I use ptp4L,command is
     ./ptp4l -E -4 -H -i eth0 -l 7 -m -f default.cfg

the ptp4l is working(Slave):
ptp4l[1898078.766]: master offset  1670 s2 freq +20901 path delay 25399
ptp4l[1898079.768]: master offset -1315 s2 freq +18417 path delay 25399
ptp4l[1898080.770]: master offset -2759 s2 freq +16578 path delay 25399

But,i Use Wireshark to Capture the package

the Slave PTP4L's Delay_Req Message (0x01) package's
originTimestamp(seconds): 0
originTimestamp(nanoseconds): 0

Another
​
Device
​
,
The master PTP's Delay_Resp Message (0x09)
receiveTimestamp(seconds): 1469608239
receiveTimestamp (nanoseconds): 973646596


Why does the
​​
Slave
​
(PTP4L)​
​​
originTimestamp capture 0?

Thank you in advance for your help,

LPT

Re: [Linuxptp-users] New article explaining PTP and NTP

[Baya O. <bay...@gm...>]

many thankx  for the link to this paper...

2016-07-25 23:27 GMT+02:00 Richard Cochran <ric...@gm...>:

>
> I just stumbled over Miroslav's recent article.
>
>
> http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/
>
> It gives a thorough treatment of NTP and PTP.  Nice work!
> (Now I know what the timemaster is good for ;)
>
> Regarding redundancy (resiliency) using PTP, I have been giving it
> some thought recently.  There are different possibilities out there,
> for example operating in two or more domains, using the alternate
> master option, or even running under HSR/PRP.  The new TSN protocol is
> also going to address redundancy, IIRC.
>
> So I think we will add redundancy to linuxptp, but I don't know which
> flavor(s) it will be.  I am taking a "wait and see" approach.  In the
> mean time, if anyone want to take on this issue, please go right
> ahead...
>
> Thanks,
> Richard
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>

[Linuxptp-users] New article explaining PTP and NTP

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

I just stumbled over Miroslav's recent article.

  http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/

It gives a thorough treatment of NTP and PTP.  Nice work!
(Now I know what the timemaster is good for ;)

Regarding redundancy (resiliency) using PTP, I have been giving it
some thought recently.  There are different possibilities out there,
for example operating in two or more domains, using the alternate
master option, or even running under HSR/PRP.  The new TSN protocol is
also going to address redundancy, IIRC.

So I think we will add redundancy to linuxptp, but I don't know which
flavor(s) it will be.  I am taking a "wait and see" approach.  In the
mean time, if anyone want to take on this issue, please go right
ahead...

Thanks,
Richard

[Linuxptp-users] [announce] version 1.7 released

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

Dear linuxptp users and developers,

Version 1.7 of linuxptp is released, a good ten months after the
previous release.  I pushed out tag v1.7 and a tar ball on SF.

Thanks to Henry, Miroslav, and Wolfgang for their contributions!

Cheers,
Richard


Jesuiter, Henry (ALC NetworX GmbH) (2):
      Fix data type for return value of vasprintf()
      Introduce options to set DSCP values in PTP messages.

Miroslav Lichvar (4):
      tsproc: allow zero remote timestamps in delay update
      timemaster: allow arbitrary options in server/refclock directives.
      timemaster: add option to specify first SHM segment.
      timemaster: ignore failures of non-essential processes.

Richard Cochran (17):
      tsproc: Fix time stamp handling with P2P one shot mode.
      Properly initialize the message lists.
      fault: protect header against multiple inclusion.
      print: add missing include directive.
      config: get the time stamp information early.
      clock: simplify the create method.
      clock: remove redundant parameter from the create method.
      Move the clock type enumeration into the clock header.
      clock: offer a method to get the type rather than the number of ports.
      clock: offer a method to get the first port in the list.
      Perform the time stamping mode check in the clock module.
      config: count the interfaces as they are added.
      clock: specify type at creation time.
      Let the clock code figure the PHC index.
      Fix the man page regarding the '-p' option.
      uds: Prevent unintentional announce message timeouts.
      Version 1.7

Wolfgang Wallner (1):
      Fix typo in manpage of ptp4l

Re: [Linuxptp-users] Read ptp clock from a C code ..

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

On Tue, Jul 19, 2016 at 10:42:20AM +0200, Baya Oussena wrote:
> I tried to compile the testptp.c but failed. Is there any one from you who
> has a code I could adapt to my need or is it as sample as just opening and
> reading /dev/ptp0 driver.

The testptp.c program is the example for the PHC API.  It should
compile without any trouble.

Here is how I would do it, taking the beagle bone as an example:

	export ARCH=arm
	export CROSS_COMPILE=/opt/x-tools/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-
	export KBUILD_OUTPUT=/home/richard/kernel/beagle
	# compile the kernel
	make
	# install the headers under ${KBUILD_OUTPUT}
	make headers_install
	# compile the test program
	make -C Documentation/ptp -f testptp.mk

Easy, right?

Thanks,
Richard

[Linuxptp-users] Read ptp clock from a C code ..

[Baya O. <bay...@gm...>]

Hallo linuxptp-users,

I would like to use a C code to read the ptp clock of the running ptp4l
daemon.
I tried to compile the testptp.c but failed. Is there any one from you who
has a code I could adapt to my need or is it as sample as just opening and
reading /dev/ptp0 driver.

Thank you for your attention,,
Baya

Re: [Linuxptp-users] complete nub

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

On Fri, Jul 15, 2016 at 11:00:50AM +0000, Prasenjeet Shodangi wrote:
> I am currently trying to run ptp protocol using a single master and a slave
> using software timestamping.
> I have been able to sync the slave to master for now.

That sounds good.

> please guide me on how should i continue further.

(If you are happy with the result, then there is no need to go further ;)

> any helpful reading material would be highly
> appreciated. also need help in writing the .conf files.

For reading, try IEEE 1588, IEEE 802.1AS-2011, the ptp4l and phc2sys
man pages, the linuxptp-users and linuxptp-devel archives on gmane.

For the conf files, you can start with default.cfg as it contains the
most common default settings.  Only change an option when you are sure
that you need that special setting (check the ptp4l man page).

HTH,
Richard

[Linuxptp-users] complete nub

[Prasenjeet S. <pr...@gm...>]

I am currently trying to run ptp protocol using a single master and a slave
using software timestamping.
I have been able to sync the slave to master for now. please guide me on how
should i continue further. any helpful reading material would be highly
appreciated. also need help in writing the .conf files.

Re: [Linuxptp-users] (no subject)

[Baya O. <bay...@gm...>]

yes thank you Richard,
 indeed it is going to be some issues to resolve... I will let you know the
progress using ptp4l but we need to find a best and secured solution
because the software will be implemented on real fast train, so the timing
is very very important..
Baya

2016-07-13 11:14 GMT+02:00 Richard Cochran <ric...@gm...>:

> On Wed, Jul 13, 2016 at 10:25:46AM +0200, Baya Oussena wrote:
> > Once again, I thank you very much for your help, you saved me a lot of
> > time. Indeed our architecture is Intel 82574 (driver e1000e) so I will
> have
> > to think of an other solution.
>
> Oh man.  That is not one of Intel's better parts.  Oh well.
>
> If you want to use ptp4l, you are going to have to implement multiple
> clocks, each with its own configuration.  Take a look at clock.h and
> clock.c.  The functional interface would allow more than one clock,
> but the implementation does not.  We have:
>
>         struct clock the_clock;
>         ...
>         clock_create()
>         {
>                 struct clock *c = &the_clock;
>                 ...
>                 return c;
>         }
>
> At the very least, you will have to properly allocate the new clock.
> After that, you'll have to make sure it all works.  My gut feeling is
> that there will be some issues to resolve...
>
> Good luck,
> Richard
>
>