linuxptp-users Mailing List for linuxptp (Page 133)
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: Ronex D. <ron...@ya...> - 2014-08-06 09:57:44
|
Hello,
I have few queries related to linuxptp, as mentioned below:
1) I tried to run ptp4l application using command:
/home/ptp4l -i eth0 -p eth0 -m -P (ptp master)
But it fails with the following error message:
ptp4l[3505.127]: selected /dev/ptp0 as PTP clock
ptp4l[3505.166]: Failed to open /dev/ptp0: No such file or directory
failed to create a clock
I am trying to run it for arm architecture, and for this I have cross compiled kernel and linuxptp source.
This ('/dev/ptp0') device node is not present inside '/dev' directory. Please help me to understand who creates this node, I have ptp supported driver for the ethernet device.
If this device is supposed to be created by user then what is the MAJOR/MINOR number for /dev/ptp0 ?
And which driver manages/handles access to this node ?
2) I am also not able to understand the basic higher level abstract flow of how this application works ?
I think linux kernel has its own ptp driver implementation, So From the application does it use the linux user space API/system calls which further calls linux ptp driver functions (<linux_x.x>/drivers/ptp/), from which hardware ptp supported driver's functions are invoked ?
ptp4l(linuxptp app) ---> drivers/ptp ---> ethernet_driver_with_ptp_support
Regards,
Ronex
|
|
From: Richard C. <ric...@gm...> - 2014-07-29 07:18:54
|
On Tue, Jul 29, 2014 at 02:43:54PM +0800, Ronex Dicapriyo wrote: > Hello, > > I want to compile linuxptp for linux and ARM host, > But while compiling over linux it throws following errors: > > grep: /usr/include/linux/net_tstamp.h: No such file or directory > gcc -Wall -DVER=1.4-00063-gbdb6a35 -c -o ptp4l.o ptp4l.c > ptp4l.c:26:30: error: linux/net_tstamp.h: No such file or directory You need the kernel headers installed, and the kernel must be v3.0 or newer. See the sections, "System Requirements" and "Installation" in the README file. > I need steps for cross-compilation for arm architecture also. To cross compile, set the environment variables CROSS_COMPILE and KBUILD_OUTPUT. You set these in exactly the same way as when you cross compiled your kernel. > Further please also suggest that if I need to establish ptp master/slave > communication between two host in LAN, what are the steps that I need to follow for this. On the master host: ptp4l -m -q -i eth0 On the slave host: ptp4l -m -q -i eth0 -s Thanks, Richard |
|
From: Ronex D. <ron...@ya...> - 2014-07-29 06:57:10
|
Hello, I want to compile linuxptp for linux and ARM host, But while compiling over linux it throws following errors: grep: /usr/include/linux/net_tstamp.h: No such file or directory gcc -Wall -DVER=1.4-00063-gbdb6a35 -c -o ptp4l.o ptp4l.c ptp4l.c:26:30: error: linux/net_tstamp.h: No such file or directory ptp4l.c: In function ‘main’: ptp4l.c:343: error: ‘SOF_TIMESTAMPING_TX_SOFTWARE’ undeclared (first use in this function) ptp4l.c:343: error: (Each undeclared identifier is reported only once ptp4l.c:343: error: for each function it appears in.) ptp4l.c:344: error: ‘SOF_TIMESTAMPING_RX_SOFTWARE’ undeclared (first use in this function) ptp4l.c:345: error: ‘SOF_TIMESTAMPING_SOFTWARE’ undeclared (first use in this function) ptp4l.c:348: error: ‘SOF_TIMESTAMPING_TX_HARDWARE’ undeclared (first use in this function) ptp4l.c:349: error: ‘SOF_TIMESTAMPING_RX_HARDWARE’ undeclared (first use in this function) ptp4l.c:350: error: ‘SOF_TIMESTAMPING_SYS_HARDWARE’ undeclared (first use in this function) ptp4l.c:356: error: ‘SOF_TIMESTAMPING_RAW_HARDWARE’ undeclared (first use in this function) make: *** [ptp4l.o] Error 1 Can anyone please share the steps to compile linuxptp, and how it's supposed to use ? I need steps for cross-compilation for arm architecture also. Further please also suggest that if I need to establish ptp master/slave communication between two host in LAN, what are the steps that I need to follow for this. Regards,Ronex |
|
From: Miroslav L. <mli...@re...> - 2014-07-23 07:45:47
|
On Wed, Jul 23, 2014 at 02:36:24AM +0000, Dylan Davis wrote: > I was experimenting to see how far I could push PTP accuracy using software > timstamps. I have a simple test setup with a single master and a single slave, > configured to use the P2P delay mechanism. logSyncInterval on the master is set > to -8. -8 is an extremenly short update interval, I'm a bit surprised it still works. Did you use the default PI configuration? > Both systems have tickless kernel disabled (nohz=off). With both systems > idle I can reach around 2us rms offset and 15-20us peak offset. If I then fully > load all 4 cores of the slave (using the 'stress' program), after a brief spike > the accuracy of the synchronization actually *improves*, reaching 300-500ns rms > offset and around 3us peak offset. Removing the CPU load brings the offset back > to its original magnitude. In both cases the rms and max offset values are > consistent, with only occasional spikes. Interestingly, the reported delay under > load is 12us less than when unloaded. Beside what Richard has mentioned, I think it could be also the variability in the time it takes the CPU to wake up from various powersaving states. You can try setting the idle= or intel_idle.max_cstate= kernel options and see if that helps. -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2014-07-23 04:04:57
|
On Wed, Jul 23, 2014 at 02:36:24AM +0000, Dylan Davis wrote: > Interestingly, the reported delay under > load is 12us less than when unloaded. Hm.. > These results are unintuitive, and I can't come up with a solid explanation for > them. Assuming the reported offsets are accurate (which may be a poor > assumption), my best guess is that somehow the 'stress' workload is forcing > ptp4l to be scheduled more consistently, but that's only speculation. Can > anybody shed some light on what's happening here? The effects that you see are indeed unintuitive, and I have also seen improved timing behavior under high load. There are at least three different ways that a load might have this effect. 1. Cache Effects. The high load might cause more cache misses in the time stamping path in the driver, resulting in a longer duration between the packet arrival time and the SW time stamp, but with more consistent timing. 2. Driver and networking stack. Depending on how your MAC hardware works and how the driver is written, there can be long and variable delays between the time stamp point and the actual transmission or reception time. The load can cause more consistent run time behavior, but the details of how this happens can be hard to understand. 3. NTP. Due to bugs in the kernel's NTP servo, high load can improve the clock regulation. I have seen this with nohz=on, but there might be other problems in that code as well. This is an area in the kernel that is still wanting improvement. The 12 us smaller delay is a sign that the load is making the driver or the stack time stamps more consistent. Thanks, Richard |
|
From: Dylan D. <dh...@um...> - 2014-07-23 02:40:12
|
Hi! I was experimenting to see how far I could push PTP accuracy using software timstamps. I have a simple test setup with a single master and a single slave, configured to use the P2P delay mechanism. logSyncInterval on the master is set to -8. Both systems have tickless kernel disabled (nohz=off). With both systems idle I can reach around 2us rms offset and 15-20us peak offset. If I then fully load all 4 cores of the slave (using the 'stress' program), after a brief spike the accuracy of the synchronization actually *improves*, reaching 300-500ns rms offset and around 3us peak offset. Removing the CPU load brings the offset back to its original magnitude. In both cases the rms and max offset values are consistent, with only occasional spikes. Interestingly, the reported delay under load is 12us less than when unloaded. These results are unintuitive, and I can't come up with a solid explanation for them. Assuming the reported offsets are accurate (which may be a poor assumption), my best guess is that somehow the 'stress' workload is forcing ptp4l to be scheduled more consistently, but that's only speculation. Can anybody shed some light on what's happening here? I've attached the slave log for the test run below. Thanks, Dylan ptp4l[8649.834]: port 1: get_ts_info not supported ptp4l[8649.834]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[8649.834]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[8650.918]: port 1: new foreign master 0019b9.fffe.252000-1 ptp4l[8654.918]: selected best master clock 0019b9.fffe.252000 ptp4l[8654.918]: foreign master not using PTP timescale ptp4l[8654.918]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[8656.840]: rms 734578 max 744561 freq +26416 +/- 0 delay 39708 +/- 24 ptp4l[8657.848]: rms 736520 max 743539 freq +26416 +/- 0 delay 39638 +/- 0 ... ptp4l[8801.938]: rms 945773 max 964402 freq +26416 +/- 0 delay 39709 +/- 0 ptp4l[8802.730]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[8802.946]: rms 836497 max 955345 freq +26150 +/- 548 delay 39709 +/- 0 ptp4l[8803.954]: rms 1783 max 12258 freq +25241 +/- 902 delay 39713 +/- 0 ptp4l[8804.961]: rms 2157 max 14819 freq +25446 +/- 1045 delay 39717 +/- 0 ... ptp4l[8855.342]: rms 2248 max 16992 freq +25950 +/- 1166 delay 39664 +/- 0 ptp4l[8856.350]: rms 2161 max 16421 freq +25903 +/- 1129 delay 39664 +/- 0 START CPU LOAD ptp4l[8857.357]: rms 11941 max 23139 freq +22475 +/- 5440 delay 39743 +/- 0 ptp4l[8858.365]: rms 15882 max 21184 freq +17063 +/- 1244 delay 39743 +/- 0 ptp4l[8859.372]: rms 8949 max 12262 freq +20357 +/- 796 delay 39743 +/- 0 ptp4l[8860.380]: rms 4424 max 6615 freq +22570 +/- 580 delay 39619 +/- 0 ptp4l[8861.388]: rms 1683 max 3025 freq +23970 +/- 421 delay 39460 +/- 0 ptp4l[8862.395]: rms 3780 max 7212 freq +26205 +/- 1386 delay 34165 +/- 0 ptp4l[8863.403]: rms 7421 max 12901 freq +28606 +/- 1288 delay 28178 +/- 0 ptp4l[8864.410]: rms 6528 max 10496 freq +28518 +/- 400 delay 28178 +/- 0 ptp4l[8865.418]: rms 4527 max 5672 freq +27623 +/- 257 delay 27930 +/- 0 ptp4l[8866.426]: rms 3457 max 6476 freq +27161 +/- 279 delay 27592 +/- 0 ptp4l[8867.433]: rms 2612 max 4947 freq +26802 +/- 218 delay 27567 +/- 0 ptp4l[8868.441]: rms 1846 max 3771 freq +26454 +/- 206 delay 27567 +/- 0 ptp4l[8869.448]: rms 1467 max 4106 freq +26293 +/- 207 delay 27545 +/- 0 ptp4l[8870.456]: rms 1380 max 3813 freq +26274 +/- 234 delay 27545 +/- 0 ptp4l[8871.463]: rms 1086 max 3599 freq +26149 +/- 212 delay 27477 +/- 0 ptp4l[8872.471]: rms 1016 max 3528 freq +26143 +/- 196 delay 27389 +/- 0 ptp4l[8873.479]: rms 853 max 2890 freq +26082 +/- 177 delay 27359 +/- 0 ptp4l[8874.486]: rms 891 max 2639 freq +26124 +/- 182 delay 27359 +/- 0 ptp4l[8875.494]: rms 808 max 3244 freq +26071 +/- 230 delay 27359 +/- 0 ptp4l[8876.501]: rms 1039 max 11250 freq +26094 +/- 411 delay 27348 +/- 0 ptp4l[8877.509]: rms 815 max 4812 freq +26092 +/- 260 delay 27359 +/- 0 ptp4l[8878.517]: rms 720 max 3040 freq +26074 +/- 222 delay 27348 +/- 0 ptp4l[8879.524]: rms 635 max 3106 freq +26050 +/- 201 delay 27348 +/- 0 ptp4l[8880.532]: rms 875 max 8865 freq +26029 +/- 398 delay 27348 +/- 0 ptp4l[8881.539]: rms 538 max 2507 freq +26028 +/- 178 delay 27349 +/- 0 ... ptp4l[8948.041]: rms 414 max 2590 freq +26419 +/- 190 delay 27396 +/- 0 ptp4l[8949.049]: rms 478 max 2572 freq +26399 +/- 238 delay 27519 +/- 0 ptp4l[8950.056]: rms 329 max 2126 freq +26299 +/- 173 delay 27519 +/- 0 ptp4l[8951.064]: rms 329 max 836 freq +26360 +/- 169 delay 27519 +/- 0 ptp4l[8952.071]: rms 375 max 2201 freq +26392 +/- 185 delay 27442 +/- 0 END CPU LOAD ptp4l[8953.079]: rms 18781 max 31000 freq +35948 +/- 3220 delay 27543 +/- 0 ptp4l[8954.087]: rms 11567 max 21944 freq +32929 +/- 1356 delay 27561 +/- 0 ptp4l[8955.094]: rms 6487 max 18632 freq +30427 +/- 1190 delay 27561 +/- 0 ptp4l[8956.102]: rms 3574 max 20490 freq +28809 +/- 1182 delay 27997 +/- 0 ptp4l[8957.109]: rms 3211 max 13653 freq +26883 +/- 1625 delay 33853 +/- 0 ptp4l[8958.117]: rms 6117 max 15778 freq +24339 +/- 1348 delay 39216 +/- 0 ptp4l[8959.125]: rms 6791 max 16738 freq +23659 +/- 990 delay 39338 +/- 0 ptp4l[8960.132]: rms 5012 max 22610 freq +24594 +/- 1199 delay 39424 +/- 0 ptp4l[8961.140]: rms 3755 max 25494 freq +25219 +/- 1130 delay 39424 +/- 0 ptp4l[8962.147]: rms 2528 max 13296 freq +25792 +/- 899 delay 39424 +/- 0 ptp4l[8963.155]: rms 2324 max 14095 freq +25982 +/- 970 delay 39573 +/- 0 ptp4l[8964.163]: rms 2215 max 19140 freq +26043 +/- 971 delay 39730 +/- 0 ... ptp4l[9004.467]: rms 2661 max 22221 freq +26836 +/- 1388 delay 39727 +/- 0 ptp4l[9005.474]: rms 1767 max 14313 freq +26741 +/- 926 delay 39731 +/- 0 ptp4l[9006.482]: rms 1540 max 10717 freq +26625 +/- 813 delay 39700 +/- 0 ptp4l[9007.490]: rms 1804 max 14455 freq +26692 +/- 951 delay 39748 +/- 0 |
|
From: Richard C. <ric...@gm...> - 2014-06-18 06:57:55
|
On Wed, Jun 18, 2014 at 04:23:07AM +0000, Daniel Le wrote: > Hello, > > Is there any potential 1588/PTP patent infringement for using the linuxptp open source code? You should direct this question to your company's legal department. IANAL, Richard |
|
From: Daniel Le <dan...@ex...> - 2014-06-18 04:23:16
|
Hello, Is there any potential 1588/PTP patent infringement for using the linuxptp open source code? Thanks, Daniel |
|
From: Keller, J. E <jac...@in...> - 2014-05-13 23:25:17
|
On Tue, 2014-05-13 at 17:15 -0600, Mason Winsauer wrote: > Well this is all very good news. > > Are you actually seeing incorrect clock adjustment? The clocks > appear to > be in sync. Note that the output of ptp4l you show is actually > that > device becoming master, I am curious what the output of the > connected > PTP ports are, so we can see how the other end is faring. I > think mostly > you simply misinterpreted output of ptp4l. > > > I suppose not, if that is in fact the case. It would seem as though my > misinterpretation stemmed from the fact that when I actually tried to > transmit a UDP message, it was not able to see PTP evidence when > checking at packet scope. Wireshark reported the protocols used as > 'eth:ip:udp:data', though, correct me if I'm wrong, I would see > evidence both here and in other areas of a PTP stamp. It was a very > simple test, just writing a message through either Netcat > or /dev/udp/, so there's as good of a chance that my fallacy lies > there as anywhere else. > You would be seeing much different issues if the timestamps were not working. Note that generally, PTP hardware does not insert the timestamp into the packet, but rather returns it to the application via kernel subsystem. Your hardware may support in-packet timestamp insertion, but that requires being enabled in the driver. For that to occur, you would have to issue the correct IOCTL command to the device, and pass it the correct settings to enable in-packet timestamping, assuming the driver and hardware support it. You can however, check the results of a tcpdump/wireshark of a PTP sequence, and you should see the timestamps of the SYNC message in the payload of the FOLLOW-UP message. Thanks, Jake > > Again, thank you so very much for your help, > Mason > > > On Tue, May 13, 2014 at 4:50 PM, Keller, Jacob E > <jac...@in...> wrote: > On Tue, 2014-05-13 at 15:26 -0600, Mason Winsauer wrote: > > Hey guys, > > > > Hi there, > > It seems you mistook a sort of debug message output as an > error, when > infact it's part of normal operation. I believe a recent > commit into the > head of the project fixes this to be a debug instead of an > error, but I > will explain more below. > > > > > I know this is a common question, and have researched the > vast > > majority of similar questions, but there still isn't much > information > > for my configuration. Also, I'm brand new to PTP as a > concept, so > > please forgive my ignorance. I'll start with a quick rundown > of the > > current configuration, outputs of relevant programs, etc. > > > > > > OpenSuse 13.1, Custom built kernel 3.14.3-7-desktop > > All required PTP/PPS/PHY options enabled > > Broadcom NetXtreme 5720, > > Tigon3 driver version 3.136 > > LinuxPTP v. 1.4 > > > > > > -Output of '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) > > ptpv1-l4-event > (HWTSTAMP_FILTER_PTP_V1_L4_EVENT) > > ptpv2-l4-event > (HWTSTAMP_FILTER_PTP_V2_L4_EVENT) > > ptpv2-l2-event > (HWTSTAMP_FILTER_PTP_V2_L2_EVENT) > > > > > > -Output of 'pmc -u -b 0 'GET CURRENT_DATA_SET'' > > sending: GET CURRENT_DATA_SET > > 90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT > > CURRENT_DATA_SET > > stepsRemoved 0 > > offsetFromMaster 0.0 > > meanPathDelay 0.0 > > > > > > -Output of 'pmc -u -b 0 'GET TIME_STATUS_NP'' > > sending: GET TIME_STATUS_NP > > 90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT > TIME_STATUS_NP > > master_offset 0 > > ingress_time 0 > > cumulativeScaledRateOffset +1.000000000 > > scaledLastGmPhaseChange 0 > > gmTimeBaseIndicator 0 > > lastGmPhaseChange > 0x0000'0000000000000000.0000 > > gmPresent false > > gmIdentity 90b11c.fffe.2e1b2d > > > > > > > > -Output of 'ptp4l -S -i eth0 -m -l7' > > > Your command is correct, except that -l7 outputs *very* > verbose log > messages, and is completely unnecessary. Try with -l6 and you > should see > less cruft, but most of the useful output. > > > ptp4l[3401.186]: PI servo: sync interval 1.000 kp > 0.100 ki > > 0.001000 > > ptp4l[3401.186]: port 1: INITIALIZING to LISTENING > on > > INITIALIZE > > ptp4l[3401.186]: port 0: INITIALIZING to LISTENING > on > > INITIALIZE > > ptp4l[3407.916]: port 1: announce timeout > > ptp4l[3407.916]: port 1: LISTENING to MASTER on > > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > ptp4l[3407.916]: selected best master clock > 90b11c.fffe.2e1b2d > > ptp4l[3407.916]: assuming the grand master role > > ptp4l[3407.917]: port 1: master tx announce timeout > > ptp4l[3407.918]: port 1: setting asCapable > > ptp4l[3408.917]: port 1: master sync timeout > > ptp4l[3409.917]: port 1: master sync timeout > > ptp4l[3409.918]: port 1: master tx announce timeout > > ptp4l[3410.917]: port 1: master sync timeout > > ptp4l[3411.917]: port 1: master sync timeout > > ... > > > > > The above messages are output whenever the internal timeouts > for sending > announce and sync messages timeout. They only appear at -l7 > and are > *not* error messages despite what it appears. The timeout is a > standard > timer that we set so that we periodically send a sync and > announce > messages as the master. This is standard behavior of the PTP > daemon. > Hopefully these messages can be redesigned soon so that they > appear less > like a debug. Maybe change the timeout word. > > > > > -Output of 'phc2sys -c eth0 -s /dev/ptp0 -w -m' > > phc2sys[5786.385]: phc offset 16 s0 freq +0 > delay > > 3968 > > phc2sys[5787.385]: phc offset -8 s2 freq -24 > delay > > 3984 > > phc2sys[5788.386]: phc offset 0 s2 freq -24 > delay > > 4000 > > phc2sys[5789.386]: phc offset 8 s2 freq -16 > delay > > 3952 > > ... > > > > > > > Here, you see the phc2sys offset, and it actually is very good > those > numbers are quite low. > > > This will continue on indefinitely. > > I have heard of systems being incapable of syncing due to > time > > disparity, but I have manually synced these clocks in an > attempt to > > rule this possibility out. I have also tried increasing all > timeouts, > > delays, etc. I have even gone so far as to use NTP as the > source for > > PTP, just to see if it would help. It didn't. > > > > > The clocks should be synced as it shows here. the values you > see above > are in order from left to right: > > 1) the value in nanoseconds of the last measured offset > 2) sN is the current P/I servo state > 3) the frequency adjustment we've applied to correct the clock > 4) the measured delay of measuring the clock. > > These all look great! > > > > > Regardless, from everything I've seen, this appears to be > more of a > > driver/kernel issue, though everything I've been able to > identify has > > checked out as the proper version, setting, etc. When I was > having > > this issue on kernel 3.11, I upgraded to 3.14 to no avail. > I'm more > > than willing and happy to send more information upon request > and any > > information you guys may have would be hugely helpful. > > > > > > > Are you actually seeing incorrect clock adjustment? The clocks > appear to > be in sync. Note that the output of ptp4l you show is actually > that > device becoming master, I am curious what the output of the > connected > PTP ports are, so we can see how the other end is faring. I > think mostly > you simply misinterpreted output of ptp4l. > > > Many Thanks, > > Mason > > > > Hope this helps! > > Regards, > Jake > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - > For FREE > Instantly run your Selenium tests across 300+ browser/OS > combos. > Get unparalleled scalability from the best Selenium testing > platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Mason W. <mas...@gm...> - 2014-05-13 23:16:04
|
Well this is all very good news. > Are you actually seeing incorrect clock adjustment? The clocks appear to > be in sync. Note that the output of ptp4l you show is actually that > device becoming master, I am curious what the output of the connected > PTP ports are, so we can see how the other end is faring. I think mostly > you simply misinterpreted output of ptp4l. I suppose not, if that is in fact the case. It would seem as though my misinterpretation stemmed from the fact that when I actually tried to transmit a UDP message, it was not able to see PTP evidence when checking at packet scope. Wireshark reported the protocols used as 'eth:ip:udp:data', though, correct me if I'm wrong, I would see evidence both here and in other areas of a PTP stamp. It was a very simple test, just writing a message through either Netcat or /dev/udp/, so there's as good of a chance that my fallacy lies there as anywhere else. Again, thank you so very much for your help, Mason On Tue, May 13, 2014 at 4:50 PM, Keller, Jacob E <jac...@in...>wrote: > On Tue, 2014-05-13 at 15:26 -0600, Mason Winsauer wrote: > > Hey guys, > > > > Hi there, > > It seems you mistook a sort of debug message output as an error, when > infact it's part of normal operation. I believe a recent commit into the > head of the project fixes this to be a debug instead of an error, but I > will explain more below. > > > > > I know this is a common question, and have researched the vast > > majority of similar questions, but there still isn't much information > > for my configuration. Also, I'm brand new to PTP as a concept, so > > please forgive my ignorance. I'll start with a quick rundown of the > > current configuration, outputs of relevant programs, etc. > > > > > > OpenSuse 13.1, Custom built kernel 3.14.3-7-desktop > > All required PTP/PPS/PHY options enabled > > Broadcom NetXtreme 5720, > > Tigon3 driver version 3.136 > > LinuxPTP v. 1.4 > > > > > > -Output of '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) > > ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT) > > ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT) > > ptpv2-l2-event (HWTSTAMP_FILTER_PTP_V2_L2_EVENT) > > > > > > -Output of 'pmc -u -b 0 'GET CURRENT_DATA_SET'' > > sending: GET CURRENT_DATA_SET > > 90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT > > CURRENT_DATA_SET > > stepsRemoved 0 > > offsetFromMaster 0.0 > > meanPathDelay 0.0 > > > > > > -Output of 'pmc -u -b 0 'GET TIME_STATUS_NP'' > > sending: GET TIME_STATUS_NP > > 90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT TIME_STATUS_NP > > master_offset 0 > > ingress_time 0 > > cumulativeScaledRateOffset +1.000000000 > > scaledLastGmPhaseChange 0 > > gmTimeBaseIndicator 0 > > lastGmPhaseChange 0x0000'0000000000000000.0000 > > gmPresent false > > gmIdentity 90b11c.fffe.2e1b2d > > > > > > > > -Output of 'ptp4l -S -i eth0 -m -l7' > > Your command is correct, except that -l7 outputs *very* verbose log > messages, and is completely unnecessary. Try with -l6 and you should see > less cruft, but most of the useful output. > > > ptp4l[3401.186]: PI servo: sync interval 1.000 kp 0.100 ki > > 0.001000 > > ptp4l[3401.186]: port 1: INITIALIZING to LISTENING on > > INITIALIZE > > ptp4l[3401.186]: port 0: INITIALIZING to LISTENING on > > INITIALIZE > > ptp4l[3407.916]: port 1: announce timeout > > ptp4l[3407.916]: port 1: LISTENING to MASTER on > > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > ptp4l[3407.916]: selected best master clock 90b11c.fffe.2e1b2d > > ptp4l[3407.916]: assuming the grand master role > > ptp4l[3407.917]: port 1: master tx announce timeout > > ptp4l[3407.918]: port 1: setting asCapable > > ptp4l[3408.917]: port 1: master sync timeout > > ptp4l[3409.917]: port 1: master sync timeout > > ptp4l[3409.918]: port 1: master tx announce timeout > > ptp4l[3410.917]: port 1: master sync timeout > > ptp4l[3411.917]: port 1: master sync timeout > > ... > > > > The above messages are output whenever the internal timeouts for sending > announce and sync messages timeout. They only appear at -l7 and are > *not* error messages despite what it appears. The timeout is a standard > timer that we set so that we periodically send a sync and announce > messages as the master. This is standard behavior of the PTP daemon. > Hopefully these messages can be redesigned soon so that they appear less > like a debug. Maybe change the timeout word. > > > > > -Output of 'phc2sys -c eth0 -s /dev/ptp0 -w -m' > > phc2sys[5786.385]: phc offset 16 s0 freq +0 delay > > 3968 > > phc2sys[5787.385]: phc offset -8 s2 freq -24 delay > > 3984 > > phc2sys[5788.386]: phc offset 0 s2 freq -24 delay > > 4000 > > phc2sys[5789.386]: phc offset 8 s2 freq -16 delay > > 3952 > > ... > > > > > > Here, you see the phc2sys offset, and it actually is very good those > numbers are quite low. > > > This will continue on indefinitely. > > I have heard of systems being incapable of syncing due to time > > disparity, but I have manually synced these clocks in an attempt to > > rule this possibility out. I have also tried increasing all timeouts, > > delays, etc. I have even gone so far as to use NTP as the source for > > PTP, just to see if it would help. It didn't. > > > > The clocks should be synced as it shows here. the values you see above > are in order from left to right: > > 1) the value in nanoseconds of the last measured offset > 2) sN is the current P/I servo state > 3) the frequency adjustment we've applied to correct the clock > 4) the measured delay of measuring the clock. > > These all look great! > > > > > Regardless, from everything I've seen, this appears to be more of a > > driver/kernel issue, though everything I've been able to identify has > > checked out as the proper version, setting, etc. When I was having > > this issue on kernel 3.11, I upgraded to 3.14 to no avail. I'm more > > than willing and happy to send more information upon request and any > > information you guys may have would be hugely helpful. > > > > > > Are you actually seeing incorrect clock adjustment? The clocks appear to > be in sync. Note that the output of ptp4l you show is actually that > device becoming master, I am curious what the output of the connected > PTP ports are, so we can see how the other end is faring. I think mostly > you simply misinterpreted output of ptp4l. > > > Many Thanks, > > Mason > > > > Hope this helps! > > Regards, > Jake > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform > available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: Keller, J. E <jac...@in...> - 2014-05-13 22:50:54
|
On Tue, 2014-05-13 at 15:26 -0600, Mason Winsauer wrote: > Hey guys, > Hi there, It seems you mistook a sort of debug message output as an error, when infact it's part of normal operation. I believe a recent commit into the head of the project fixes this to be a debug instead of an error, but I will explain more below. > > I know this is a common question, and have researched the vast > majority of similar questions, but there still isn't much information > for my configuration. Also, I'm brand new to PTP as a concept, so > please forgive my ignorance. I'll start with a quick rundown of the > current configuration, outputs of relevant programs, etc. > > > OpenSuse 13.1, Custom built kernel 3.14.3-7-desktop > All required PTP/PPS/PHY options enabled > Broadcom NetXtreme 5720, > Tigon3 driver version 3.136 > LinuxPTP v. 1.4 > > > -Output of '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) > ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT) > ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT) > ptpv2-l2-event (HWTSTAMP_FILTER_PTP_V2_L2_EVENT) > > > -Output of 'pmc -u -b 0 'GET CURRENT_DATA_SET'' > sending: GET CURRENT_DATA_SET > 90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT > CURRENT_DATA_SET > stepsRemoved 0 > offsetFromMaster 0.0 > meanPathDelay 0.0 > > > -Output of 'pmc -u -b 0 'GET TIME_STATUS_NP'' > sending: GET TIME_STATUS_NP > 90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT TIME_STATUS_NP > master_offset 0 > ingress_time 0 > cumulativeScaledRateOffset +1.000000000 > scaledLastGmPhaseChange 0 > gmTimeBaseIndicator 0 > lastGmPhaseChange 0x0000'0000000000000000.0000 > gmPresent false > gmIdentity 90b11c.fffe.2e1b2d > > > > -Output of 'ptp4l -S -i eth0 -m -l7' Your command is correct, except that -l7 outputs *very* verbose log messages, and is completely unnecessary. Try with -l6 and you should see less cruft, but most of the useful output. > ptp4l[3401.186]: PI servo: sync interval 1.000 kp 0.100 ki > 0.001000 > ptp4l[3401.186]: port 1: INITIALIZING to LISTENING on > INITIALIZE > ptp4l[3401.186]: port 0: INITIALIZING to LISTENING on > INITIALIZE > ptp4l[3407.916]: port 1: announce timeout > ptp4l[3407.916]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[3407.916]: selected best master clock 90b11c.fffe.2e1b2d > ptp4l[3407.916]: assuming the grand master role > ptp4l[3407.917]: port 1: master tx announce timeout > ptp4l[3407.918]: port 1: setting asCapable > ptp4l[3408.917]: port 1: master sync timeout > ptp4l[3409.917]: port 1: master sync timeout > ptp4l[3409.918]: port 1: master tx announce timeout > ptp4l[3410.917]: port 1: master sync timeout > ptp4l[3411.917]: port 1: master sync timeout > ... > The above messages are output whenever the internal timeouts for sending announce and sync messages timeout. They only appear at -l7 and are *not* error messages despite what it appears. The timeout is a standard timer that we set so that we periodically send a sync and announce messages as the master. This is standard behavior of the PTP daemon. Hopefully these messages can be redesigned soon so that they appear less like a debug. Maybe change the timeout word. > > -Output of 'phc2sys -c eth0 -s /dev/ptp0 -w -m' > phc2sys[5786.385]: phc offset 16 s0 freq +0 delay > 3968 > phc2sys[5787.385]: phc offset -8 s2 freq -24 delay > 3984 > phc2sys[5788.386]: phc offset 0 s2 freq -24 delay > 4000 > phc2sys[5789.386]: phc offset 8 s2 freq -16 delay > 3952 > ... > > Here, you see the phc2sys offset, and it actually is very good those numbers are quite low. > This will continue on indefinitely. > I have heard of systems being incapable of syncing due to time > disparity, but I have manually synced these clocks in an attempt to > rule this possibility out. I have also tried increasing all timeouts, > delays, etc. I have even gone so far as to use NTP as the source for > PTP, just to see if it would help. It didn't. > The clocks should be synced as it shows here. the values you see above are in order from left to right: 1) the value in nanoseconds of the last measured offset 2) sN is the current P/I servo state 3) the frequency adjustment we've applied to correct the clock 4) the measured delay of measuring the clock. These all look great! > > Regardless, from everything I've seen, this appears to be more of a > driver/kernel issue, though everything I've been able to identify has > checked out as the proper version, setting, etc. When I was having > this issue on kernel 3.11, I upgraded to 3.14 to no avail. I'm more > than willing and happy to send more information upon request and any > information you guys may have would be hugely helpful. > > Are you actually seeing incorrect clock adjustment? The clocks appear to be in sync. Note that the output of ptp4l you show is actually that device becoming master, I am curious what the output of the connected PTP ports are, so we can see how the other end is faring. I think mostly you simply misinterpreted output of ptp4l. > Many Thanks, > Mason > Hope this helps! Regards, Jake |
|
From: Mason W. <mas...@gm...> - 2014-05-13 21:26:56
|
Hey guys, I know this is a common question, and have researched the vast majority of similar questions, but there still isn't much information for my configuration. Also, I'm brand new to PTP as a concept, so please forgive my ignorance. I'll start with a quick rundown of the current configuration, outputs of relevant programs, etc. *OpenSuse 13.1, Custom built kernel 3.14.3-7-desktop* All required PTP/PPS/PHY options enabled *Broadcom NetXtreme 5720*, Tigon3 driver version 3.136 *LinuxPTP v. 1.4* -Output of '*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) ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT) ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT) ptpv2-l2-event (HWTSTAMP_FILTER_PTP_V2_L2_EVENT) -Output of '*pmc -u -b 0 'GET CURRENT_DATA_SET'*' sending: GET CURRENT_DATA_SET 90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET stepsRemoved 0 offsetFromMaster 0.0 meanPathDelay 0.0 -Output of '*pmc -u -b 0 '**GET TIME_STATUS_NP**'*' sending: GET TIME_STATUS_NP 90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT TIME_STATUS_NP master_offset 0 ingress_time 0 cumulativeScaledRateOffset +1.000000000 scaledLastGmPhaseChange 0 gmTimeBaseIndicator 0 lastGmPhaseChange 0x0000'0000000000000000.0000 gmPresent false gmIdentity 90b11c.fffe.2e1b2d -Output of '*ptp4l -S -i eth0 -m -l7*' ptp4l[3401.186]: PI servo: sync interval 1.000 kp 0.100 ki 0.001000 ptp4l[3401.186]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[3401.186]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[3407.916]: port 1: announce timeout ptp4l[3407.916]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[3407.916]: selected best master clock 90b11c.fffe.2e1b2d ptp4l[3407.916]: assuming the grand master role ptp4l[3407.917]: port 1: master tx announce timeout ptp4l[3407.918]: port 1: setting asCapable ptp4l[3408.917]: port 1: master sync timeout ptp4l[3409.917]: port 1: master sync timeout ptp4l[3409.918]: port 1: master tx announce timeout ptp4l[3410.917]: port 1: master sync timeout ptp4l[3411.917]: port 1: master sync timeout ... -Output of '*phc2sys -c eth0 -s /dev/ptp0 -w -m*' phc2sys[5786.385]: phc offset 16 s0 freq +0 delay 3968 phc2sys[5787.385]: phc offset -8 s2 freq -24 delay 3984 phc2sys[5788.386]: phc offset 0 s2 freq -24 delay 4000 phc2sys[5789.386]: phc offset 8 s2 freq -16 delay 3952 ... This will continue on indefinitely. I have heard of systems being incapable of syncing due to time disparity, but I have manually synced these clocks in an attempt to rule this possibility out. I have also tried increasing all timeouts, delays, etc. I have even gone so far as to use NTP as the source for PTP, just to see if it would help. It didn't. Regardless, from everything I've seen, this appears to be more of a driver/kernel issue, though everything I've been able to identify has checked out as the proper version, setting, etc. When I was having this issue on kernel 3.11, I upgraded to 3.14 to no avail. I'm more than willing and happy to send more information upon request and any information you guys may have would be hugely helpful. Many Thanks, Mason |
|
From: Richard C. <ric...@gm...> - 2014-05-07 19:48:23
|
On Mon, May 05, 2014 at 04:09:00PM +0200, Cyril Baletaud wrote: > # ptp4l -A -m -i enp1s0 & This looks okay. > # phc2sys enp1s0-s-c-m-enp2s0 w & This command line looks wrong. > a sample of what I get > > # ptp4l: master s2 offset 60 freq 7000 path delay 7714 > # phc2sys: offset phc 12 s2 path delay freq 11900 12960 > > Is this the right way? Show us a longer sample of the output. Thanks, Richard |
|
From: Cyril B. <cyr...@gm...> - 2014-05-05 14:09:07
|
I develop a GigE Vision application (jiguiviou on gitorious) GigE Vision 2.0 supports the dating of images PtP. I have a master clock (MEINBERG lantime m600) and a switch PtP RUGGEDCOM RSG2288. Unfortunately, the switch does not support jumbo frame, required for very high bitrates (near 850 Mb/s). My PC has 5 NIC Intel I210. My idea is to connect a NIC to the switch PtP, and GigE camera on a different NIC. enp1s0 -> PtP switch (Master Clock) enp2s0 -> GigE camera (AVT Prosilica GT PtP client) # ptp4l -A -m -i enp1s0 & # phc2sys enp1s0-s-c-m-enp2s0 w & a sample of what I get # ptp4l: master s2 offset 60 freq 7000 path delay 7714 # phc2sys: offset phc 12 s2 path delay freq 11900 12960 Is this the right way? Sorry for my english (google translate) |
|
From: Richard C. <ric...@gm...> - 2014-04-26 06:25:02
|
On Fri, Apr 25, 2014 at 08:22:22PM +0000, Lide, David wrote: > anyone working on ptp transparent mode (ete, peer2peer) support for this stack ? If you mean implementing a transparent clock using linuxptp, then no, nobody is working on it, as far as I know. The problem is that a TC is a kind of a switch, and it looks like managed switches do not have very broad support in the Linux kernel. The is a "DSA" driver for a few Marvell switches, but I am not familiar with the details of DSA. For linuxptp to support TC, we would need a unified way to talk with the switch hardware. Thanks, Richard |
|
From: Lide, D. <dl...@ti...> - 2014-04-25 20:22:32
|
anyone working on ptp transparent mode (ete, peer2peer) support for this stack ? thanks, dave |
|
From: Richard C. <ric...@gm...> - 2014-04-15 04:59:19
|
On Mon, Apr 14, 2014 at 09:44:30PM +0000, Vick, Matthew wrote: > On 4/14/14, 12:23 PM, "Hanspeter Portner" <de...@op...> > wrote: > > >I have my time master (e1000e, Intel 82579LM) set up with hardware time > >stamping. This card can only time stamp one packet at a time. > >Then I have two slaves set up with software timestamping (not using > >linuxptp, microcontrollers). > > > >When the two slaves send their delay requests shortly following each > >other, often only one of both is answered. > >For the ignored one, there is this error: 'ptp4l[16004.338]: port 1: > >received DELAY_REQ without timestamp' > > > >For the ignored delay request: > >- 'fsm_event_port_event' returns -ETIME > >- because 'transport_recv' reports a hardware time stamp of 0 > >- 'transport_recv' calls 'udp_rec' which calls 'sk_receive' > >- there I've seen that the ignored delay request packet has no cmsg and > >therefore no associated timestamp > > > >Has anybody encountered similar issues? This is to be expected. If two packets arrive at nearly the same time, the 82579 will only be able to time stamp one of them, and one event message will be dropped by linuxptp. However, this does not present a problem because: 1. The slaves are required by the PTP to randomly distribute their requests, making the "collision" a rare event. 2. The synchronization algorithm is robust to occasional missing Delay_Req/Resp information. After all, the path delay does not change in typical environments. Thanks, Richard |
|
From: Vick, M. <mat...@in...> - 2014-04-14 21:44:44
|
On 4/14/14, 12:23 PM, "Hanspeter Portner" <de...@op...> wrote: >I have my time master (e1000e, Intel 82579LM) set up with hardware time >stamping. >Then I have two slaves set up with software timestamping (not using >linuxptp, microcontrollers). > >When the two slaves send their delay requests shortly following each >other, often only one of both is answered. >For the ignored one, there is this error: 'ptp4l[16004.338]: port 1: >received DELAY_REQ without timestamp' > >For the ignored delay request: >- 'fsm_event_port_event' returns -ETIME >- because 'transport_recv' reports a hardware time stamp of 0 >- 'transport_recv' calls 'udp_rec' which calls 'sk_receive' >- there I've seen that the ignored delay request packet has no cmsg and >therefore no associated timestamp > >Has anybody encountered similar issues? > >Here the corresonding wireshark capture: >https://dl.dropboxusercontent.com/u/46882396/ptp4l.pcapng.gz > >Hanspeter Hanspeter, Sorry to hear you're having trouble! I haven't had the chance to look over the Wireshark capture, but typically that message in your setup (e.g. not using linuxptp on the link partners and bursting the traffic) means that the hardware simply cannot process the Rx timestamp requests quickly enough. I'd recommend trying to space out the DELAY_REQ traffic a little better if at all possible. I've CC'd Dave Ertman, the e1000e maintainer, in case there's anything further we can help with. Cheers, Matthew Matthew Vick Linux Development Networking Division Intel Corporation |
|
From: Hanspeter P. <de...@op...> - 2014-04-14 19:42:53
|
I have my time master (e1000e, Intel 82579LM) set up with hardware time stamping. Then I have two slaves set up with software timestamping (not using linuxptp, microcontrollers). When the two slaves send their delay requests shortly following each other, often only one of both is answered. For the ignored one, there is this error: 'ptp4l[16004.338]: port 1: received DELAY_REQ without timestamp' For the ignored delay request: - 'fsm_event_port_event' returns -ETIME - because 'transport_recv' reports a hardware time stamp of 0 - 'transport_recv' calls 'udp_rec' which calls 'sk_receive' - there I've seen that the ignored delay request packet has no cmsg and therefore no associated timestamp Has anybody encountered similar issues? Here the corresonding wireshark capture: https://dl.dropboxusercontent.com/u/46882396/ptp4l.pcapng.gz Hanspeter |
|
From: Richard C. <ric...@gm...> - 2014-03-27 05:46:46
|
On Wed, Mar 26, 2014 at 08:39:10PM +0000, Keller, Jacob E wrote: > I would rather have this check in the ptp core, because it wouldn't rely > on drivers doing it, and we'd only have to code it in one place. Yep, did you see the patch I posted? Thanks, Richard |
|
From: Keller, J. E <jac...@in...> - 2014-03-26 20:39:19
|
I would rather have this check in the ptp core, because it wouldn't rely on drivers doing it, and we'd only have to code it in one place. On Wed, 2014-03-26 at 08:57 +0100, Mohamed Belaouad wrote: > I agree with you. Either that or the drivers could return an error in such a case. > > Best Regards, > Mohamed > > ----- Mail original ----- > > On Tue, 2014-03-25 at 15:29 +0100, Richard Cochran wrote: > > > On Tue, Mar 25, 2014 at 02:38:29PM +0100, Mohamed Belaouad wrote: > > > > > > > Considering that the drivers sets the max adj to 62,500,000, I > > > > should be able to set the ppb ajustment up/down to -+62,500,000 from > > > > my understanding. > > > > > > Yes, that is correct. > > > > > > > However, when printing the value passed to the driver with testptp I get: > > > > Value passed to testptp | Value printed at the entry of the driver > > > > function > > > > > +32,768,000 | -32,768,000 > > > > < -32,768,000 | -32,768,000 > > > > > > I guess you are on a 32 bit platform. In that case, the size of the > > > adjustment is limited by the timex.freq field. See linuxptp/phc.c. > > > > > > > Please excuse me if it is a misunderstanding on my part. > > > > > > I thought you meant that the kernel should check that the dialed > > > frequency offset is within the bounds of [-max_adj, +max_adj]. > > > That is a different issue. > > > > > > > I think that change to the kernel would be a good thing, since most > > drivers assume that the value passed to them is within range. > > > > Regards, > > Jake > > > > > Thanks, > > > Richard > > > > > > > > > |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-26 07:57:43
|
I agree with you. Either that or the drivers could return an error in such a case. Best Regards, Mohamed ----- Mail original ----- > On Tue, 2014-03-25 at 15:29 +0100, Richard Cochran wrote: > > On Tue, Mar 25, 2014 at 02:38:29PM +0100, Mohamed Belaouad wrote: > > > > > Considering that the drivers sets the max adj to 62,500,000, I > > > should be able to set the ppb ajustment up/down to -+62,500,000 from > > > my understanding. > > > > Yes, that is correct. > > > > > However, when printing the value passed to the driver with testptp I get: > > > Value passed to testptp | Value printed at the entry of the driver > > > function > > > > +32,768,000 | -32,768,000 > > > < -32,768,000 | -32,768,000 > > > > I guess you are on a 32 bit platform. In that case, the size of the > > adjustment is limited by the timex.freq field. See linuxptp/phc.c. > > > > > Please excuse me if it is a misunderstanding on my part. > > > > I thought you meant that the kernel should check that the dialed > > frequency offset is within the bounds of [-max_adj, +max_adj]. > > That is a different issue. > > > > I think that change to the kernel would be a good thing, since most > drivers assume that the value passed to them is within range. > > Regards, > Jake > > > Thanks, > > Richard > > > > > |
|
From: Keller, J. E <jac...@in...> - 2014-03-25 16:35:38
|
On Tue, 2014-03-25 at 15:29 +0100, Richard Cochran wrote: > On Tue, Mar 25, 2014 at 02:38:29PM +0100, Mohamed Belaouad wrote: > > > Considering that the drivers sets the max adj to 62,500,000, I > > should be able to set the ppb ajustment up/down to -+62,500,000 from > > my understanding. > > Yes, that is correct. > > > However, when printing the value passed to the driver with testptp I get: > > Value passed to testptp | Value printed at the entry of the driver function > > > +32,768,000 | -32,768,000 > > < -32,768,000 | -32,768,000 > > I guess you are on a 32 bit platform. In that case, the size of the > adjustment is limited by the timex.freq field. See linuxptp/phc.c. > > > Please excuse me if it is a misunderstanding on my part. > > I thought you meant that the kernel should check that the dialed > frequency offset is within the bounds of [-max_adj, +max_adj]. > That is a different issue. > I think that change to the kernel would be a good thing, since most drivers assume that the value passed to them is within range. Regards, Jake > Thanks, > Richard > |
|
From: Mohamed B. <mbe...@ad...> - 2014-03-25 16:16:41
|
I really appreciate that you and Jake helped me on my issues. > I guess you are on a 32 bit platform. In that case, the size of the > adjustment is limited by the timex.freq field. See linuxptp/phc.c. > Yes, I am. I was on the right track and understand now. Thanks to both of you & Best Regards, Mohamed |
|
From: Richard C. <ric...@gm...> - 2014-03-25 14:29:29
|
On Tue, Mar 25, 2014 at 02:38:29PM +0100, Mohamed Belaouad wrote: > Considering that the drivers sets the max adj to 62,500,000, I > should be able to set the ppb ajustment up/down to -+62,500,000 from > my understanding. Yes, that is correct. > However, when printing the value passed to the driver with testptp I get: > Value passed to testptp | Value printed at the entry of the driver function > > +32,768,000 | -32,768,000 > < -32,768,000 | -32,768,000 I guess you are on a 32 bit platform. In that case, the size of the adjustment is limited by the timex.freq field. See linuxptp/phc.c. > Please excuse me if it is a misunderstanding on my part. I thought you meant that the kernel should check that the dialed frequency offset is within the bounds of [-max_adj, +max_adj]. That is a different issue. Thanks, Richard |
27 messages has been excluded from this view by a project administrator.
