linuxptp-users Mailing List for linuxptp (Page 147)
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: Richard C. <ric...@gm...> - 2013-08-06 07:17:54
|
On Mon, Aug 05, 2013 at 04:32:14PM +0000, Ledda William EXT wrote: > Sorry Richard, but I'm stiil a bit confused about the meaning of the > PHY column. Let me make an example, I have a i350 that has the igb > driver. I read from the table the following table: > > Driver Hardware SOTS PHC PHY VER > igb Intel 82576, 82580 RAW Y NA 3.5 > > In this case, this means that I have a PTP-capable PHY attached to PTP-capable MAC? The PHY column reads "NA" meaning "Not Applicable." Even if you attach a PTP capable PHY (like the National Semiconductor PHYTER) to your i350 MAC, still you will never get any time stamps from the PHY, as the MAC driver will intercept the SIOCSHWTSTAMP ioctl. HTH, Richard |
|
From: Keller, J. E <jac...@in...> - 2013-08-05 20:26:18
|
> -----Original Message----- > From: Гаврилов Александр [mailto:le...@im...] > Sent: Sunday, August 04, 2013 11:56 PM > To: lin...@li... > Subject: Re: [Linuxptp-users] Hardware PTP clock synchronization > > Hello! > > Here is an example of the log where synchronization occured: > > ----------------------------------------------------------------------- > > ptp4l -2 -i p16p1 -m -H -s > ptp4l[17534.938]: selected /dev/ptp0 as PTP clock > ptp4l[17534.957]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[17534.957]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[17536.761]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[17540.751]: selected best master clock ece555.fffe.2de639 > ptp4l[17540.751]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[17542.696]: port 1: minimum delay request interval 2^3 > ptp4l[17542.746]: master offset 50001478246023551 s0 adj +0 path > delay 1276 > ptp4l[17543.744]: master offset 50001478246021573 s0 adj +0 path > delay 974 > ptp4l[17544.741]: master offset 50001478246019277 s0 adj +0 path > delay 974 > ptp4l[17545.739]: master offset 50001478246016997 s1 adj +0 path > delay 974 > ptp4l[17546.736]: master offset -5048 s2 adj -5048 path delay > 974 > ptp4l[17546.736]: port 1: UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > ptp4l[17547.734]: master offset -2323 s2 adj -3837 path delay > 974 > ptp4l[17548.732]: master offset -789 s2 adj -3000 path delay 974 > ptp4l[17549.729]: master offset -95 s2 adj -2543 path delay 974 > ptp4l[17550.726]: master offset 123 s2 adj -2354 path delay 974 > ptp4l[17551.724]: master offset 110 s2 adj -2330 path delay 974 > ptp4l[17552.721]: master offset 106 s2 adj -2301 path delay 974 > ptp4l[17553.719]: master offset 109 s2 adj -2266 path delay 974 > ptp4l[17554.716]: master offset 104 s2 adj -2238 path delay 974 > ptp4l[17555.714]: master offset -27 s2 adj -2338 path delay 974 > ptp4l[17556.711]: master offset -48 s2 adj -2367 path delay 974 > ptp4l[17557.709]: master offset -53 s2 adj -2386 path delay 974 > ptp4l[17558.706]: master offset 45 s2 adj -2304 path delay 974 > ptp4l[17559.704]: master offset 275 s2 adj -2061 path delay 716 > ptp4l[17560.701]: master offset 9 s2 adj -2244 path delay 716 > ptp4l[17561.699]: master offset -131 s2 adj -2382 path delay 716 > ptp4l[17562.696]: master offset -176 s2 adj -2466 path delay 716 > ptp4l[17563.694]: master offset -102 s2 adj -2445 path delay 716 > ptp4l[17564.691]: master offset -28 s2 adj -2401 path delay 716 > ptp4l[17565.689]: master offset 47 s2 adj -2335 path delay 716 > ptp4l[17566.686]: master offset 2 s2 adj -2366 path delay 716 > ptp4l[17567.684]: master offset -27 s2 adj -2394 path delay 716 > ptp4l[17568.681]: master offset 40 s2 adj -2335 path delay 716 > ptp4l[17569.679]: master offset -13 s2 adj -2376 path delay 716 > ptp4l[17570.676]: master offset 69 s2 adj -2298 path delay 589 > ptp4l[17571.674]: master offset 9 s2 adj -2337 path delay 589 > ptp4l[17572.671]: master offset -52 s2 adj -2396 path delay 589 > ptp4l[17572.955]: recvmsg tx timestamp failed: Resource temporarily > unavailable > ptp4l[17572.955]: port 1: send delay request failed > ptp4l[17572.955]: port 1: SLAVE to FAULTY on FAULT_DETECTED > ptp4l[17591.068]: port 1: FAULTY to LISTENING on FAULT_CLEARED > ptp4l[17592.622]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[17596.612]: selected best master clock ece555.fffe.2de639 > ptp4l[17596.612]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[17597.609]: master offset 1492 s2 adj -867 path delay 589 > ptp4l[17597.609]: port 1: UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > ptp4l[17597.654]: recvmsg tx timestamp failed: Resource temporarily > unavailable > ptp4l[17597.654]: port 1: send delay request failed > ptp4l[17597.654]: port 1: SLAVE to FAULTY on FAULT_DETECTED > > ----------------------------------------------------------------------- > > I350-F2 - can you recommend this ethernet adapter > as alternative? (gigabit, fiber optic interface) > It still appears to be running version 1.0. Could you please ensure you have updated to v1.2 or v1.3 and try again? In regards to "hardware bugs"... the 82576 is not "bugged" or "glitched" so much as it is simply flawed. It has a design bug or flaw, but it is doing exactly what it was designed to do. However, I believe you really need to update to ptp4l v1.2 since this has resolved a rather important issue around polling for Tx timestamps, and vastly reduces issues with software dropping Tx timestamps because it couldn't process them fast enough. In addition it may be the case that you need to update your kernel. I don't recall any specific fixes for this type of issue but it is possible. And yes, I would highly suggest posting on the e1000-devel list, because that would get proper recognition from among other folks at Intel.. While Intel's Ethernet products are validated and certified.. I don't believe much 1588/PTP testing and certification is done, especially on older hardware. - Jake |
|
From: Keller, J. E <jac...@in...> - 2013-08-05 20:21:04
|
> -----Original Message----- > From: Гаврилов Александр [mailto:le...@im...] > Sent: Monday, August 05, 2013 4:58 AM > To: lin...@li... > Subject: Re: [Linuxptp-users] Hardware PTP clock synchronization > > Hello!. > > IntelR 82576 Gigabit Ethernet Controller Datasheet: > "On both transmit and receive sides the timestamp values are locked in > registers until values are read by > software. As a result if a new PTP packet that requires time stamp arrives > before software access it is > not time stamped. In some cases in the receive path a packet that was > timestamped might be lost and > not reach the host. To avoid a deadlock condition on the time stamp > registers the software should keep > a watch dog timer to clear locking of the time stamp register. The interval > counted by such a timer > should be at least higher then the expected interval between two Sync or > Delay_Req packets depends > on the node state (Master or Slave)." > > How should I modify the source code of igb driver (or ptp4l) to use > the timer? > > Sincerely, Alexander. > You should not have to modify the 82576 driver code. - Jake |
|
From: Ledda W. E. <Wil...@it...> - 2013-08-05 16:32:23
|
Sorry Richard, but I'm stiil a bit confused about the meaning of the PHY column. Let me make an example, I have a i350 that has the igb driver. I read from the table the following table: Driver Hardware SOTS PHC PHY VER igb Intel 82576, 82580 RAW Y NA 3.5 In this case, this means that I have a PTP-capable PHY attached to PTP-capable MAC? Thanks -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: 31 July 2013 16:43 To: Ledda William EXT Cc: lin...@li... Subject: Re: [Linuxptp-users] Clarification about Driver Compatibility Matrix On Wed, Jul 31, 2013 at 09:18:48AM +0000, Ledda William EXT wrote: > Hi all, > I don't understand very well why in the Compatibility matrix all Hardware timestamping drivers have the PHY column to "NA", while in the software timestamping table some have the PHY equal to "Y" and some equal to "N". > > My interpretation is that, since they have the PHC support this means that they also support the timestamping in PHY. Is it the right conclusion? No, time stamping can be done in hardware in special MACs and special PHYs. The Linux kernel does not support both at the same time, so if you have a PTP-capable PHY attached to PTP-capable MAC, then you will only get the MAC as a PHC. In addition, only drivers using phylib can support PTP-capable PHYs. HTH, Richard |
|
From: Гаврилов А. <le...@im...> - 2013-08-05 11:58:40
|
Hello!. Intel® 82576 Gigabit Ethernet Controller Datasheet: "On both transmit and receive sides the timestamp values are locked in registers until values are read by software. As a result if a new PTP packet that requires time stamp arrives before software access it is not time stamped. In some cases in the receive path a packet that was timestamped might be lost and not reach the host. To avoid a deadlock condition on the time stamp registers the software should keep a watch dog timer to clear locking of the time stamp register. The interval counted by such a timer should be at least higher then the expected interval between two Sync or Delay_Req packets depends on the node state (Master or Slave)." How should I modify the source code of igb driver (or ptp4l) to use the timer? Sincerely, Alexander. |
|
From: Гаврилов А. <le...@im...> - 2013-08-05 07:30:43
|
Hello! And more thing: on my card 82676 i can read time registers directly in DOS - it work fine. But in linux this causes an error "tx timestamp timeout". Sincerely, Alexander. |
|
From: Гаврилов А. <le...@im...> - 2013-08-05 06:56:41
|
Hello! Here is an example of the log where synchronization occured: ----------------------------------------------------------------------- ptp4l -2 -i p16p1 -m -H -s ptp4l[17534.938]: selected /dev/ptp0 as PTP clock ptp4l[17534.957]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[17534.957]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[17536.761]: port 1: new foreign master ece555.fffe.2de639-2 ptp4l[17540.751]: selected best master clock ece555.fffe.2de639 ptp4l[17540.751]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[17542.696]: port 1: minimum delay request interval 2^3 ptp4l[17542.746]: master offset 50001478246023551 s0 adj +0 path delay 1276 ptp4l[17543.744]: master offset 50001478246021573 s0 adj +0 path delay 974 ptp4l[17544.741]: master offset 50001478246019277 s0 adj +0 path delay 974 ptp4l[17545.739]: master offset 50001478246016997 s1 adj +0 path delay 974 ptp4l[17546.736]: master offset -5048 s2 adj -5048 path delay 974 ptp4l[17546.736]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[17547.734]: master offset -2323 s2 adj -3837 path delay 974 ptp4l[17548.732]: master offset -789 s2 adj -3000 path delay 974 ptp4l[17549.729]: master offset -95 s2 adj -2543 path delay 974 ptp4l[17550.726]: master offset 123 s2 adj -2354 path delay 974 ptp4l[17551.724]: master offset 110 s2 adj -2330 path delay 974 ptp4l[17552.721]: master offset 106 s2 adj -2301 path delay 974 ptp4l[17553.719]: master offset 109 s2 adj -2266 path delay 974 ptp4l[17554.716]: master offset 104 s2 adj -2238 path delay 974 ptp4l[17555.714]: master offset -27 s2 adj -2338 path delay 974 ptp4l[17556.711]: master offset -48 s2 adj -2367 path delay 974 ptp4l[17557.709]: master offset -53 s2 adj -2386 path delay 974 ptp4l[17558.706]: master offset 45 s2 adj -2304 path delay 974 ptp4l[17559.704]: master offset 275 s2 adj -2061 path delay 716 ptp4l[17560.701]: master offset 9 s2 adj -2244 path delay 716 ptp4l[17561.699]: master offset -131 s2 adj -2382 path delay 716 ptp4l[17562.696]: master offset -176 s2 adj -2466 path delay 716 ptp4l[17563.694]: master offset -102 s2 adj -2445 path delay 716 ptp4l[17564.691]: master offset -28 s2 adj -2401 path delay 716 ptp4l[17565.689]: master offset 47 s2 adj -2335 path delay 716 ptp4l[17566.686]: master offset 2 s2 adj -2366 path delay 716 ptp4l[17567.684]: master offset -27 s2 adj -2394 path delay 716 ptp4l[17568.681]: master offset 40 s2 adj -2335 path delay 716 ptp4l[17569.679]: master offset -13 s2 adj -2376 path delay 716 ptp4l[17570.676]: master offset 69 s2 adj -2298 path delay 589 ptp4l[17571.674]: master offset 9 s2 adj -2337 path delay 589 ptp4l[17572.671]: master offset -52 s2 adj -2396 path delay 589 ptp4l[17572.955]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[17572.955]: port 1: send delay request failed ptp4l[17572.955]: port 1: SLAVE to FAULTY on FAULT_DETECTED ptp4l[17591.068]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[17592.622]: port 1: new foreign master ece555.fffe.2de639-2 ptp4l[17596.612]: selected best master clock ece555.fffe.2de639 ptp4l[17596.612]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[17597.609]: master offset 1492 s2 adj -867 path delay 589 ptp4l[17597.609]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[17597.654]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[17597.654]: port 1: send delay request failed ptp4l[17597.654]: port 1: SLAVE to FAULTY on FAULT_DETECTED ----------------------------------------------------------------------- I350-F2 - can you recommend this ethernet adapter as alternative? (gigabit, fiber optic interface) |
|
From: Richard C. <ric...@gm...> - 2013-08-04 08:22:14
|
On Sat, Aug 03, 2013 at 10:08:08PM +0300, Alex Gavrilov wrote: > > What did not work? > > Richard, you wrote: "In any case, the hardware is clearly missing time > stamps. You can just ignore this error.". But these errors are > constantly - during 4 hours only once sinchronization was happened. You mean that only one delay request every four hours is successful? The PTP can work will occasional dropping of messages, but what you have here is obviously not good enough. > Spec update for 82576 not contains bugs with 1588: Okay, but after you finish with Intel, you can expect to see a new erratum published. > How a series of 210, 350, 82576 refers to a series of IXPxxx? This is just an example of a real life hardware bug from Intel. You said that your boss cannot believe such a thing is possible. However, it is not a matter of belief, hardware bugs are an undeniable fact. If I were you, I would post your issue to the e1000-devel mailing list. It is most probably a hardware bug (but perhaps a driver bug). In any case, it is not a bug in linuxptp. Also, buy another card. From the Intel cards, I have tested the 82574, the 82580, and the i210. HTH, Richard |
|
From: Alex G. <al....@gm...> - 2013-08-03 19:08:15
|
> What did not work? Richard, you wrote: "In any case, the hardware is clearly missing time stamps. You can just ignore this error.". But these errors are constantly - during 4 hours only once sinchronization was happened. Tomorrow i write this moment from ptp4l log (saved on my work). > Are you talking about the Linux system time? If so, you can sychronize it to /dev/ptp0 using the phc2sys program. I need to get the exact time value in "/dev/ptp0" and query from my program through clock_gettime(ID_PTP0, timeval); > Hardware ships with bugs. It is a fact of life. ...... Spec update for 82576 not contains bugs with 1588: http://www.intel.com/content/www/us/en/ethernet-controllers/82576eb-gigabit-ethernet-controller-spec-update.html How a series of 210, 350, 82576 refers to a series of IXPxxx? Thank you very much for your answers! Sincerely, Alexander. |
|
From: Richard C. <ric...@gm...> - 2013-08-03 17:02:43
|
On Sat, Aug 03, 2013 at 05:33:29PM +0300, Alex Gavrilov wrote: > 1 time hardware clock was synchronized, and in the application i see > what time "/dev/ptp0" synchronizes (through clock_gettime). But again > it did not work. What did not work? > I also thought that if the synchronization happens > sometimes, even with errors, we would arrange this option. But the > synchronization is no longer happening, how much we try to. Are you talking about the Linux system time? If so, you can sychronize it to /dev/ptp0 using the phc2sys program. > In what could be the reason? Switch sync time is too long (2 sec). > My boss does not believe that the Intel certified card can not be > fully tested and have a hardware error. Hardware ships with bugs. It is a fact of life. When bugs are discovered, an erratum is published that tells you that the bug does exist. Intel calls their errata "Specification Update". You should look if there is one for the 82576. Even if none have been published, that doesn't mean there aren't hardware bugs. You and your boss might find this document interesting. It describes an Intel PTP hardware implementation with bugs. http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/ixp4xx-product-line-network-processors-spec-update.pdf Look especially at Item #40 on page 39: 40. IEEE-1588 Time Sync Lock-up Fails to Time-Stamp a Second PTP Message Problem: A lock-up condition has been identified in the IEEE-1588 Time Sync block that prevents all subsequent messages form being time-stamped. It occurs when a message has been time-stamped and the registers are locked, after which - if a new message comes in before the previous time stamp is read and the lock bit is cleared - the Time Sync block enters a lock-up condition and prevents all furthers messages from being time-stamped. This occurs for both received and transmitted messages. Implication: Under very typical usage scenarios, the IEEE-1588 unit can lock up and will not capture time stamps after the initial one is locked. Workaround: If IEEE-1588 functionality is required, it must be implemented with external hardware. This says that PTP function in the silicon is totally useless. > Can I get an official response from Intel about this card (or any > official response to convince my boss, they 2 months not responding). Maybe you can, but don't hold your breath. Thanks, Richard |
|
From: Alex G. <al....@gm...> - 2013-08-03 14:33:37
|
>So I suspect that you were running a version prior to 1.2, can that be true? Yes, i ran 1.0 version, this is my bug, sorry. >In any case, the hardware is clearly missing time stamps. You can just ignore this error. What happens when you let the program continue? Does every delay request throw an error, or do some succeed? 1 time hardware clock was synchronized, and in the application i see what time "/dev/ptp0" synchronizes (through clock_gettime). But again it did not work. I also thought that if the synchronization happens sometimes, even with errors, we would arrange this option. But the synchronization is no longer happening, how much we try to. > If only some of the messages fail, then you can just set the fault_reset_interval config option to "ASAP" to avoid the long fault time. Okay, I'll try it. > In any case, the hardware is clearly missing time stamps. In what could be the reason? Switch sync time is too long (2 sec). My boss does not believe that the Intel certified card can not be fully tested and have a hardware error. Can I get an official response from Intel about this card (or any official response to convince my boss, they 2 months not responding). Sincerely, Alexander. |
|
From: Richard C. <ric...@gm...> - 2013-08-03 13:40:37
|
On Sat, Aug 03, 2013 at 12:12:22PM +0300, Гаврилов Александр wrote: > My problem - any way get time values from 82576 in program. May be, > through modification of the source code driver igb-4.3.0, or > ptp4l. We havent time to buy a new card. What can you recommend? I doubt you can fix this by changing the source code. It appears that the *hardware* is dropping the time stamps. [ It might possibly be a driver issue, but to find out and fix this you need to read and understand both the 82576 data sheet and the igb driver, and then figure out what is going wrong. ] If you find that only some of the Tx time stamps are being missed, then you can change the fault reset option to ASAP, to let the ptp4l program continue without the pauses after the faults. HTH, Richard |
|
From: Richard C. <ric...@gm...> - 2013-08-03 13:31:47
|
On Sat, Aug 03, 2013 at 11:14:43AM +0300, Гаврилов Александр wrote:
>
> ptp4l.conf:
>
> #tx_timestamp_retries 1
> tx_timestamp_timeout 1000
Good ...
> [root@lab32 linuxptp-1.3]# ptp4l -f "ptp4l.conf" -i p16p1 -m
> ptp4l[2946.559]: selected /dev/ptp0 as PTP clock
> ptp4l[2946.573]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[2946.573]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[2947.895]: port 1: new foreign master ece555.fffe.2de639-2
> ptp4l[2951.885]: selected best master clock ece555.fffe.2de639
> ptp4l[2951.885]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[2955.029]: poll tx timestamp timeout
^^^^^^^^^^^^^^^^^^^^^^^^^
> ptp4l[2955.029]: port 1: send delay request failed
Hm, before you had:
ptp4l[3709.401]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[3710.039]: recvmsg tx timestamp failed: Resource temporarily unavailable
ptp4l[3710.039]: port 1: send delay request failed
ptp4l[733.452]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[734.458]: recvmsg tx timestamp failed: Resource temporarily unavailable
ptp4l[734.458]: port 1: send peer delay request failed
So I suspect that you were running a version prior to 1.2, can that be
true?
In any case, the hardware is clearly missing time stamps. You can just
ignore this error. What happens when you let the program continue?
Does every delay request throw an error, or do some succeed?
If only some of the messages fail, then you can just set the
fault_reset_interval config option to "ASAP" to avoid the long fault
time.
HTH,
Richard
|
|
From: Гаврилов А. <le...@im...> - 2013-08-03 09:12:46
|
My problem - any way get time values from 82576 in program. May be, through modification of the source code driver igb-4.3.0, or ptp4l. We havent time to buy a new card. What can you recommend? Sincerely, Alexander. |
|
From: Гаврилов А. <le...@im...> - 2013-08-03 08:15:05
|
Hello! > I would recommend the i210. It is not expensive, and it has excellent capabilities. We need fiber optic interface (for example, I350F, but it is too expensive for us, we will try to use 82576). > Would it be possible for you to attempt using LinuxPTP 1.3 Ok, i try. ------------------------------------------------------ DMESG log: 3.949188] igb: module verification failed: signature and/or required key missing - tainting kernel [ 3.949987] Intel(R) Gigabit Ethernet Network Driver - version 4.3.0 [ 3.949990] Copyright (c) 2007-2013 Intel Corporation. [ 3.952065] igb 0000:04:00.0: irq 49 for MSI/MSI-X [ 3.952074] igb 0000:04:00.0: irq 50 for MSI/MSI-X [ 3.982512] igb 0000:04:00.0: added PHC on eth0 [ 3.982516] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection [ 3.982518] igb 0000:04:00.0: eth0: (PCIe:2.5GT/s:Width x4) [ 3.982520] igb 0000:04:00.0: eth0: MAC: [ 3.982521] 00:1b:21:d9:ef:34 [ 3.982596] igb 0000:04:00.0: eth0: PBA No: E31745-004 [ 3.982597] igb 0000:04:00.0: LRO is disabled [ 3.982599] igb 0000:04:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) [ 3.983868] igb 0000:04:00.1: irq 51 for MSI/MSI-X [ 3.983875] igb 0000:04:00.1: irq 52 for MSI/MSI-X [ 3.986161] microcode: CPU0 sig=0x1067a, pf=0x10, revision=0xa07 [ 3.989520] tun: Universal TUN/TAP device driver, 1.6 [ 3.989522] tun: (C) 1999-2004 Max Krasnyansky <ma...@qu...> [ 4.014485] igb 0000:04:00.1: added PHC on eth1 [ 4.014489] igb 0000:04:00.1: Intel(R) Gigabit Ethernet Network Connection [ 4.014491] igb 0000:04:00.1: eth1: (PCIe:2.5GT/s:Width x4) [ 4.014493] igb 0000:04:00.1: eth1: MAC: [ 4.014494] 00:1b:21:d9:ef:35 [ 4.014568] igb 0000:04:00.1: eth1: PBA No: E31745-004 [ 4.014570] igb 0000:04:00.1: LRO is disabled [ 4.014572] igb 0000:04:00.1: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s) [ 36.905039] igb: p16p1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 348.347009] igb 0000:04:00.0: clearing Tx timestamp hang [ 371.862010] igb 0000:04:00.0: clearing Tx timestamp hang [ 429.447013] igb 0000:04:00.0: clearing Tx timestamp hang [ 475.400010] igb 0000:04:00.0: clearing Tx timestamp hang [ 504.270012] igb 0000:04:00.0: clearing Tx timestamp hang ------------------------------------------------------ ETHTOOL: [root@lab32 linuxptp-1.3]# ethtool -i p16p1 driver: igb version: 4.3.0 firmware-version: 1.2.1 bus-info: 0000:04:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no ------------------------------------------------------ ptp4l.conf: [global] # # Default Data Set # twoStepFlag 1 slaveOnly 1 priority1 128 priority2 128 domainNumber 0 clockClass 248 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 # # Port Data Set # logAnnounceInterval 1 logSyncInterval 0 logMinDelayReqInterval 1 logMinPdelayReqInterval 1 announceReceiptTimeout 3 delayAsymmetry 0 # # Run time options # assume_two_step 1 logging_level 6 path_trace_enabled 0 follow_up_info 0 #tx_timestamp_retries 1 tx_timestamp_timeout 1000 use_syslog 1 verbose 0 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_offset_const 0.0 clock_servo pi # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp6_scope 0x0E # # Default interface options # network_transport L2 delay_mechanism E2E time_stamping hardware ------------------------------------------------------ [root@lab32 linuxptp-1.3]# ptp4l -f "ptp4l.conf" -i p16p1 -m ptp4l[2946.559]: selected /dev/ptp0 as PTP clock ptp4l[2946.573]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[2946.573]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[2947.895]: port 1: new foreign master ece555.fffe.2de639-2 ptp4l[2951.885]: selected best master clock ece555.fffe.2de639 ptp4l[2951.885]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[2955.029]: poll tx timestamp timeout ptp4l[2955.029]: port 1: send delay request failed ptp4l[2955.029]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) wireshark: 31 9.975069000 Hirschma_2d:e6:39 IeeeI&MS_00:00:00 PTPv2 60 Sync Message Ethernet II, Src: Hirschma_2d:e6:39 (ec:e5:55:2d:e6:39), Dst: IeeeI&MS_00:00:00 (01:1b:19:00:00:00) .... 0010 = versionPTP: 2 correction: 0,000000 nanoseconds ClockIdentity: 0xece555fffe2de639 ptp.v2.flags == 0x0200 originTimestamp (seconds): 1375519750 originTimestamp (nanoseconds): 317139647 32 9.975971000 Hirschma_2d:e6:39 IeeeI&MS_00:00:00 PTPv2 60 Follow_Up Message 33 10.972569000 Hirschma_2d:e6:39 IeeeI&MS_00:00:00 PTPv2 60 Sync Message 34 10.973499000 Hirschma_2d:e6:39 IeeeI&MS_00:00:00 PTPv2 60 Follow_Up Message 35 10.973698000 Hirschma_2d:e6:39 IeeeI&MS_00:00:00 PTPv2 78 Announce Message 36 11.121565000 IntelCor_d9:ef:34 IeeeI&MS_00:00:00 PTPv2 58 Delay_Req Message 37 11.122969000 Hirschma_2d:e6:39 IeeeI&MS_00:00:00 PTPv2 68 Delay_Resp Message 38 11.511230000 Hirschma_2d:e6:42 Spanning-tree-(for-bridges)_00 STP 60 RST. Root = 32768/0/ec:e5:55:2d:e6:39 Cost = 0 Port = 0x8002 39 11.970068000 Hirschma_2d:e6:39 IeeeI&MS_00:00:00 PTPv2 60 Sync Message Sincerely, Alexander. |
|
From: Keller, J. E <jac...@in...> - 2013-08-02 23:30:18
|
I agree with you.. But the architects here usually just consider 1588/PTP support sort of a "best effort" when designing the hardware. That tends towards not really properly supporting the feature. At least early on there weren't many hardware guys here who actually understood what PTP needed either, so some of the older designs just don't quite do the right thing. That is why some of the designs really don't work quite as well as one would like. Thanks, Jake On Fri, 2013-08-02 at 17:20 -0400, Dale Smith wrote: > Yeah, that's pretty much what I suspected. > > > A reason you want to use something like a vcxo, is so get get a really > clean clock for driving things like A2D converters. It's important if > you are doing signal analysis. A fixed frequency clock with pulse > addition/subtraction to get the right number of clocks edges per > second just doesn't cut it. > > > Thanks, > -Dale > > > > > > > On Fri, Aug 2, 2013 at 4:16 PM, Keller, Jacob E > <jac...@in...> wrote: > On Fri, 2013-08-02 at 14:36 -0400, Dale Smith wrote: > > On Fri, Aug 2, 2013 at 1:54 PM, Keller, Jacob E > > <jac...@in...> wrote: > > Richard suggested the i210, and I also would > recommend this > > part. > > Obviously I am somewhat biased as I am an Intel > engineer. > > However this > > part definitely is better than the 82576 because it > supports > > timestamping all packets (vastly reducing issues) > > > > > > Something I'm unclear on after reading the i210 datasheets, > is if it > > is possible for it to use an external servoed vcxo or the > like for the > > 1588 clock, or does it only do the missing pulse / extra > pulse thing > > to adjust the 1588 clock frequency? > > > > > > Thanks, > > -Dale > > > > I do not believe you can use an external servo to create the > 1588 clock. > You may, however, be able to use an external PPS signal and > have that > timestamped and software tune the onboard 1588 clock > frequency. > > I don't know this for certain though. > > Thanks, > Jake > > |
|
From: Dale S. <dal...@gm...> - 2013-08-02 21:20:27
|
Yeah, that's pretty much what I suspected. A reason you want to use something like a vcxo, is so get get a really clean clock for driving things like A2D converters. It's important if you are doing signal analysis. A fixed frequency clock with pulse addition/subtraction to get the right number of clocks edges per second just doesn't cut it. Thanks, -Dale On Fri, Aug 2, 2013 at 4:16 PM, Keller, Jacob E <jac...@in...>wrote: > On Fri, 2013-08-02 at 14:36 -0400, Dale Smith wrote: > > On Fri, Aug 2, 2013 at 1:54 PM, Keller, Jacob E > > <jac...@in...> wrote: > > Richard suggested the i210, and I also would recommend this > > part. > > Obviously I am somewhat biased as I am an Intel engineer. > > However this > > part definitely is better than the 82576 because it supports > > timestamping all packets (vastly reducing issues) > > > > > > Something I'm unclear on after reading the i210 datasheets, is if it > > is possible for it to use an external servoed vcxo or the like for the > > 1588 clock, or does it only do the missing pulse / extra pulse thing > > to adjust the 1588 clock frequency? > > > > > > Thanks, > > -Dale > > > I do not believe you can use an external servo to create the 1588 clock. > You may, however, be able to use an external PPS signal and have that > timestamped and software tune the onboard 1588 clock frequency. > > I don't know this for certain though. > > Thanks, > Jake > |
|
From: Keller, J. E <jac...@in...> - 2013-08-02 20:16:31
|
On Fri, 2013-08-02 at 14:36 -0400, Dale Smith wrote: > On Fri, Aug 2, 2013 at 1:54 PM, Keller, Jacob E > <jac...@in...> wrote: > Richard suggested the i210, and I also would recommend this > part. > Obviously I am somewhat biased as I am an Intel engineer. > However this > part definitely is better than the 82576 because it supports > timestamping all packets (vastly reducing issues) > > > Something I'm unclear on after reading the i210 datasheets, is if it > is possible for it to use an external servoed vcxo or the like for the > 1588 clock, or does it only do the missing pulse / extra pulse thing > to adjust the 1588 clock frequency? > > > Thanks, > -Dale I do not believe you can use an external servo to create the 1588 clock. You may, however, be able to use an external PPS signal and have that timestamped and software tune the onboard 1588 clock frequency. I don't know this for certain though. Thanks, Jake |
|
From: Dale S. <dal...@gm...> - 2013-08-02 18:36:20
|
On Fri, Aug 2, 2013 at 1:54 PM, Keller, Jacob E <jac...@in...>wrote: > Richard suggested the i210, and I also would recommend this part. > Obviously I am somewhat biased as I am an Intel engineer. However this > part definitely is better than the 82576 because it supports > timestamping all packets (vastly reducing issues) Something I'm unclear on after reading the i210 datasheets, is if it is possible for it to use an external servoed vcxo or the like for the 1588 clock, or does it only do the missing pulse / extra pulse thing to adjust the 1588 clock frequency? Thanks, -Dale |
|
From: Keller, J. E <jac...@in...> - 2013-08-02 17:54:09
|
Hi Alexander, On Fri, 2013-08-02 at 09:33 +0300, Гаврилов Александр wrote: > Thanks for your interest in my problem! > Would it be possible for you to attempt using LinuxPTP 1.3 (released today!)? or the git tree? I know you said you were using version 1.2, but it appears based on your error log that you are not using the version which fixes the tx timestamp timeout issue by using poll(). Please just for clarity re-test using LinuxPTP 1.3? :) > lspci output: > Intel 82576 Gigabit ethernet controller (rev 01) > Intel 82576 Gigabit ethernet controller (rev 01) > > ethtool output: > ethtool -T p16p1 > Time stamping parameters for p16p1: > 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-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) > > > You are on a modern kernel. Please do not use -p /dev/ptpX option. Let the program automatically determine it. > > Ok, it works. > Was hoping this would solve the problem... :( Ok. > > How about just increasing the tx_timestamp_timeout configuration option to 100 or 1000? > > Set a tx_timestamp_timeout value to 1000 in configuration file. > > > Also please re-try with -P, for peer to peer delay mechanism. > I realize now that you are using a switch which probably only does one mode.. > ptp4l -2 -i p16p1 -P -m -H -s > ptp4l[728.271]: selected /dev/ptp0 as PTP clock > ptp4l[728.288]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[728.288]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[729.462]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[733.452]: selected best master clock ece555.fffe.2de639 > ptp4l[733.452]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE I just noticed this. This is weird.. > ptp4l[734.458]: recvmsg tx timestamp failed: Resource temporarily unavailable You get the tx timestamp failed error instead of the polling failed error. That means that the LinuxPTP attempts to poll and then still fails to receive the message. I am very unsure why this happens. I believe this is the right place to look regarding the issue. > ptp4l[734.458]: port 1: send peer delay request failed > ptp4l[734.458]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED > > > I wrote the original igb ptp code, but I never tested the 82576 > because I don't have one. I am not sure if Intel tested this either. > Richard wrote the original patch which added PTP support into the driver, and then a developer here on my team updated it to support newer devices. I know the validation team for the driver did some testing, but the 82576 is not very good for PTP. (details on why below) > > Basically, the 82576 is not a very reliable part for timestamping... > What kind of adapter would you recommend instead of 82576? (gigabit). > Richard suggested the i210, and I also would recommend this part. Obviously I am somewhat biased as I am an Intel engineer. However this part definitely is better than the 82576 because it supports timestamping all packets (vastly reducing issues) On Fri, 2013-08-02 at 09:48 +0300, Гаврилов Александр wrote: > Basically, the 82576 is not a very reliable part for timestamping. > > Why? > > Sincerely, Alexander. > > The 82576 was one of the first parts Intel ND did with 1588 support. The hardware was done years before we had a stable PTP kernel support, and before a lot of things were understood well, and therefor the design of the MAC chip does not really work well for 1588 support. Mainly, when timestamping it can only store one timestamp for RX and TX and the driver has to process packets fast enough, otherwise dropped timestamps can occur. This is the issue you are seeing. Newer parts have solved this issue by enabling the device to insert a timestamp for each packet directly into the packet buffer. > > In any case, thank you very much! > I asked Matthew Vick, the developer who worked on the igb driver, and did the refreshed PTP work. He has since moved onto other work so he does not have much time to work on this. However, he did some touch testing of the 82576, and was able to get it to work.76e10e95 I believe the likely issue you are seeing is related to the switch you are working against (he tried back to back). Do you know the Sync transmit rate? It is normally once per second. However some switches set this to a much higher rate. This causes issues because the 82576 part cannot really handle timestamping packets if they arrive too quickly together, which would be the result of dropped timestamps. some questions, and other information that may help: 1) if you are comfortable instrumenting LinuxPTP code, could you please add some pr_err() calls into sk.c's sk_receive call around line 221? This is really bothering me that the poll isn't timing out and is indeed waking up with something on the error queue when there is nothing there. 2) could you get a dmesg log for your device, and also an ethtool -i on your device so I know the igb version number you are using... 3) what is the sync rate of the switch? once per second? or faster? 4) could you send me a packet dump of the packets transmitted? via tcpdump.. I am very concerned because you are in an incredibly weird state.. It looks like poll() succeeds but then recvmsg fails, which is just not good. I don't know what could be causing this... Hope we can debug this and resolve the issue.. Thanks, Jake |
|
From: Richard C. <ric...@gm...> - 2013-08-02 11:05:15
|
Dear linuxptp users and developers,
It has been almost four months since the last release, and a number of
important fixes and features have appeared. So before summer vacation,
I pushed out a v1.3 tag and released a tar ball on SF.
Many thanks to the contributors, Andy, Dale, Delio, Geoff, Jacob, Jiri
Benc, Jiri Bohac, Ken, Libor, and Miroslav.
The short log is appended, below.
Enjoy,
Richard
Andy Lutomirski (1):
Fix check for timestamping modes
Dale P. Smith (1):
Place clock type values in the correct positon
Delio Brignoli (1):
Fix parsing of fault_badpeernet_interval option
Geoff Salmon (1):
Allow received GET management messages to have bodies
Jacob Keller (2):
phc2sys: update open_clock and deprecate '-i' option
phc2sys: update usage/error reporting
Jiri Benc (1):
ptp4l: flush old cached packets
Jiri Bohac (2):
fix misleading pr_err on poll timeout
fix the check for supported timestamping modes
Ken ICHIKAWA (8):
Add support for more strict config value validation
config: Apply config value validation to logging_level option
util: Add common procedures to get argument values for ptp4l and phc2sys
ptp4l and phc2sys: Get argument values with strict error checking
Don't return bogus clock id
config: Apply more strict input validation to almost all config file options
Add a new servo option which specifies first step threshold
ptp4l: add support for using configured_pi_f_offset servo option
Libor Pechacek (4):
Document PTP time scale usage and provide examples
phc2sys: Require either -O or -w on command line
phc2sys: common code exit point for bad usage case
Reordered options in manual page synopsis
Miroslav Lichvar (8):
ptp4l: Allow P, I constants over 1.0.
phc2sys: Use currentUtcOffset only with PTP timescale.
phc2sys: Change update rate parameter to floating-point.
ptp4l: Reset path delay when new master is selected.
Add missing state setting in PI servo when date check fails.
Minor documentation improvements.
phc2sys: Set servo sync interval.
Adjust constants of PI servo according to sync interval.
Richard Cochran (33):
phc2sys: Use nanosleep instead of usleep.
Silence grep error during build.
trivial: break the very long lines of the get_ functions.
Bring the readme file up to date with the equipment donations.
uClinux: Add another missing system call wrapper.
Add another Freescale driver into the support matrix.
No need to set kernel_leap twice in a row.
Clean up indented white space.
pmc: fix coding style by using K&R style functions.
Reset announce timer when port is passive.
Add missing option to the default configuration file.
Add a clock variable to hold the value of the time source.
Add a configuration option for the time source.
Introduce a non-portable management TLV for grand masters.
Support the grand master settings management query.
pmc: Support the grandmaster settings management request.
Support configuration of the grand master settings.
Throw a state decision event if the clock quality changes.
pmc: add a utility function for sending a message with the SET action.
pmc: add our very first SET command.
Let the clock servo know the expected sync interval.
Use a dynamic frequency estimation interval.
Become the grand master when all alone.
msg: Add missing network byte order conversion.
pmc: make the TLV length a functional result.
pmc: send GET management messages according to interpretation #29.
pmc: optional legacy zero length TLV for GET actions.
pmc_common: introduce a variable for the target port identity.
pmc: add a command to select the target port.
pmc: release the message cache on exit.
Be more careful when receiving clock description TLVs.
Fix bug in unlucky sync/follow up handling.
Version 1.3
|
|
From: Richard C. <ric...@gm...> - 2013-08-02 08:48:18
|
On Fri, Aug 02, 2013 at 09:33:12AM +0300, Гаврилов Александр wrote: > > Richard, you are an employee Intel? No, I am not. > Or a driver for Intel card are developing people who do not work in Intel? The driver is for the Linux kernel, and anyone may contribute to that project. Intel does develop Linux drivers, of course, but they also cooperate with non-Intel developers, too. I am the author and maintainer of the PTP Hardware Clock (PHC) subsystem of the Linux kernel. > > Basically, the 82576 is not a very reliable part for timestamping... It sounds like to me that the 82576 has a hardware bug (and not a driver issue). > What kind of adapter would you recommend instead of 82576? (gigabit). I would recommend the i210. It is not expensive, and it has excellent capabilities. Thanks, Richard |
|
From: Гаврилов А. <le...@im...> - 2013-08-02 06:49:01
|
> Basically, the 82576 is not a very reliable part for timestamping. Why? Sincerely, Alexander. |
|
From: Гаврилов А. <le...@im...> - 2013-08-02 06:33:32
|
Thanks for your interest in my problem!
lspci output:
Intel 82576 Gigabit ethernet controller (rev 01)
Intel 82576 Gigabit ethernet controller (rev 01)
ethtool output:
ethtool -T p16p1
Time stamping parameters for p16p1:
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-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)
> You are on a modern kernel. Please do not use -p /dev/ptpX option. Let the program automatically determine it.
Ok, it works.
> How about just increasing the tx_timestamp_timeout configuration option to 100 or 1000?
Set a tx_timestamp_timeout value to 1000 in configuration file.
> Also please re-try with -P, for peer to peer delay mechanism.
ptp4l -2 -i p16p1 -P -m -H -s
ptp4l[728.271]: selected /dev/ptp0 as PTP clock
ptp4l[728.288]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[728.288]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[729.462]: port 1: new foreign master ece555.fffe.2de639-2
ptp4l[733.452]: selected best master clock ece555.fffe.2de639
ptp4l[733.452]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[734.458]: recvmsg tx timestamp failed: Resource temporarily unavailable
ptp4l[734.458]: port 1: send peer delay request failed
ptp4l[734.458]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED
> I wrote the original igb ptp code, but I never tested the 82576
because I don't have one. I am not sure if Intel tested this either.
Richard, you are an employee Intel?
Or a driver for Intel card are developing people who do not work in Intel?
I wrote to tech support intel two months ago, they said that my question is redirected to a deeper level.
To this day there is no response from Intel.
> Basically, the 82576 is not a very reliable part for timestamping...
What kind of adapter would you recommend instead of 82576? (gigabit).
In any case, thank you very much!
|
|
From: Keller, J. E <jac...@in...> - 2013-08-01 20:54:35
|
On Thu, 2013-08-01 at 19:58 +0200, Richard Cochran wrote: > On Thu, Aug 01, 2013 at 05:44:37PM +0000, Keller, Jacob E wrote: > > > > I encountered a problem while obtaining the time from the adapter Intel > > > pro1000 (82576). > > ... > > > > ptp4l[3704.267]: selected /dev/ptp0 as PTP clock > > > ptp4l[3704.278]: port 1: INITIALIZING to LISTENING on INITIALIZE > > > ptp4l[3704.278]: port 0: INITIALIZING to LISTENING on INITIALIZE > > > ptp4l[3705.077]: port 1: new foreign master ece555.fffe.2de639-2 > > > ptp4l[3709.401]: selected best master clock ece555.fffe.2de639 > > > ptp4l[3709.401]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > > > ptp4l[3710.039]: recvmsg tx timestamp failed: Resource temporarily > > > unavailable > > > > This means your tx timestamp is not being properly detected. I don't > > know for sure why this is, but there are a few reasons. I will > > forward this to the intel engineer who designed the driver for this > > part. > > I wrote the original igb ptp code, but I never tested the 82576 > because I don't have one. I am not sure if Intel tested this either. > > How about just increasing the tx_timestamp_timeout configuration > option to 100 or 1000? > > Thanks, > Richard I believe this is actually physical hardware dropping the timestamps, not an issue of not returning them fast enough. I know that Matthew Vick has done some testing of the 82576 but not that much. I also believe the use of poll has since removed any of the issues due to timing (we poll for an entire second if it isn't there!) You could try increasing the poll time just in case to see if it helps.. Basically, the 82576 is not a very reliable part for timestamping... - Jake |
27 messages has been excluded from this view by a project administrator.
