Thread: [Linuxptp-users] Installation of Linuxptp on Ubuntu PC
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: Guo H. <gh...@gm...> - 2015-08-28 19:23:59
|
Hi Richard, I am new to Linuxptp as well as the Ubuntu / Linux system. Could please provide more details on how to install Linuxptp on Ubuntu? I tried to compile the Ubuntu kernel but cannot find any option such as "configure_pps" after command make menuconfig. So could you please tell me how to move forward from the kernel part? Thank you very much for your help. Best regards, Hao |
From: Richard C. <ric...@gm...> - 2015-08-28 20:39:10
|
On Fri, Aug 28, 2015 at 08:23:51PM +0100, Guo Hao wrote: > So could you please tell me how to move forward from the kernel part? > Thank you very much for your help. You do not need to compile the kernel if it is new enough. Tell us the output of this command: uname -a Thanks, Richard |
From: Guo H. <gh...@gm...> - 2015-08-28 21:59:44
|
Hi Richard, Thanks a lot for the reply. The output of uname -a is: hao@Hao-Ubuntu:~$ uname -a Linux Hao-Ubuntu 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Best regards, Hao On 28 August 2015 at 22:56, Guo Hao <gh...@gm...> wrote: > Hi Richard, > > Thanks a lot for the reply. > > The output of uname -a is: > > hao@Hao-Ubuntu:~$ uname -a > Linux Hao-Ubuntu 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 > 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > > Best regards, > Hao > > > On 28 August 2015 at 21:39, Richard Cochran <ric...@gm...> > wrote: > >> On Fri, Aug 28, 2015 at 08:23:51PM +0100, Guo Hao wrote: >> > So could you please tell me how to move forward from the kernel part? >> > Thank you very much for your help. >> >> You do not need to compile the kernel if it is new enough. >> >> Tell us the output of this command: >> >> uname -a >> >> Thanks, >> Richard >> > > |
From: Guo H. <gh...@gm...> - 2015-08-30 21:28:23
|
Hi Richard, Thanks a lot for the clarification. #The ToD is really only telling your endace card the *approximate* date #and time. Your endace card phase locks (not just frequency locks) to #the PPS. Hence the working principle would be as: 1. The Endace card might get the ToD second (from NTP or PTP) before the accurate 1-PPS or after the 1-PPS 2. If the ToD second comes first then 1-PPS comes later, Endace card would record the ToD second and match that second to the moment when it really receives the 1-PPS. 3. If the 1-PPS comes first and ToD second comes later, Endace card would add some offset to the ToD second to make that align to the 1-PPS. Is my understanding correct or not? Still not that clear on how the Endace card coordinate NTP ToD with PPS and can you give more clues? > As far as I know, the GPS clock might already did something about the > egress and ingress latency. # And just how do you know that? # It cannot possibly know the ingress latency of the Endace card.) Sorry to confuse you. What I want to say is that the GPS clock would have already compensate the egress latency of the PTP messages introduced by itself as well as the ingress latency of the PTP messages introduced by itself. It is for sure that the GPS clock does not know the ingress latency of the Endace card. According to the one of the GPS clock manufacturer, their egress latency should be less than 100 ns. To sum up the installation of Linuxptp on Ubuntu: 1. Check the kernel version of Ubuntu by command "uname -a". Ubuntu 14.04 kernel version 3.16 has already supported PTP features and there is no need to compile own kernel. 2. Check whether the Network Interface Card (NIC) supports hardware timestamping by command "ethtool -T eth0 (NIC name)". Intel 82574 NIC supports hardware timestamping. 3. Download Linuxptp source code (tarball) from http://linuxptp.sourceforge.net/ 4. Untar the tarball and change to the directory; then type command "make" to compile the source code 5. Check whether the program works by command "./ptp4l -E -2 -H -i eth0 -m -q"; for help menu of ptp4l, type "./ptp4l -h" 6. Install the the source code by "make install" 7. After successful installation of Linuxptp, could run program ptp4l, pmc and phc2sys directly from terminal / command line. 8. "ptp4l -h", "pmc -h", "pmc help" and "phc2sys -h" for help of the programs ptp4l, pmc and phc2sys Best regards, Hao On 30 August 2015 at 15:01, Richard Cochran <ric...@gm...> wrote: > On Sat, Aug 29, 2015 at 08:35:56PM +0100, Guo Hao wrote: > > But what if there is certain time offset between GPS clock's ToD and host > > PC's ToD, say 3 us when the capture card gets its initial ToD from the > PC. > > Then even the capture has 1-PPS from the GPS clock, the timestamp > > difference would be in the range of 3 us? > > The ToD is really only telling your endace card the *approximate* date > and time. Your endace card phase locks (not just frequency locks) to > the PPS. > > Endace said: > > > Yes, your understanding is correct: the host clock sets the DAG’s initial > > TOD for time stamping and the PPS keeps the oscillator on the DAG from > > drifting. This way once the initial TOD is established if the DAG has > > proper sync the largest possible timing skew would be a few > > nanoseconds. > > and I said: > > > # so the ToD from the host is irrelevant. The capture has the GPS's > > # 1-PPS, and so the phase of its time stamps should be correct to a few > > # hundred nanoseconds. > > See how you got the same answer twice? > > > As far as I know, the GPS clock might already did something about the > > egress and ingress latency. > > And just how do you know that? > > (It cannot possibly know the ingress latency of the Endace card.) > > > Therefore, I guess most of the latency might be introduced by the capture > > card. > > Could be. > > Cheers, > Richard > |
From: Richard C. <ric...@gm...> - 2015-08-31 08:22:23
|
On Sun, Aug 30, 2015 at 10:28:15PM +0100, Guo Hao wrote: > Hence the working principle would be as: > 1. The Endace card might get the ToD second (from NTP or PTP) before the > accurate 1-PPS or after the 1-PPS > 2. If the ToD second comes first then 1-PPS comes later, Endace card would > record the ToD second and match that second to the moment when it really > receives the 1-PPS. > 3. If the 1-PPS comes first and ToD second comes later, Endace card would > add some offset to the ToD second to make that align to the 1-PPS. > > Is my understanding correct or not? Yes, I think so. > Still not that clear on how the Endace card coordinate NTP ToD with PPS and > can you give more clues? You can always ask Endace how their card works... Thanks, Richard |
From: Richard C. <ric...@gm...> - 2015-08-29 08:17:40
|
On Fri, Aug 28, 2015 at 10:59:37PM +0100, Guo Hao wrote: > hao@Hao-Ubuntu:~$ uname -a > Linux Hao-Ubuntu 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 > 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Ok, so your kernel is new enough, and I guess that the ubuntu kernel does include PTP support. Now, check your network interfaces for time stamping support: ethtool -T eth0 ethtool -T eth1 ... Post the output of these commands. Thanks, Richard |
From: Guo H. <gh...@gm...> - 2015-08-29 11:19:32
|
Hi Richard, i have 2 Intel 82547 NICs and they should support hardware timestamping. Please see below the output of ethtool -T ethx: hao@Hao-Ubuntu:~$ ethtool -T eth0 Time stamping parameters for eth0: 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: 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) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) 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) hao@Hao-Ubuntu:~$ hao@Hao-Ubuntu:~$ ethtool -T eth1 Time stamping parameters for eth1: 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) all (HWTSTAMP_FILTER_ALL) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) 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) Best regards, Hao On 29 August 2015 at 09:17, Richard Cochran <ric...@gm...> wrote: > On Fri, Aug 28, 2015 at 10:59:37PM +0100, Guo Hao wrote: > > hao@Hao-Ubuntu:~$ uname -a > > Linux Hao-Ubuntu 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 > > 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > Ok, so your kernel is new enough, and I guess that the ubuntu kernel > does include PTP support. > > Now, check your network interfaces for time stamping support: > > ethtool -T eth0 > ethtool -T eth1 > ... > > Post the output of these commands. > > Thanks, > Richard > > |
From: Richard C. <ric...@gm...> - 2015-08-29 12:59:24
|
On Sat, Aug 29, 2015 at 12:19:25PM +0100, Guo Hao wrote: > Hi Richard, > > i have 2 Intel 82547 NICs and they should support hardware timestamping. ^^^^^ 82574 ? > Please see below the output of ethtool -T ethx: Ok, then: - Download and untar the linuxptp sources. - Change into the directory. - Type "make" Then, run the program: ./ptp4l -m -q -i eth0 HTH, Richard |
From: Guo H. <gh...@gm...> - 2015-08-29 13:18:16
|
Hi Richard, Thanks a lot for the help. Sorry I make a mistake. It should be Intel 82574 NIC. Will try to install the linuxptp now. Best regards, Hao On 29 August 2015 at 13:59, Richard Cochran <ric...@gm...> wrote: > On Sat, Aug 29, 2015 at 12:19:25PM +0100, Guo Hao wrote: > > Hi Richard, > > > > i have 2 Intel 82547 NICs and they should support hardware timestamping. > ^^^^^ > 82574 ? > > > Please see below the output of ethtool -T ethx: > > Ok, then: > > - Download and untar the linuxptp sources. > - Change into the directory. > - Type "make" > > Then, run the program: > > ./ptp4l -m -q -i eth0 > > > HTH, > Richard > > |
From: Guo H. <gh...@gm...> - 2015-08-29 17:10:05
|
Hi Richard, Finally, I can make the ptp4l program works and the output of ptp4l -E -2 -H -i eth0 -m -q is shown as below: ptp4l[7709.666]: master offset -46 s2 freq +3798 path delay 828 ptp4l[7710.667]: master offset 68 s2 freq +3898 path delay 828 ptp4l[7711.669]: master offset 40 s2 freq +3890 path delay 831 ptp4l[7712.672]: master offset 41 s2 freq +3903 path delay 831 ptp4l[7713.678]: master offset 43 s2 freq +3918 path delay 831 ptp4l[7714.679]: master offset -77 s2 freq +3810 path delay 831 ptp4l[7715.679]: master offset 41 s2 freq +3905 path delay 831 ptp4l[7716.685]: master offset 39 s2 freq +3916 path delay 830 ptp4l[7717.689]: master offset -52 s2 freq +3836 path delay 830 ptp4l[7718.692]: master offset -34 s2 freq +3839 path delay 829 ptp4l[7719.695]: master offset -28 s2 freq +3835 path delay 828 ptp4l[7720.697]: master offset -50 s2 freq +3804 path delay 828 ptp4l[7721.701]: master offset 95 s2 freq +3934 path delay 828 ptp4l[7722.702]: master offset -27 s2 freq +3841 path delay 828 ptp4l[7723.703]: master offset -3 s2 freq +3857 path delay 828 ptp4l[7724.705]: master offset -33 s2 freq +3826 path delay 828 ptp4l[7725.709]: master offset -20 s2 freq +3829 path delay 827 ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay 825 Does this mean the clock offset between the 82574 NIC and the Master Clock is in the range less than 100 ns? After that I make install the linuxptp package and follow the instruction from Red Hat: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-Using_the_PTP_management_Client.html I can use the pmc and phc2sys utilities and the output of phc2sys -s eth0 -w -m -q is shown below: phc2sys[7981.691]: phc offset -70 s2 freq -22120 delay 13340 phc2sys[7982.691]: phc offset -81 s2 freq -22152 delay 13270 phc2sys[7983.691]: phc offset -46 s2 freq -22141 delay 13340 phc2sys[7984.691]: phc offset 70 s2 freq -22039 delay 13340 phc2sys[7985.692]: phc offset 48 s2 freq -22040 delay 13410 phc2sys[7986.692]: phc offset 19 s2 freq -22055 delay 13340 phc2sys[7987.692]: phc offset -23 s2 freq -22091 delay 13410 phc2sys[7988.692]: phc offset -47 s2 freq -22122 delay 13340 phc2sys[7989.692]: phc offset 11 s2 freq -22078 delay 14318 phc2sys[7990.692]: phc offset -14 s2 freq -22100 delay 13340 phc2sys[7991.693]: phc offset 27 s2 freq -22063 delay 13340 phc2sys[7992.693]: phc offset 237 s2 freq -21845 delay 13829 phc2sys[7993.693]: phc offset -220 s2 freq -22231 delay 13340 phc2sys[7994.693]: phc offset -71 s2 freq -22148 delay 13340 phc2sys[7995.693]: phc offset -188 s2 freq -22286 delay 16483 phc2sys[7996.693]: phc offset 188 s2 freq -21966 delay 13340 phc2sys[7997.694]: phc offset 119 s2 freq -21979 delay 13340 phc2sys[7998.694]: phc offset 14 s2 freq -22048 delay 13340 phc2sys[7999.694]: phc offset -87 s2 freq -22145 delay 13270 Does that mean the system time is synchronized to the ptp hardware clock on the 82574 NIC? However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu: root@Hao-Ubuntu:~# service ptp4l start ptp4l: unrecognized service root@Hao-Ubuntu:~# Any idea on this? I am carrying out a test on verify the timestamp accuracy of an Ethernet capture card. This card obtains the ToD info from the host PC while accept the 1-PPS signal to tick afterwards. The host PC is synchronized to the GPS clock via Linuxptp (PTP port 1 on GPS clock in use) and the Ethernet capture card gets the 1-PPS from the same GPS clock. Then I connect PTP port 2 of the GPS clock directly to the Ethernet capture card via 3 m RJ45 cable. When I compare the timestamp within the Follow_Up and the receipt timestamp of corresponding Sync by Ethernet capture card, the time difference is about 1.15 us, which might be not reasonable. I got similar result around 1.5 us before I used Linuxptp and I used NTP to sync the host pc with the GPS clock at that moment. Therefore, I doubt whether there is a inherent delay between the point when the Ethernet capture card request for the ToD and point the Ethernet capture card really gets the information or the system time is not synchronized by the hardware clock of the 82574 NIC. Thank you very much and look forward to your feedback soon. Best regards, Hao On 29 August 2015 at 13:59, Richard Cochran <ric...@gm...> wrote: > On Sat, Aug 29, 2015 at 12:19:25PM +0100, Guo Hao wrote: > > Hi Richard, > > > > i have 2 Intel 82547 NICs and they should support hardware timestamping. > ^^^^^ > 82574 ? > > > Please see below the output of ethtool -T ethx: > > Ok, then: > > - Download and untar the linuxptp sources. > - Change into the directory. > - Type "make" > > Then, run the program: > > ./ptp4l -m -q -i eth0 > > > HTH, > Richard > > |
From: Richard C. <ric...@gm...> - 2015-08-29 18:10:09
|
On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote: > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay > 825 > > Does this mean the clock offset between the 82574 NIC and the Master Clock > is in the range less than 100 ns? Yes. > Does that mean the system time is synchronized to the ptp hardware clock on > the 82574 NIC? Yes, but remember that there is probably some offset in the low microseconds range. The "delay" tells you that reading the PHC time over the PCIe bus takes about 13 microseconds. > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu: > > root@Hao-Ubuntu:~# service ptp4l start > ptp4l: unrecognized service > root@Hao-Ubuntu:~# > > Any idea on this? Just start the programs by hand. To start them automatically, one easy way is to put the commands into /etc/rc.local. > Therefore, I doubt whether there is a inherent delay between the point when > the Ethernet capture card request for the ToD and point the Ethernet > capture card really gets the information or the system time is not > synchronized by the hardware clock of the 82574 NIC. But you said, the Ethernet capture card gets the 1-PPS from the same GPS clock. so the ToD from the host is irrelevant. The capture has the GPS's 1-PPS, and so the phase of its time stamps should be correct to a few hundred nanoseconds. The ~1 usec difference is probably just the sum of the GPS device's egress latency and the capture card's ingress latency. The number is perfectly reasonable, if one or both of the devices has MAC time stamping. HTH, Richard |
From: Guo H. <gh...@gm...> - 2015-08-29 19:36:04
|
Hi Richard, Thanks a lot the reply. # so the ToD from the host is irrelevant. The capture has the GPS's # 1-PPS, and so the phase of its time stamps should be correct to a few # hundred nanoseconds. But what if there is certain time offset between GPS clock's ToD and host PC's ToD, say 3 us when the capture card gets its initial ToD from the PC. Then even the capture has 1-PPS from the GPS clock, the timestamp difference would be in the range of 3 us? Since the 1-PPS just trains the internal oscillator of the capture and its timestamp only ticks forward based on the 1-PPS. I am not sure whether my understanding is correct or not. Below is the feedback I got from the Endace support (DAG is the capture card): Hi Hao, Yes, your understanding is correct: the host clock sets the DAG’s initial TOD for time stamping and the PPS keeps the oscillator on the DAG from drifting. This way once the initial TOD is established if the DAG has proper sync the largest possible timing skew would be a few nanoseconds. If for some reason the delta between the DAG and the host clock becomes too great (1 second in older drivers, 0.5 seconds in newer drivers) the DAG card will automatically reset the TOD to the new value and resync. Other than that, the DAG will always maintain TOD based off of the initial start, with the PPS as it’s tick corrector. However, if the ToD does matter, then the result should be totally different when using NTP and PTP. That is a bit strange... # The ~1 usec difference is probably just the sum of the GPS device's # egress latency and the capture card's ingress latency. The number is # perfectly reasonable, if one or both of the devices has MAC time # stamping. As far as I know, the GPS clock might already did something about the egress and ingress latency. Therefore, I guess most of the latency might be introduced by the capture card. It is also interesting that when I use the capture card under Windows 7, it gave me the time difference in the range of 3.4 - 3.7 us. Best regards, Hao On 29 August 2015 at 19:09, Richard Cochran <ric...@gm...> wrote: > On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote: > > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay > > 825 > > > > Does this mean the clock offset between the 82574 NIC and the Master > Clock > > is in the range less than 100 ns? > > Yes. > > > Does that mean the system time is synchronized to the ptp hardware clock > on > > the 82574 NIC? > > Yes, but remember that there is probably some offset in the low > microseconds range. The "delay" tells you that reading the PHC time > over the PCIe bus takes about 13 microseconds. > > > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu: > > > > root@Hao-Ubuntu:~# service ptp4l start > > ptp4l: unrecognized service > > root@Hao-Ubuntu:~# > > > > Any idea on this? > > Just start the programs by hand. To start them automatically, one > easy way is to put the commands into /etc/rc.local. > > > Therefore, I doubt whether there is a inherent delay between the point > when > > the Ethernet capture card request for the ToD and point the Ethernet > > capture card really gets the information or the system time is not > > synchronized by the hardware clock of the 82574 NIC. > > But you said, > > the Ethernet capture card gets the 1-PPS from the same GPS clock. > > so the ToD from the host is irrelevant. The capture has the GPS's > 1-PPS, and so the phase of its time stamps should be correct to a few > hundred nanoseconds. > > The ~1 usec difference is probably just the sum of the GPS device's > egress latency and the capture card's ingress latency. The number is > perfectly reasonable, if one or both of the devices has MAC time > stamping. > > HTH, > Richard > > |
From: Richard C. <ric...@gm...> - 2015-08-30 14:01:14
|
On Sat, Aug 29, 2015 at 08:35:56PM +0100, Guo Hao wrote: > But what if there is certain time offset between GPS clock's ToD and host > PC's ToD, say 3 us when the capture card gets its initial ToD from the PC. > Then even the capture has 1-PPS from the GPS clock, the timestamp > difference would be in the range of 3 us? The ToD is really only telling your endace card the *approximate* date and time. Your endace card phase locks (not just frequency locks) to the PPS. Endace said: > Yes, your understanding is correct: the host clock sets the DAG’s initial > TOD for time stamping and the PPS keeps the oscillator on the DAG from > drifting. This way once the initial TOD is established if the DAG has > proper sync the largest possible timing skew would be a few > nanoseconds. and I said: > # so the ToD from the host is irrelevant. The capture has the GPS's > # 1-PPS, and so the phase of its time stamps should be correct to a few > # hundred nanoseconds. See how you got the same answer twice? > As far as I know, the GPS clock might already did something about the > egress and ingress latency. And just how do you know that? (It cannot possibly know the ingress latency of the Endace card.) > Therefore, I guess most of the latency might be introduced by the capture > card. Could be. Cheers, Richard |
From: 林志剛 <dun...@gm...> - 2015-08-30 06:55:48
|
so, the unit of master offset is nanosecond?how to convert to ppb? 2015/8/30 上午2:10於 "Richard Cochran" <ric...@gm...>寫道: > On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote: > > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay > > 825 > > > > Does this mean the clock offset between the 82574 NIC and the Master > Clock > > is in the range less than 100 ns? > > Yes. > > > Does that mean the system time is synchronized to the ptp hardware clock > on > > the 82574 NIC? > > Yes, but remember that there is probably some offset in the low > microseconds range. The "delay" tells you that reading the PHC time > over the PCIe bus takes about 13 microseconds. > > > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu: > > > > root@Hao-Ubuntu:~# service ptp4l start > > ptp4l: unrecognized service > > root@Hao-Ubuntu:~# > > > > Any idea on this? > > Just start the programs by hand. To start them automatically, one > easy way is to put the commands into /etc/rc.local. > > > Therefore, I doubt whether there is a inherent delay between the point > when > > the Ethernet capture card request for the ToD and point the Ethernet > > capture card really gets the information or the system time is not > > synchronized by the hardware clock of the 82574 NIC. > > But you said, > > the Ethernet capture card gets the 1-PPS from the same GPS clock. > > so the ToD from the host is irrelevant. The capture has the GPS's > 1-PPS, and so the phase of its time stamps should be correct to a few > hundred nanoseconds. > > The ~1 usec difference is probably just the sum of the GPS device's > egress latency and the capture card's ingress latency. The number is > perfectly reasonable, if one or both of the devices has MAC time > stamping. > > HTH, > Richard > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
From: Dale S. <dal...@gm...> - 2015-08-30 17:21:47
|
ppb is dimensionless, but one nanosecond is one ppb of a second, so... -Dale On Sun, Aug 30, 2015 at 2:55 AM, 林志剛 <dun...@gm...> wrote: > so, the unit of master offset is nanosecond?how to convert to ppb? > 2015/8/30 上午2:10於 "Richard Cochran" <ric...@gm...>寫道: > >> On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote: >> > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay >> > 825 >> > >> > Does this mean the clock offset between the 82574 NIC and the Master >> Clock >> > is in the range less than 100 ns? >> >> Yes. >> >> > Does that mean the system time is synchronized to the ptp hardware >> clock on >> > the 82574 NIC? >> >> Yes, but remember that there is probably some offset in the low >> microseconds range. The "delay" tells you that reading the PHC time >> over the PCIe bus takes about 13 microseconds. >> >> > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu: >> > >> > root@Hao-Ubuntu:~# service ptp4l start >> > ptp4l: unrecognized service >> > root@Hao-Ubuntu:~# >> > >> > Any idea on this? >> >> Just start the programs by hand. To start them automatically, one >> easy way is to put the commands into /etc/rc.local. >> >> > Therefore, I doubt whether there is a inherent delay between the point >> when >> > the Ethernet capture card request for the ToD and point the Ethernet >> > capture card really gets the information or the system time is not >> > synchronized by the hardware clock of the 82574 NIC. >> >> But you said, >> >> the Ethernet capture card gets the 1-PPS from the same GPS clock. >> >> so the ToD from the host is irrelevant. The capture has the GPS's >> 1-PPS, and so the phase of its time stamps should be correct to a few >> hundred nanoseconds. >> >> The ~1 usec difference is probably just the sum of the GPS device's >> egress latency and the capture card's ingress latency. The number is >> perfectly reasonable, if one or both of the devices has MAC time >> stamping. >> >> HTH, >> Richard >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Linuxptp-users mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > |
From: Guo H. <gh...@gm...> - 2015-08-30 21:27:42
|
Hi, I agree with Dale that ppb is dimensionless and it is a ratio. So 1 ns is 1 ppb of a second. Meanwhile, as far as I know, ppb and ppm are mainly used to indicate the stability of an oscillator. When we talk about ppb / ppm, it might be more related to the frequency. Best regards, Hao On 30 August 2015 at 07:55, 林志剛 <dun...@gm...> wrote: > so, the unit of master offset is nanosecond?how to convert to ppb? > 2015/8/30 上午2:10於 "Richard Cochran" <ric...@gm...>寫道: > >> On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote: >> > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay >> > 825 >> > >> > Does this mean the clock offset between the 82574 NIC and the Master >> Clock >> > is in the range less than 100 ns? >> >> Yes. >> >> > Does that mean the system time is synchronized to the ptp hardware >> clock on >> > the 82574 NIC? >> >> Yes, but remember that there is probably some offset in the low >> microseconds range. The "delay" tells you that reading the PHC time >> over the PCIe bus takes about 13 microseconds. >> >> > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu: >> > >> > root@Hao-Ubuntu:~# service ptp4l start >> > ptp4l: unrecognized service >> > root@Hao-Ubuntu:~# >> > >> > Any idea on this? >> >> Just start the programs by hand. To start them automatically, one >> easy way is to put the commands into /etc/rc.local. >> >> > Therefore, I doubt whether there is a inherent delay between the point >> when >> > the Ethernet capture card request for the ToD and point the Ethernet >> > capture card really gets the information or the system time is not >> > synchronized by the hardware clock of the 82574 NIC. >> >> But you said, >> >> the Ethernet capture card gets the 1-PPS from the same GPS clock. >> >> so the ToD from the host is irrelevant. The capture has the GPS's >> 1-PPS, and so the phase of its time stamps should be correct to a few >> hundred nanoseconds. >> >> The ~1 usec difference is probably just the sum of the GPS device's >> egress latency and the capture card's ingress latency. The number is >> perfectly reasonable, if one or both of the devices has MAC time >> stamping. >> >> HTH, >> Richard >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Linuxptp-users mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users >> > |