linuxptp-users Mailing List for linuxptp (Page 139)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: Stephan G. <ste...@gm...> - 2013-11-14 16:57:21
|
> I mean to keep this interface as the one and only way of controlling > ptp4l at run time. Other ways have been defined to control a PTP > service, like SNMP. If we ever support these, then it will be as a > separate program to handle SNMP requests and translate them into > management packets on the local UDS interface. > > So, I do view the UDS interface as "stable". Than it probably makes sense to go for the UDS interface. Some information like master_offset are updated very often. So it doesn't always make sense to run a script if "something" changes. Regards, Stephan |
|
From: Richard C. <ric...@gm...> - 2013-11-14 16:18:42
|
On Thu, Nov 14, 2013 at 08:32:36AM -0500, Rich Schmidt wrote: > > So there is no Spectracom code on the Supermicro ATOM server. It was not > running NTP during these tests. Okay, I just wanted to rule that out as a source of the weird big jumps or of the jitter. BTW, the Intel i210 card can time stamp any packet, and so it could be used with NTP just as well as with PTP. All you would need is an ntpd that supports the Linux SO_TIMESTAMPING socket option... Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2013-11-14 13:53:47
|
On Thu, Nov 14, 2013 at 08:32:36AM -0500, Rich Schmidt wrote: > I will check my kernel time config and report back. I did set hz=1000. I > am working on an NTP driver for the PHC steered by ptp4l. NTP has pretty > sophisticated filtering tracking Allan deviation of the input signal; of > course it is > 600,000 lines of C code... FWIW, the chrony NTP implementation already includes a PHC driver. It's in the latest version from git. chrony is usually able to synchronize the clock better than ntpd, YMMV. -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2013-11-14 12:40:00
|
On Thu, Nov 14, 2013 at 09:39:46AM +0100, Stephan Gatzka wrote: > Hi! > > > 1. Management message "push" option. This would let the ptp4l program > > send changed status messages on the UDS interface. > > This depends on if we consider the UDS interface stable. I mean to keep this interface as the one and only way of controlling ptp4l at run time. Other ways have been defined to control a PTP service, like SNMP. If we ever support these, then it will be as a separate program to handle SNMP requests and translate them into management packets on the local UDS interface. So, I do view the UDS interface as "stable". Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-11-14 12:32:23
|
On Thu, Nov 14, 2013 at 10:38:46AM +0100, Miroslav Lichvar wrote: > > I made some progress in investigation of the bug and I'll try to post > the results/patch soon. If you post to LKML then please put me on CC so that I can spot the thread. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-11-14 12:14:38
|
On Wed, Nov 13, 2013 at 09:07:39AM +0100, Richard Cochran wrote: > On Tue, Nov 12, 2013 at 02:28:38PM -0500, Rich Schmidt wrote: > > We use 16s update interval on our NTP servers that are synced to PTP time > > code using a Spectracom PCIe PTP card, and our system clock jitter is > > around 700 nanoseconds! Frequency changes due to temperature effects are > > not rapid in our environment. If you run adjtime too frequently you may > > end up chasing your tail. > > That seems like a surprisingly good figure. Do you have a way of > verifying it, or is this simply what their software tells you? Okay, I take it back. 700 nanoseconds is perfectly reasonable, provided your kernel isn't using CONFIG_NO_HZ_IDLE. Once I reboot using nohz=off then I get very good results using phc2sys. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-11-14 11:56:16
|
On Tue, Nov 12, 2013 at 12:08:58PM -0500, Rich Schmidt wrote:
>
> Even with the large phase offsets excluded, phc2sys performed poorly as a
> timing standard, 50 microseconds peak-peak, standard deviation 8.1
> microseconds. See phc2sys-offset.png and phc2sys-offs2.png for a look at
> the best data.
Rich,
Is your kernel configured with CONFIG_NO_HZ_IDLE?
That is the likely cause of the time error jitter.
Thanks,
Richard
PS. I think I have been referring to you as "Rick" in some other
mails. Please forgive me for that.
|
|
From: Richard C. <ric...@gm...> - 2013-11-14 11:50:25
|
On Thu, Nov 14, 2013 at 10:38:46AM +0100, Miroslav Lichvar wrote: > > Any chance your kernel is running with nohz? You might get better > results with nohz=off. Yes, I just noticed that my test machine has CONFIG_NO_HZ_IDLE. I suspect that the NTP time accounting is broken in this case, when the machine load is light. With a heavy load (like compiling kernel with -j2, dual core) then the time jitter stays within 100 ns or so using: phc2sys -R 1 -P.1 -I.001 -N 25 I am right now recompiling with CONFIG_HZ_PERIODIC CONFIG_PREEMPT_NONE CONFIG_HZ_1000 and then I'll rerun the test. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2013-11-14 09:38:56
|
On Thu, Nov 14, 2013 at 10:16:57AM +0100, Richard Cochran wrote: > On Thu, Nov 14, 2013 at 10:01:17AM +0100, Richard Cochran wrote: > > Mine is a 32 bit Pentium D, and Rick's is an atom, IIRC. > > > > It looks to me like the VDSO is giving much different results. But we > > want to have phc2sys working well in both cases. > > I take it back. My setup is using the PTP_SYS_OFFSET ioctl. > > But still, I see much more jitter in the time error... Any chance your kernel is running with nohz? You might get better results with nohz=off. https://lkml.org/lkml/2012/10/11/343 I made some progress in investigation of the bug and I'll try to post the results/patch soon. -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2013-11-14 09:17:15
|
On Thu, Nov 14, 2013 at 10:01:17AM +0100, Richard Cochran wrote: > On Wed, Nov 13, 2013 at 01:41:37PM +0100, Miroslav Lichvar wrote: > > > > I tried to run the test with 32s interval on my test machine. When the > > CPU is idle: > > > > phc2sys[773832.254]: PI servo: sync interval 32.000 kp 0.022 ki 0.009375 > > phc2sys[773864.254]: sys offset -58 s0 freq +0 delay 4929 > > Your results look way better than mine. I guess that your machine is a > 64 bit OS with VDSO, right? > > Mine is a 32 bit Pentium D, and Rick's is an atom, IIRC. > > It looks to me like the VDSO is giving much different results. But we > want to have phc2sys working well in both cases. I take it back. My setup is using the PTP_SYS_OFFSET ioctl. But still, I see much more jitter in the time error... Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-11-14 09:01:30
|
On Wed, Nov 13, 2013 at 01:41:37PM +0100, Miroslav Lichvar wrote: > > I tried to run the test with 32s interval on my test machine. When the > CPU is idle: > > phc2sys[773832.254]: PI servo: sync interval 32.000 kp 0.022 ki 0.009375 > phc2sys[773864.254]: sys offset -58 s0 freq +0 delay 4929 Your results look way better than mine. I guess that your machine is a 64 bit OS with VDSO, right? Mine is a 32 bit Pentium D, and Rick's is an atom, IIRC. It looks to me like the VDSO is giving much different results. But we want to have phc2sys working well in both cases. Thanks, Richard |
|
From: Stephan G. <st...@ga...> - 2013-11-14 08:57:38
|
Hi! > 1. Management message "push" option. This would let the ptp4l program > send changed status messages on the UDS interface. This depends on if we consider the UDS interface stable. > 2. Run a script. This would let the ptp4l program run a shell script > after status changes, just like dhclient does. Looks promising to me. Regards, Stephan |
|
From: Richard C. <ric...@gm...> - 2013-11-14 08:33:28
|
On Wed, Nov 13, 2013 at 02:36:40PM +0100, Mario Molitor wrote: > > What do you think about this or do you have a better idea to get this information without poll pmc. I don't like the file idea, but I can suggest two alternatives: 1. Management message "push" option. This would let the ptp4l program send changed status messages on the UDS interface. 2. Run a script. This would let the ptp4l program run a shell script after status changes, just like dhclient does. Thoughts? Thanks, Richard |
|
From: Mario M. <mar...@we...> - 2013-11-13 13:36:48
|
Hallo PTP4l Members, Our measurement data unit need for some situation the current information about the grandmasterIdentity and currentUtcOffset. This information need our measurent data unit only in case of changing. I know that I can get this by the pmc application, but I not a realy friend of polling. I would prefer a file with information in /var/run e.g. ptp.info. In the combination with Inotify would by the application of our measurement unit inform by every change. The write of this file could be depend from new argument or now cfg file entry. What do you think about this or do you have a better idea to get this information without poll pmc. Best regards, Mario |
|
From: Miroslav L. <mli...@re...> - 2013-11-13 12:43:04
|
On Wed, Nov 13, 2013 at 09:07:39AM +0100, Richard Cochran wrote: > On Tue, Nov 12, 2013 at 02:28:38PM -0500, Rich Schmidt wrote: > > We use 16s update interval on our NTP servers that are synced to PTP time > > code using a Spectracom PCIe PTP card, and our system clock jitter is > > around 700 nanoseconds! Frequency changes due to temperature effects are > > not rapid in our environment. If you run adjtime too frequently you may > > end up chasing your tail. > > That seems like a surprisingly good figure. Do you have a way of > verifying it, or is this simply what their software tells you? It curious to what exactly "system clock jitter" means. I think there is a problem with his system clock or reading of the PHC. With a good system clock, keeping the reported offset below the PHC reading jitter at 16s interval shouldn't be really a problem. I tried to run the test with 32s interval on my test machine. When the CPU is idle: phc2sys[773832.254]: PI servo: sync interval 32.000 kp 0.022 ki 0.009375 phc2sys[773864.254]: sys offset -58 s0 freq +0 delay 4929 phc2sys[773896.254]: sys offset 58 s2 freq +24472 delay 4921 phc2sys[773928.254]: sys offset 135 s2 freq +24476 delay 4929 phc2sys[773960.255]: sys offset 170 s2 freq +24478 delay 4936 phc2sys[773992.255]: sys offset 277 s2 freq +24483 delay 4951 phc2sys[774024.255]: sys offset 232 s2 freq +24484 delay 4921 phc2sys[774056.255]: sys offset 19 s2 freq +24480 delay 4921 phc2sys[774088.255]: sys offset -244 s2 freq +24472 delay 4906 phc2sys[774120.255]: sys offset -298 s2 freq +24468 delay 4936 phc2sys[774152.255]: sys offset -115 s2 freq +24471 delay 4913 phc2sys[774184.256]: sys offset 99 s2 freq +24476 delay 4928 phc2sys[774216.256]: sys offset 390 s2 freq +24486 delay 4928 phc2sys[774248.256]: sys offset 399 s2 freq +24490 delay 4936 phc2sys[774280.256]: sys offset 239 s2 freq +24489 delay 4943 phc2sys[774312.256]: sys offset -107 s2 freq +24480 delay 4921 phc2sys[774344.256]: sys offset -262 s2 freq +24475 delay 4943 phc2sys[774376.257]: sys offset -404 s2 freq +24468 delay 4951 However, loading the CPU causes a rapid change in the frequency of the clock and it takes a while to settle down again: phc2sys[777864.273]: sys offset 229 s2 freq +24519 delay 4951 phc2sys[777896.273]: sys offset 158 s2 freq +24519 delay 4913 phc2sys[777928.273]: sys offset 183 s2 freq +24522 delay 4925 phc2sys[777960.273]: sys offset 255 s2 freq +24526 delay 4954 phc2sys[777992.273]: sys offset 371 s2 freq +24532 delay 4929 phc2sys[778024.273]: sys offset 546 s2 freq +24541 delay 4928 phc2sys[778056.274]: sys offset 814 s2 freq +24554 delay 4928 phc2sys[778088.274]: sys offset 1362 s2 freq +24579 delay 4936 phc2sys[778120.274]: sys offset 1743 s2 freq +24604 delay 4921 phc2sys[778152.274]: sys offset 1708 s2 freq +24619 delay 4929 phc2sys[778184.274]: sys offset 1789 s2 freq +24637 delay 4936 phc2sys[778216.274]: sys offset 1822 s2 freq +24655 delay 4921 phc2sys[778248.274]: sys offset 1840 s2 freq +24673 delay 4914 phc2sys[778280.275]: sys offset 1931 s2 freq +24693 delay 4928 phc2sys[778312.275]: sys offset 1832 s2 freq +24708 delay 4921 phc2sys[778344.275]: sys offset 1224 s2 freq +24706 delay 4936 The response would be better with more aggresive PI constants. > Also, does their servo converge rather slowly, like ntp? The PI servo should be able to give similar results to other servos if the constants are set well and there are no problems with unexpected changes in the frequency due to temperature, etc. See this graph from the simulator of time error vs reference clock jitter with differently scaled PI constants. Each set of the constants has a jitter/wander ratio where it performs best. chrony is included as an example of well performing adaptive loop. For any jitter/wander there are PI constants that will perform better than chrony adjusting its own loop automatically. http://mlichvar.fedorapeople.org/tmp/pi_poll5.png -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2013-11-13 08:46:46
|
On Tue, Nov 12, 2013 at 12:08:58PM -0500, Rich Schmidt wrote: > In an 18 hour test of phc2sys with these parameters: > numactl --physcpubind=0 --localalloc phc2sys -s /dev/ptp1 -l 7 -R 0.03125 > -O 0 -P 0.022 -I 0.004 > on four occasions phc2sys failed with large phase offsets (19.55 hours!). Thanks for running these tests and posting the results. The strange events are very infrequent. I'll see if I can set up a longer test with my own 82574 card. The big jumps definitely look like either a driver, kernel, or main board issue, or that someone is messing with the system time. Are you sure that the Spectracom drivers/libraries/services are not interfering in some way? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-11-13 08:34:05
|
On Tue, Nov 12, 2013 at 02:28:38PM -0500, Rich Schmidt wrote: > We use 16s update interval on our NTP servers that are synced to PTP time > code using a Spectracom PCIe PTP card, and our system clock jitter is > around 700 nanoseconds! Frequency changes due to temperature effects are > not rapid in our environment. If you run adjtime too frequently you may > end up chasing your tail. Regarding Spectracom, you are talking about their TimeKeeper software, right? >From the description on their web site it sounds like they are keeping their own time in user space. They say their product does not require user space or kernel modifications (but I suppose must require loading a driver for their card). It is likely that they are intercepting calls to the C library functions (like gettimeofday) via LD_PRELOAD. In any case, in order to avoid comparing apples with oranges, I just what to make it clear that phc2sys is adjusting the Linux system time via the standard adjtimex system call. Looking at your nov11-12.txt, it takes about 4.7 microseconds to read the time from your PCIe card once. That is why the claim of 700 ns jitter is surprising to me. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-11-13 08:07:51
|
On Tue, Nov 12, 2013 at 02:28:38PM -0500, Rich Schmidt wrote: > We use 16s update interval on our NTP servers that are synced to PTP time > code using a Spectracom PCIe PTP card, and our system clock jitter is > around 700 nanoseconds! Frequency changes due to temperature effects are > not rapid in our environment. If you run adjtime too frequently you may > end up chasing your tail. That seems like a surprisingly good figure. Do you have a way of verifying it, or is this simply what their software tells you? Also, does their servo converge rather slowly, like ntp? Thanks, Richard |
|
From: Rich S. <sch...@gm...> - 2013-11-12 19:28:46
|
We use 16s update interval on our NTP servers that are synced to PTP time code using a Spectracom PCIe PTP card, and our system clock jitter is around 700 nanoseconds! Frequency changes due to temperature effects are not rapid in our environment. If you run adjtime too frequently you may end up chasing your tail. Rich Schmidt Time Service Dept. US Naval Observatory On Tue, Nov 12, 2013 at 1:07 PM, Miroslav Lichvar <mli...@re...>wrote: > On Tue, Nov 12, 2013 at 12:08:58PM -0500, Rich Schmidt wrote: > > In an 18 hour test of phc2sys with these parameters: > > numactl --physcpubind=0 --localalloc phc2sys -s /dev/ptp1 -l 7 -R 0.03125 > > -O 0 -P 0.022 -I 0.004 > > > Even with the large phase offsets excluded, phc2sys performed poorly as a > > timing standard, 50 microseconds peak-peak, standard deviation 8.1 > > microseconds. See phc2sys-offset.png and phc2sys-offs2.png for a look at > > the best data. > > Just curious, why are you using 32s update interval? If the clock is > not very stable (e.g. rapid changes in the temperature), you may be > hitting the limit of what's possible. I'd expect better results with a > shorter interval. > > -- > Miroslav Lichvar > |
|
From: Miroslav L. <mli...@re...> - 2013-11-12 18:09:20
|
On Tue, Nov 12, 2013 at 12:08:58PM -0500, Rich Schmidt wrote: > In an 18 hour test of phc2sys with these parameters: > numactl --physcpubind=0 --localalloc phc2sys -s /dev/ptp1 -l 7 -R 0.03125 > -O 0 -P 0.022 -I 0.004 > Even with the large phase offsets excluded, phc2sys performed poorly as a > timing standard, 50 microseconds peak-peak, standard deviation 8.1 > microseconds. See phc2sys-offset.png and phc2sys-offs2.png for a look at > the best data. Just curious, why are you using 32s update interval? If the clock is not very stable (e.g. rapid changes in the temperature), you may be hitting the limit of what's possible. I'd expect better results with a shorter interval. -- Miroslav Lichvar |
|
From: Rich S. <sch...@gm...> - 2013-11-12 17:09:08
|
Nov 11 21:42:50 2757.866 261267301 s0 freq +0 4722 Nov 11 21:43:22 2789.866 277500554 s1 freq +7285 4722 Nov 11 21:43:54 2821.867 3462 +7375 4715 Nov 11 21:44:26 2853.867 5913 +7453 4710 ... Nov 11 23:12:26 8133.897 -12638 +7082 4711 Nov 11 23:12:58 8165.897 10997 +7645 4719 Nov 11 23:13:30 8197.897 -70368744166426 -500000 4720 Nov 11 23:14:02 8229.897 3518453432642 +500000 4717 Nov 11 23:14:34 8261.897 3512213078157 +500000 4704 Nov 11 23:15:06 8293.898 3492986001963 +500000 4707 ... Nov 11 23:55:38 10725.911 2031727550676 +500000 4787 Nov 11 23:56:10 10757.911 2012500472205 +500000 4702 ... Nov 12 00:34:34 13061.923 628150600222 +500000 4697 Nov 12 00:35:06 13093.923 608923535029 +500000 4707 Nov 12 00:35:38 13125.923 -69779047728383 -500000 4703 Nov 12 00:36:10 13157.923 -2315629608 -500000 4712 Nov 12 00:36:42 13189.924 -2364688921 -500000 4698 ... Nov 12 02:06:50 18597.958 21561 +7597 4710 Nov 12 02:07:22 18629.958 18370 +7600 4710 Nov 12 02:07:54 18661.959 13352 +7543 4711 Nov 12 02:08:26 18693.959 11357 +7545 4715 Nov 12 02:08:58 18725.959 8546 +7517 4705 Nov 12 02:09:30 18757.959 7370 +7521 4720 Nov 12 02:10:02 18789.959 3376 +7446 4710 Nov 12 02:10:34 18821.959 5736 +7521 4700 Nov 12 02:11:06 18853.960 2087 +7449 4726 Nov 12 02:12:42 18949.960 554 +7444 4830 Nov 12 02:13:14 18981.960 -187 +7427 4700 Nov 12 02:13:46 19013.961 3278 +7516 4715 Nov 12 02:14:18 19045.961 -979 +7418 4711 ... Nov 12 02:26:34 19781.965 -2503 +7397 4701 Nov 12 02:27:06 19813.965 -986 +7426 4701 Nov 12 02:27:38 19845.965 4347 +7561 4720 Nov 12 02:28:10 19877.965 -70368744179149 -500000 4710 Nov 12 02:28:42 19909.966 3518453449519 +500000 4711 Nov 12 02:29:14 19941.966 3506419020568 +500000 4857 Nov 12 02:29:46 19973.966 3487191947960 +500000 4697 ... Nov 12 03:17:46 22853.979 1756756010257 +500000 4687 Nov 12 03:18:18 22885.979 1737528941707 +500000 4717 ... Nov 12 04:11:06 26053.999 -963261146 -500000 4712 Nov 12 04:11:38 26085.999 -947030769 -500000 4702 Nov 12 04:12:10 26118.000 -930800188 -500000 4722 Nov 12 04:12:42 26150.000 -70369658744841 -500000 4722 Nov 12 04:13:14 26182.000 -898334456 -500000 4723 ... Nov 12 04:53:14 28582.017 31184 +7742 4705 Nov 12 04:53:46 28614.017 16720 +7491 4700 Nov 12 04:54:18 28646.017 21197 +7674 4705 Nov 12 04:54:50 28678.017 11083 +7496 4705 Nov 12 04:55:22 28710.017 12842 +7586 4700 Nov 12 04:55:54 28742.018 8813 +7533 4720 Nov 12 04:56:26 28774.018 8074 +7549 4715 Nov 12 04:56:58 28806.018 4479 +7488 4720 Nov 12 04:57:30 28838.018 5512 +7533 4704 ... Nov 12 05:05:30 29318.021 1148 +7492 4720 Nov 12 05:06:02 29350.021 -1275 +7433 4705 Nov 12 05:06:34 29382.021 2896 +7537 4710 Nov 12 05:07:06 29414.021 344 +7482 4720 Nov 12 05:07:38 29446.022 798 +7495 4700 ... Nov 12 06:31:22 34470.050 -1427 +7465 4710 Nov 12 06:31:54 34502.050 7969 +7703 4710 Nov 12 06:32:26 34534.050 94 +7531 4710 Nov 12 06:32:58 34566.051 -1839 +7481 4720 Nov 12 06:33:30 34598.051 -70368744178218 -500000 4710 Nov 12 06:34:02 34630.051 16225279 +429378 4712 Nov 12 06:34:34 34662.051 2715379 +143022 4703 Nov 12 06:35:06 34694.051 -1613228 +41340 4714 Nov 12 06:35:38 34726.052 -2698087 +6681 4699 Nov 12 06:36:10 34758.052 -2668799 -3350 4709 Nov 12 06:36:42 34790.052 -2331560 -5257 4710 Nov 12 06:37:14 34822.052 -1918316 -3839 4710 Nov 12 06:37:46 34854.052 -1554358 -2049 4711 Nov 12 06:38:18 34886.053 -1249295 -335 4711 ... Nov 12 06:54:50 35878.058 -1772 +7460 4710 Nov 12 06:55:22 35910.058 2787 +7572 4720 Nov 12 06:55:54 35942.059 -1782 +7464 4705 Nov 12 06:56:26 35974.059 -2391 +7441 4689 Nov 12 06:56:58 36006.059 349 +7503 4710 Nov 12 06:57:30 36038.059 882 +7518 4720 Nov 12 06:58:02 36070.059 3952 +7602 4715 Nov 12 06:58:34 36102.059 -7383 +7323 4706 Nov 12 06:59:06 36134.060 9864 +7742 4709 ... Nov 12 11:49:46 53574.156 471 +7491 4710 Nov 12 11:50:18 53606.156 18413 +7959 4699 Nov 12 11:50:50 53638.156 7464 +7748 4699 Nov 12 11:51:22 53670.157 -13980 +7221 4705 Nov 12 11:51:54 53702.157 -10936 +7244 4720 Nov 12 11:52:26 53734.157 -4285 +7373 4871 Nov 12 11:52:58 53766.157 -4120 +7360 4720 Nov 12 11:53:30 53798.157 7780 +7653 4700 Nov 12 11:54:02 53830.157 14539 +7860 4699 Nov 12 11:54:34 53862.158 -70368744196527 -500000 4791 Nov 12 11:55:06 53894.158 16243645 +429875 4712 Nov 12 11:55:38 53926.158 2725650 +143382 4687 Nov 12 11:56:10 53958.158 -1634519 +40920 4719 ... Nov 12 12:25:30 55718.168 12079 +7799 4869 Nov 12 12:26:02 55750.168 -15486 +7130 4710 ... Nov 12 12:28:10 55878.169 831 +7576 4720 Nov 12 12:28:42 55910.169 4129 +7665 4820 Nov 12 12:29:14 55942.169 -17983 +7107 4790 ... Nov 12 15:52:58 68166.235 2546 +7603 4865 Nov 12 15:53:30 68198.236 1091 +7575 4700 Nov 12 15:54:02 68230.236 -3903 +7450 4710 Nov 12 15:54:34 68262.236 -4744 +7412 4720 Nov 12 15:55:06 68294.236 5526 +7660 4700 |
|
From: Rich S. <sch...@gm...> - 2013-11-11 22:12:18
|
Nov 11 21:42:50 pluto phc2sys: [2757.866] phc offset 261267301 s0 freq +0 delay 4722 Nov 11 21:43:22 pluto phc2sys: [2789.866] phc offset 277500554 s1 freq +7285 delay 4722 Nov 11 21:43:54 pluto phc2sys: [2821.867] phc offset 3462 s2 freq +7375 delay 4715 Nov 11 21:44:26 pluto phc2sys: [2853.867] phc offset 5913 s2 freq +7453 delay 4710 Nov 11 21:44:58 pluto phc2sys: [2885.867] phc offset -491 s2 freq +7310 delay 4705 Nov 11 21:45:30 pluto phc2sys: [2917.867] phc offset 3465 s2 freq +7411 delay 4720 Nov 11 21:46:02 pluto phc2sys: [2949.867] phc offset 4888 s2 freq +7462 delay 4700 Nov 11 21:46:34 pluto phc2sys: [2981.867] phc offset -1083 s2 freq +7326 delay 4710 Nov 11 21:47:06 pluto phc2sys: [3013.868] phc offset 6008 s2 freq +7506 delay 4720 Nov 11 21:47:38 pluto phc2sys: [3045.868] phc offset 4738 s2 freq +7497 delay 4700 Nov 11 21:48:10 pluto phc2sys: [3077.868] phc offset 578 s2 freq +7408 delay 4710 Nov 11 21:48:42 pluto phc2sys: [3109.868] phc offset 1082 s2 freq +7423 delay 4700 Nov 11 21:49:14 pluto phc2sys: [3141.868] phc offset 1497 s2 freq +7438 delay 4705 Nov 11 21:49:46 pluto phc2sys: [3173.869] phc offset -1775 s2 freq +7359 delay 4709 Nov 11 21:50:18 pluto phc2sys: [3205.869] phc offset -2171 s2 freq +7342 delay 4715 Nov 11 21:50:50 pluto phc2sys: [3237.869] phc offset -1054 s2 freq +7362 delay 4705 Nov 11 21:51:22 pluto phc2sys: [3269.869] phc offset 466 s2 freq +7398 delay 4700 Nov 11 21:51:54 pluto phc2sys: [3301.869] phc offset 2186 s2 freq +7444 delay 4720 Nov 11 21:52:26 pluto phc2sys: [3333.869] phc offset -1351 s2 freq +7361 delay 4695 Nov 11 21:52:58 pluto phc2sys: [3365.870] phc offset -7468 s2 freq +7196 delay 4720 Nov 11 21:53:30 pluto phc2sys: [3397.870] phc offset 6053 s2 freq +7518 delay 4709 Nov 11 21:54:02 pluto phc2sys: [3429.870] phc offset -1937 s2 freq +7335 delay 4700 Nov 11 21:54:34 pluto phc2sys: [3461.870] phc offset 2551 s2 freq +7444 delay 4711 Nov 11 21:55:06 pluto phc2sys: [3493.870] phc offset 1067 s2 freq +7415 delay 4690 Nov 11 21:55:38 pluto phc2sys: [3525.871] phc offset -6052 s2 freq +7234 delay 4695 Nov 11 21:56:10 pluto phc2sys: [3557.871] phc offset 7692 s2 freq +7568 delay 4700 Nov 11 21:56:42 pluto phc2sys: [3589.871] phc offset 4897 s2 freq +7526 delay 4710 Nov 11 21:57:14 pluto phc2sys: [3621.871] phc offset -8351 s2 freq +7201 delay 4720 Nov 11 21:57:46 pluto phc2sys: [3653.871] phc offset 8703 s2 freq +7611 delay 4809 Nov 11 21:58:18 pluto phc2sys: [3685.871] phc offset -3012 s2 freq +7341 delay 4719 Nov 11 21:58:50 pluto phc2sys: [3717.872] phc offset -872 s2 freq +7385 delay 4719 Nov 11 21:59:22 pluto phc2sys: [3749.872] phc offset -2757 s2 freq +7332 delay 4710 Nov 11 21:59:54 pluto phc2sys: [3781.872] phc offset 506 s2 freq +7406 delay 4710 Nov 11 22:00:26 pluto phc2sys: [3813.872] phc offset -1086 s2 freq +7367 delay 4710 Nov 11 22:00:58 pluto phc2sys: [3845.872] phc offset 6962 s2 freq +7571 delay 4710 Nov 11 22:01:30 pluto phc2sys: [3877.873] phc offset -3331 s2 freq +7332 delay 4719 Nov 11 22:02:02 pluto phc2sys: [3909.873] phc offset -5253 s2 freq +7268 delay 4705 Nov 11 22:02:34 pluto phc2sys: [3941.873] phc offset -791 s2 freq +7363 delay 4720 Nov 11 22:03:06 pluto phc2sys: [3973.873] phc offset -78 s2 freq +7379 delay 4700 Nov 11 22:03:38 pluto phc2sys: [4005.873] phc offset -5569 s2 freq +7236 delay 4710 Nov 11 22:04:10 pluto phc2sys: [4037.873] phc offset 3904 s2 freq +7460 delay 4710 Nov 11 22:04:42 pluto phc2sys: [4069.874] phc offset -5725 s2 freq +7225 delay 4830 Nov 11 22:05:14 pluto phc2sys: [4101.874] phc offset 6031 s2 freq +7508 delay 4710 Nov 11 22:05:46 pluto phc2sys: [4133.874] phc offset 7248 s2 freq +7563 delay 4705 Nov 11 22:06:18 pluto phc2sys: [4165.874] phc offset -9122 s2 freq +7167 delay 4700 Nov 11 22:06:50 pluto phc2sys: [4197.874] phc offset 1891 s2 freq +7417 delay 4705 Nov 11 22:07:22 pluto phc2sys: [4229.875] phc offset -53 s2 freq +7374 delay 4711 Nov 11 22:07:54 pluto phc2sys: [4261.875] phc offset 4310 s2 freq +7487 delay 4705 Nov 11 22:08:26 pluto phc2sys: [4293.875] phc offset -1578 s2 freq +7351 delay 4719 Nov 11 22:08:58 pluto phc2sys: [4325.875] phc offset -6171 s2 freq +7225 delay 4711 Nov 11 22:09:30 pluto phc2sys: [4357.875] phc offset 2605 s2 freq +7429 delay 4710 Nov 11 22:10:02 pluto phc2sys: [4389.875] phc offset 4649 s2 freq +7492 delay 4689 |
|
From: Richard C. <ric...@gm...> - 2013-11-09 14:38:04
|
On Wed, Nov 06, 2013 at 08:26:26PM +0100, Richard Cochran wrote: > > I have a 82547 PCIe card, and I will see if I can reproduce this > effect. I ran my 82547 card in my old rack mounted Pentium dual core, with debian wheezy but with a custom, vanilla 3.11+ kernel. I couldn't see anything going wrong at all. Regarding the phc2sys servo performance (Rick mentioned off-list that he wanted one sample every 32 seconds and that the frequency offset looked too jittery), I think it is only a matter of choosing the right PI constants. The defaults of kp=0.7 and ki=0.3 are not good, I think, and I will post a patch for this. In the mean time, you can set the constants manually, for example: -P 0.022 -I 0.004 I appended a bit of the phc2sys log to show how it *should* be working. Thanks, Richard $ sudo ./phc2sys -s eth4 -O0 -m -q -l7 -R .03125 -P 0.022 -I 0.004 phc2sys[7543.139]: PI servo: sync interval 32.000 kp 0.022 ki 0.004000 phc2sys[7575.139]: sys offset 309 s0 freq +0 delay 4427 phc2sys[7607.140]: sys offset 7595 s1 freq -121370 delay 4421 phc2sys[7639.140]: sys offset -6397 s2 freq -121537 delay 4422 phc2sys[7671.140]: sys offset 3198 s2 freq -121313 delay 4428 phc2sys[7703.140]: sys offset -14547 s2 freq -121761 delay 4427 phc2sys[7735.140]: sys offset -2589 s2 freq -121509 delay 4427 phc2sys[7767.141]: sys offset -4859 s2 freq -121578 delay 4430 phc2sys[7799.141]: sys offset -580 s2 freq -121486 delay 4434 phc2sys[7831.141]: sys offset 9944 s2 freq -121215 delay 4421 phc2sys[7863.141]: sys offset -10701 s2 freq -121712 delay 4424 phc2sys[7895.141]: sys offset 878 s2 freq -121454 delay 4421 phc2sys[7927.142]: sys offset -197 s2 freq -121478 delay 4428 phc2sys[7959.142]: sys offset 5006 s2 freq -121344 delay 4421 phc2sys[7991.142]: sys offset -11600 s2 freq -121755 delay 4432 phc2sys[8023.142]: sys offset 4294 s2 freq -121388 delay 4427 phc2sys[8055.142]: sys offset 5382 s2 freq -121343 delay 4421 phc2sys[8087.142]: sys offset -9560 s2 freq -121710 delay 4429 phc2sys[8119.142]: sys offset -5780 s2 freq -121650 delay 4444 phc2sys[8151.142]: sys offset -6365 s2 freq -121688 delay 4421 phc2sys[8183.143]: sys offset 5942 s2 freq -121394 delay 4424 phc2sys[8215.143]: sys offset 3935 s2 freq -121422 delay 4434 phc2sys[8247.143]: sys offset -9148 s2 freq -121747 delay 4427 phc2sys[8279.143]: sys offset 5052 s2 freq -121414 delay 4429 phc2sys[8311.143]: sys offset 2501 s2 freq -121460 delay 4446 phc2sys[8343.143]: sys offset 4341 s2 freq -121402 delay 4422 phc2sys[8375.143]: sys offset 119 s2 freq -121495 delay 4429 phc2sys[8407.143]: sys offset -7465 s2 freq -121691 delay 4424 phc2sys[8439.143]: sys offset 12213 s2 freq -121210 delay 4426 phc2sys[8471.144]: sys offset -1892 s2 freq -121527 delay 4421 phc2sys[8503.144]: sys offset -6495 s2 freq -121655 delay 4421 phc2sys[8535.144]: sys offset -11090 s2 freq -121800 delay 4422 |
|
From: Richard C. <ric...@gm...> - 2013-11-07 07:36:41
|
On Wed, Nov 06, 2013 at 05:06:57PM -0500, Rich Schmidt wrote: > I redefined CURRENT_UTC_OFFSET to zero for testing ptp4l without phc2sys: > > nice --20 $PWD/ptp4l -S -i eth1 -l 7 -s -p /dev/ptp1 > > The ptp4l master offset of the CLOCK_REALTIME shows a high jitter, > 26.5 microsec peak-peak, 5.5 microsecs s.d. Smoothing would greatly > improve this; I would like to write an NTP driver based on ptp4l and let > it filter the results rather than having it steer CLOCK_REALTIME. This jitter sounds about right for SW time stamping. You can make it worse by adding a high system load. Also, the nice command probably will not improve things as the time stamps are made in kernel context (but it doesn't hurt either). Before implementing a filter, you can simply use smaller PI weights as a first attempt. In a project a few years back, we came to the conclusion that the filter in the original ptpd code was not really helping too much. In any case, I only suggested to try SW time stamping in order to characterize the source of the time jumping problems you report. If you see the same effect with SW time stamping, then this indicates a problem in ptp4l or in your grand master. If you see the effect only with HW time stamping, then it is likely to be a driver issue. Thanks, Richard |
|
From: Rich S. <sch...@gm...> - 2013-11-06 20:30:07
|
Richard thanks for the suggestions.
I have been running ptp4l alone (hardware stamping) for about 2 hrs 45m
with no phase jumps. Now I'm testing ptp4l -S , but in fact my PTP from
the FEI-Zyfer Gsync is in UTC, not PTP, and ptp4l thinks otherwise, so it
set the system clock ahead 35 seconds.
Yes kernel 3.12 has e1000e driver 2.3.2. I built it from
kernel.orgsource. I downloaded 2.5.4 from Intel and loaded it as a
module (only mode
supported by Intel for that version.)
# 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)
...
Nov 6 20:22:05 pluto ptp4l: [448891.338] master offset -215 s2
freq +7423 path delay 41013
Nov 6 20:22:07 pluto ptp4l: [448893.338] master offset 1614 s2
freq +7573 path delay 41013
Nov 6 20:22:09 pluto ptp4l: [448895.338] master offset -2071 s2
freq +7271 path delay 41013
Nov 6 20:22:11 pluto ptp4l: [448897.338] master offset 5175 s2
freq +7867 path delay 40792
Nov 6 20:22:13 pluto ptp4l: [448899.338] master offset 2514 s2
freq +7654 path delay 40792
Nov 6 20:22:15 pluto ptp4l: [448901.339] master offset 4204 s2
freq +7797 path delay 40792
Nov 6 20:22:17 pluto ptp4l: [448903.338] master offset 3497 s2
freq +7744 path delay 40792
...
Rich
On Wed, Nov 6, 2013 at 2:23 PM, Richard Cochran <ric...@gm...>wrote:
> A couple of things to try, below...
>
> On Tue, Nov 05, 2013 at 04:26:21PM -0500, Rich Schmidt wrote:
>
> > Intel 82547L NICs driver: e1000e version: 2.5.4-NAPI
> firmware-version: 1.9-0
> > Debian with kernel 3.12.0-rc
>
> 1. This driver also supports software time stamping. So please try
> 'ptp4l -S' and no phc2sys. (In this case, ptp4l will adjust the
> Linux system clock.) If that works without the jumps, then the
> issue is most likely a driver or kernel issue.
>
> 2. You gave the e1000e version as 2.5.4, but in the kernel source
> drivers/net/ethernet/intel/e1000e/netdev.c I see version 2.3.2, so
> you must using the SF drivers. You might also try the driver from
> the kernel.
>
> 3. Are you using your own kernel.org kernel build from source? If so,
> that is good, but you should know that v3.12 has been released, and
> it is better to drop the -rc kernel.
>
> Thanks,
> Richard
>
>
|
27 messages has been excluded from this view by a project administrator.
