I have been trying to use the ptpd-2.3.2 client (as provided on https://github.com/wowczarek/ptpd/tree/wowczarek-2.3.2-hwtest) to synchronize two ZYBO boards using the hardware timestamping feature. It is my understanding that hardware timestamping is supported on the Ethernet MAC of this board. Yet, upon cross-compiling, I have found that the system time is not updated and we keep getting the error message:
"1970-01-01 00:01:46.5327xemacps e000b000.ps7-ethernet: ioctl 35220 not implemented".
I have been using v3.18 of the Linux kernel with the 'CONFIG_XILINX_PS_EMAC_HWTSTAMP' flag enabled.
Do you have any idea what could be causing this problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That IOCTL is unrelated, it is SIOCBONDINFOQUERY, which queries the interface for bond interface info - PTPd uses that to discover physical interfaces if running a bonded interface.
This should not affect your time sync.
Are you getting any errors other than this one?
what does ethtool -T eth[x] output give you?
Thanks,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Time stamping parameters for eth0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
Other than the ioctl message, the other error condition I'm seeing is that the system time doesn't seem to update to that of the PTP master. Find a sample of the output I get when running the ptpd-2.3.2 client below.
You need to watch it for a little bit longer - what happens later?
Here the eth0 clock is waiting for clock to be stepped, once that is done, it should go through TRACKING state and eventually go into LOCKED state. Once that happens, the system clock should start to sync with the NIC clock.
Add global:log_status=y to the config file or command line and watch the /var/run/ptpd.status file - that will show you exactly what is going on. You can use the 'watch' command: watch -n 1 cat /var/run/ptpd.status.
If you want it to sync quicker, you may want it to step the clock immediately rather than wait in STEP state.
Thanks,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Check the output of ptpd -O : it will list all settings with descriptions and default values - look at the clock: section, you should find some options to help you sync the clock in less time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have kept the ptpd-2.3.2 client running for a long time but it does not seem to converge at all. It never really goes into LOCKED state. Upon looking at /var/run/ptpd.status file, I can see the client cycling through FREERUN -> STEP -> TRACKING; and then back to FREERUN and starts over.
I have tried modifying the hardware clock control PI (servo:), adding 'clock:step_startup_force = y', and lowering the value of 'servo:adev_locked_threshold_low_hw'. However, I have not seen any noticeable improvements.
Could this be a driver issue? I am using the Xilinx-provided driver (xilinx_emacps.c) for the Ethernet MAC of the Zynq-7000 SoC on the ZYBO board.
Thanks,
Jorge Sanchez
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you could try running this code, and checking the counters with SIGUSR2 again.
Otherwise build that and edit src/libcck/cck_logger.h and uncomment #define CCK_DEBUG, otherwise running make CFLAGS="-DCCK_DEBUG" - debug is quite verbose but it should at least show errors.
You should increase the adev threshold, not lower it by the way, ideally looking at the adev value you are seeing in the most stable state (bottom of the status file).
Also note that some drivers don't like dot1q / VLAN tagging, not sure if that is present in your network or not. I wanted to ask if you are running multicast or not, but the driver reports HWTSTAMP_FILTER_ALL, which looks like it can timestamp all packets - whether this is true or not is a different story.
It may well be that there is no issue with packet timestamping but there are issues with clock adjustment, the debug log out of the libcck branch should shed some light on that.
Thanks,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally, this could be an issue with transmit timestamps only - try running with ptpengine:delay_mechanism=DELAY_DISABLED - then it will only be syntonising (no path delay calculation) - but it will not use any TX timestamps. But since you are using ZYBO on both ends (master and slave), the other end also does transmit timestamps for Sync messages.
Do you have a dedicated hardware grandmaster available for testing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I have been trying to use the ptpd-2.3.2 client (as provided on https://github.com/wowczarek/ptpd/tree/wowczarek-2.3.2-hwtest) to synchronize two ZYBO boards using the hardware timestamping feature. It is my understanding that hardware timestamping is supported on the Ethernet MAC of this board. Yet, upon cross-compiling, I have found that the system time is not updated and we keep getting the error message:
"1970-01-01 00:01:46.5327xemacps e000b000.ps7-ethernet: ioctl 35220 not implemented".
I have been using v3.18 of the Linux kernel with the 'CONFIG_XILINX_PS_EMAC_HWTSTAMP' flag enabled.
Do you have any idea what could be causing this problem?
Hi,
That IOCTL is unrelated, it is SIOCBONDINFOQUERY, which queries the interface for bond interface info - PTPd uses that to discover physical interfaces if running a bonded interface.
This should not affect your time sync.
Are you getting any errors other than this one?
what does
ethtool -T eth[x]output give you?Thanks,
Wojciech
Hi,
This is the output I get from ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
Other than the ioctl message, the other error condition I'm seeing is that the system time doesn't seem to update to that of the PTP master. Find a sample of the output I get when running the ptpd-2.3.2 client below.
1970-01-01 00:12:56.300236, slv, bcaec5fffe4cdd4b(unknown)/1, 0.004787556, -1487861905.725415579, 1487861905.694065332, -1487861905.720628023,4
1970-01-01 00:12:56.918829, slv, bcaec5fffe4cdd4b(unknown)/1, 0.005141510, -1487861905.725415579, 1487861905.736171722, -148786xemacps e000b00.
1905.720628023, 0.000000000, D, 00013, 0.000000000, 0, 0.000000000, 0-1487861905.720628023, 1487861905.736171795
1970-01-01 00:12:57.300159 ptpd[1024].eth0 (notice) (slv) Offset computation now calibrated, enabled clock control
1970-01-01 00:12:57.300597, slv, bcaec5fffe4cdd4b(unknown)/1, 0.005141510, -1487861905.750764383, 1487861905.736171722, -1487861905.745622873,5
1970-01-01 00:12:57.300942 ptpd[1024].eth0 (warning) (slv) clock: Clock eth0 offset above 1 second ( 1487861905.750764383 s), suspending clock)
1970-01-01 00:12:57.301243 ptpd[1024].eth0 (notice) (slv) clock: Clock eth0 changed state from FREERUN to STEP
xemacps e000b000.ps7-ethernet: ioctl 35220 not implemented.
1970-01-01 00:12:58.300466, slv, bcaec5fffe4cdd4b(unknown)/1, 0.005141510, -1487861905.775758756, 1487861905.736171722, -1487861905.770617246,5
1970-01-01 00:12:58.431143, slv, bcaec5fffe4cdd4b(unknown)/1, 0.005115041, -1487861905.775758756, 1487861905.774051427, -1487861905.770617246,9
xemacps e000b000.ps7-ethernet: ioctl 35220 not implemented.
It appears to synchronize with the master, but the system time doesn't change to that of the master.
Thanks,
Jorge
You need to watch it for a little bit longer - what happens later?
Here the eth0 clock is waiting for clock to be stepped, once that is done, it should go through TRACKING state and eventually go into LOCKED state. Once that happens, the system clock should start to sync with the NIC clock.
Add
global:log_status=yto the config file or command line and watch the/var/run/ptpd.statusfile - that will show you exactly what is going on. You can use the 'watch' command:watch -n 1 cat /var/run/ptpd.status.If you want it to sync quicker, you may want it to step the clock immediately rather than wait in STEP state.
Thanks,
Wojciech
Check the output of
ptpd -O: it will list all settings with descriptions and default values - look at theclock:section, you should find some options to help you sync the clock in less time.Hi,
I have kept the ptpd-2.3.2 client running for a long time but it does not seem to converge at all. It never really goes into LOCKED state. Upon looking at /var/run/ptpd.status file, I can see the client cycling through FREERUN -> STEP -> TRACKING; and then back to FREERUN and starts over.
I have tried modifying the hardware clock control PI (servo:), adding 'clock:step_startup_force = y', and lowering the value of 'servo:adev_locked_threshold_low_hw'. However, I have not seen any noticeable improvements.
Could this be a driver issue? I am using the Xilinx-provided driver (xilinx_emacps.c) for the Ethernet MAC of the Zynq-7000 SoC on the ZYBO board.
Thanks,
Jorge Sanchez
Jorge,
What are the offsets looking like?
When you send the process a SIGUSR2, it will dump all counters to the log, see if any error counters are incrementing.
Yes, this could be a driver issue. I find it that most Linux PTP drivers are not that well tested.
The 2.3.2-hwtest branch is frozen now, current work is in:
https://github.com/wowczarek/ptpd/tree/wowczarek-2.3.2-libcck
If you could try running this code, and checking the counters with SIGUSR2 again.
Otherwise build that and edit src/libcck/cck_logger.h and uncomment #define CCK_DEBUG, otherwise running
make CFLAGS="-DCCK_DEBUG"- debug is quite verbose but it should at least show errors.You should increase the adev threshold, not lower it by the way, ideally looking at the adev value you are seeing in the most stable state (bottom of the status file).
Also note that some drivers don't like dot1q / VLAN tagging, not sure if that is present in your network or not. I wanted to ask if you are running multicast or not, but the driver reports HWTSTAMP_FILTER_ALL, which looks like it can timestamp all packets - whether this is true or not is a different story.
It may well be that there is no issue with packet timestamping but there are issues with clock adjustment, the debug log out of the libcck branch should shed some light on that.
Thanks,
Wojciech
Finally, this could be an issue with transmit timestamps only - try running with ptpengine:delay_mechanism=DELAY_DISABLED - then it will only be syntonising (no path delay calculation) - but it will not use any TX timestamps. But since you are using ZYBO on both ends (master and slave), the other end also does transmit timestamps for Sync messages.
Do you have a dedicated hardware grandmaster available for testing?