linuxptp-users Mailing List for linuxptp (Page 148)
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-01 17:58:39
|
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 |
|
From: Keller, J. E <jac...@in...> - 2013-08-01 17:50:12
|
> -----Original Message----- > From: Гаврилов Александр [mailto:le...@im...] > Sent: Thursday, August 01, 2013 12:55 AM > To: lin...@li... > Subject: [Linuxptp-users] Hardware PTP clock synchronization > > Hello! > > I encountered a problem while obtaining the time from the adapter Intel > pro1000 (82576). > I use Fedora 18 kernel version 3.9.6. > The values of the time I get through clock_gettime (id, timevalue) for the > device / dev/ptp0. > The source of the PTP packet is switch Hirschmann MAR1140. Wireshark > shows the presence of all necessary for the implementation of the > protocol PTP packets at the input adapter interface, > but the time in the PTP counters are not adjusted in accordance with the > values of the packages. > I compiled linuxptp-1.2 downloaded from > http://linuxptp.sourceforge.net/ and run the following commands: > > Hardware timestamping: > > # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -H > Also please re-try with -P, for peer to peer delay mechanism. The 82576 does not always perform well when using E2E and can potentially drop packets due to its internal timestamping design having some flaws. See if it starts working if you can use peer delay mechanism? If your ptp source cannot use P2P, hopefully we can find out why E2E isn't working for you... - Jake > 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 > ptp4l[3710.039]: port 1: send delay request failed > ptp4l[3710.039]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED > ptp4l[3725.690]: port 1: FAULTY to LISTENING on FAULT_CLEARED > ptp4l[3726.698]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3731.022]: selected best master clock ece555.fffe.2de639 > ptp4l[3731.022]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[3731.193]: recvmsg tx timestamp failed: Resource temporarily > unavailable > ptp4l[3731.193]: port 1: send delay request failed > ptp4l[3731.193]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED > > Software timestamping: > > # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -S > > ptp4l[3826.218]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3826.218]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3828.312]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3832.218]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[3832.636]: selected best master clock ece555.fffe.2de639 > ptp4l[3832.636]: port 1: MASTER to UNCALIBRATED on RS_SLAVE > ptp4l[3833.805]: negative path delay -3374260 > ptp4l[3833.805]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[3833.805]: t2 - t3 = -87573969 > ptp4l[3833.805]: t4 - t1 = +80825448 > ptp4l[3833.805]: c1 0 > ptp4l[3833.805]: c2 0 > ptp4l[3833.805]: c3 0 > ptp4l[3833.805]: port 1: minimum delay request interval 2^3 > ptp4l[3834.628]: negative path delay -35159469 > ptp4l[3834.628]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[3834.628]: t2 - t3 = -910670474 > ptp4l[3834.628]: t4 - t1 = +840351536 > ptp4l[3834.628]: c1 0 > ptp4l[3834.628]: c2 0 > ptp4l[3834.628]: c3 0 > ptp4l[3834.798]: master offset -10774702751233 s0 adj +0 path delay > -19266864 > ptp4l[3835.879]: master offset -10774619261329 s0 adj +0 path delay > -19266864 > > > What is the difference between hardware and software timestamping in > this case? > Why Hardware timestamping is not working properly? > Why software timestamping shows the correct time values, but does not > synchronize time with hardware ptp clock (/dev/ptp0)? > > Sincerely, Alexander. > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ost > g.clktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Keller, J. E <jac...@in...> - 2013-08-01 17:44:47
|
> -----Original Message----- > From: Гаврилов Александр [mailto:le...@im...] > Sent: Thursday, August 01, 2013 12:55 AM > To: lin...@li... > Subject: [Linuxptp-users] Hardware PTP clock synchronization > > Hello! > > I encountered a problem while obtaining the time from the adapter Intel > pro1000 (82576). > I use Fedora 18 kernel version 3.9.6. > The values of the time I get through clock_gettime (id, timevalue) for the > device / dev/ptp0. > The source of the PTP packet is switch Hirschmann MAR1140. Wireshark > shows the presence of all necessary for the implementation of the > protocol PTP packets at the input adapter interface, > but the time in the PTP counters are not adjusted in accordance with the > values of the packages. > I compiled linuxptp-1.2 downloaded from > http://linuxptp.sourceforge.net/ and run the following commands: > > Hardware timestamping: > > # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -H > You are on a modern kernel. Please do not use -p /dev/ptpX option. Let the program automatically determine it. It may be the case that you don't have the right ptp device. Richard: do we have a check in place to ensure the passed argument is correct if we can check? I don't remember. > 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. > ptp4l[3710.039]: port 1: send delay request failed > ptp4l[3710.039]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED > ptp4l[3725.690]: port 1: FAULTY to LISTENING on FAULT_CLEARED > ptp4l[3726.698]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3731.022]: selected best master clock ece555.fffe.2de639 > ptp4l[3731.022]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[3731.193]: recvmsg tx timestamp failed: Resource temporarily > unavailable > ptp4l[3731.193]: port 1: send delay request failed > ptp4l[3731.193]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED > hardware timestamping is not working correctly because you are not properly receiving the tx timestamps. > Software timestamping: > > # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -S > > ptp4l[3826.218]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3826.218]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[3828.312]: port 1: new foreign master ece555.fffe.2de639-2 > ptp4l[3832.218]: port 1: LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[3832.636]: selected best master clock ece555.fffe.2de639 > ptp4l[3832.636]: port 1: MASTER to UNCALIBRATED on RS_SLAVE > ptp4l[3833.805]: negative path delay -3374260 > ptp4l[3833.805]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[3833.805]: t2 - t3 = -87573969 > ptp4l[3833.805]: t4 - t1 = +80825448 > ptp4l[3833.805]: c1 0 > ptp4l[3833.805]: c2 0 > ptp4l[3833.805]: c3 0 > ptp4l[3833.805]: port 1: minimum delay request interval 2^3 > ptp4l[3834.628]: negative path delay -35159469 > ptp4l[3834.628]: path_delay = (t2 - t3) + (t4 - t1) > ptp4l[3834.628]: t2 - t3 = -910670474 > ptp4l[3834.628]: t4 - t1 = +840351536 > ptp4l[3834.628]: c1 0 > ptp4l[3834.628]: c2 0 > ptp4l[3834.628]: c3 0 > ptp4l[3834.798]: master offset -10774702751233 s0 adj +0 path delay > -19266864 > ptp4l[3835.879]: master offset -10774619261329 s0 adj +0 path delay > -19266864 > > > What is the difference between hardware and software timestamping in > this case? > Why Hardware timestamping is not working properly? > Why software timestamping shows the correct time values, but does not > synchronize time with hardware ptp clock (/dev/ptp0)? > Hardware timestamping uses the ptp device, and coordinates with the driver for doing timestamps in the MAC or PHY. Software timestamping does software based stamps as late as possible in the driver. It does not use the PHC device at all and directly modifies the kernel time. They are completely different modes. > Sincerely, Alexander. > > Thanks, Jake |
|
From: Гаврилов А. <le...@im...> - 2013-08-01 07:57:24
|
Hello! I encountered a problem while obtaining the time from the adapter Intel pro1000 (82576). I use Fedora 18 kernel version 3.9.6. The values of the time I get through clock_gettime (id, timevalue) for the device / dev/ptp0. The source of the PTP packet is switch Hirschmann MAR1140. Wireshark shows the presence of all necessary for the implementation of the protocol PTP packets at the input adapter interface, but the time in the PTP counters are not adjusted in accordance with the values of the packages. I compiled linuxptp-1.2 downloaded from http://linuxptp.sourceforge.net/ and run the following commands: Hardware timestamping: # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -H 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 ptp4l[3710.039]: port 1: send delay request failed ptp4l[3710.039]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED ptp4l[3725.690]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[3726.698]: port 1: new foreign master ece555.fffe.2de639-2 ptp4l[3731.022]: selected best master clock ece555.fffe.2de639 ptp4l[3731.022]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[3731.193]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[3731.193]: port 1: send delay request failed ptp4l[3731.193]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED Software timestamping: # ptp4l -i p16p1 -p /dev/ptp0 -m -2 -S ptp4l[3826.218]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[3826.218]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[3828.312]: port 1: new foreign master ece555.fffe.2de639-2 ptp4l[3832.218]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[3832.636]: selected best master clock ece555.fffe.2de639 ptp4l[3832.636]: port 1: MASTER to UNCALIBRATED on RS_SLAVE ptp4l[3833.805]: negative path delay -3374260 ptp4l[3833.805]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[3833.805]: t2 - t3 = -87573969 ptp4l[3833.805]: t4 - t1 = +80825448 ptp4l[3833.805]: c1 0 ptp4l[3833.805]: c2 0 ptp4l[3833.805]: c3 0 ptp4l[3833.805]: port 1: minimum delay request interval 2^3 ptp4l[3834.628]: negative path delay -35159469 ptp4l[3834.628]: path_delay = (t2 - t3) + (t4 - t1) ptp4l[3834.628]: t2 - t3 = -910670474 ptp4l[3834.628]: t4 - t1 = +840351536 ptp4l[3834.628]: c1 0 ptp4l[3834.628]: c2 0 ptp4l[3834.628]: c3 0 ptp4l[3834.798]: master offset -10774702751233 s0 adj +0 path delay -19266864 ptp4l[3835.879]: master offset -10774619261329 s0 adj +0 path delay -19266864 What is the difference between hardware and software timestamping in this case? Why Hardware timestamping is not working properly? Why software timestamping shows the correct time values, but does not synchronize time with hardware ptp clock (/dev/ptp0)? Sincerely, Alexander. |
|
From: Richard C. <ric...@gm...> - 2013-07-31 16:33:43
|
On Wed, Jul 31, 2013 at 05:30:17PM +0200, Wolfgang Wallner wrote: > IMHO it would be more accurate to replace the delay_req-line with > "delay_resp receiveTimestamp". Yes, you are right. Care to submit a patch? Thanks, Richard |
|
From: Wolfgang W. <wol...@gm...> - 2013-07-31 15:30:26
|
On Wed, 31 Jul 2013 16:32:56 +0200, Richard Cochran
<ric...@gm...> wrote:
> On Wed, Jul 31, 2013 at 10:41:07AM +0200, Wolfgang Wallner wrote:
>> I did not think of the possibility that the lower layer puts the value
>> of
>> delay_resp.receiveTimestamp into this field.
>
> pdu = protocol data unit, here protocol means the PTP.
>
> There is a long comment in msg.h that describes the time stamp fields.
Do you mean the following comment?
struct {
/**
* Contains the time stamp from the packet data in a
* native binary format for the host machine. The
* exact source of the time stamp's value depends on
* the message type:
*
* - announce originTimestamp
* - follow_up preciseOriginTimestamp
* - sync originTimestamp
* - delay_req originTimestamp
* - pdelay_resp requestReceiptTimestamp
* - pdelay_resp_fup responseOriginTimestamp
*/
struct timestamp pdu;
/**
* Approximate ingress time stamp using the relative
* CLOCK_MONOTONIC. Used to determine when announce
* messages have expired.
*/
struct timespec host;
} ts;
This comment does not fully match the behavior in the
msg_post_recv()-function , as timestamps of delay_req-frames are not
handled in this functions, and delay_resp-frames are missing in the
comment description.
IMHO it would be more accurate to replace the delay_req-line with
"delay_resp receiveTimestamp".
regards, Wolfgang
|
|
From: Richard C. <ric...@gm...> - 2013-07-31 14:43:42
|
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: Richard C. <ric...@gm...> - 2013-07-31 14:33:18
|
On Wed, Jul 31, 2013 at 10:41:07AM +0200, Wolfgang Wallner wrote: > I did not think of the possibility that the lower layer puts the value of > delay_resp.receiveTimestamp into this field. pdu = protocol data unit, here protocol means the PTP. There is a long comment in msg.h that describes the time stamp fields. Thanks, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-31 09:18:58
|
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? Thanks William |
|
From: Wolfgang W. <wol...@gm...> - 2013-07-31 08:41:21
|
On Tue, 30 Jul 2013 17:46:58 +0200, Miroslav Lichvar <mli...@re...> wrote: > On Tue, Jul 30, 2013 at 03:06:28PM +0200, Wolfgang Wallner wrote: >> I'm not sure, but I think the "receiveTimestamp of Delay_Resp >> message"-part is not implemented correctly in LinuxPTP. >> >> The function process_delay_resp() calls clock_path_delay() as follows: >> >> clock_path_delay(p->clock, p->delay_req->hwts.ts, m->ts.pdu, >> m->header.correction); >> >> The third argument is used by clock_path_delay() as what is called t4 in >> the standard. >> As far as I understand the code, the third argument (m->ts.pdu) is the >> ingress timestamp on the slave of the DelayResp-message. >> But I think what should be passed here should be the ingress timestamp >> on >> the master of the DelayReq-message, which is contained in the >> "receiveTimestamp"-field of the DelayResp-message >> (rsp->receiveTimestamp). > > To me, it seems it's the DelayResp receiveTimestamp in the ts.pdu > field and used as t4 in the delay calculation. It's filled by the > following code in the msg_post_recv() function. > > case DELAY_RESP: > timestamp_post_recv(m, &m->delay_resp.receiveTimestamp); Oh, thanks for making this clear :) > > Why do you think it's the ingress time of the DelayResp message? Because at first I misinterpreted the standard. When it says "receiveTimestamp of Delay_Resp message" I thought of the Ingress timestamp of DelayResp. I was confused, and had a look at the source code of LinuxPTP. I found "m->ts.pdu", which at first looks like a timestamp assigned by a lower layer, e.g. the ingress timestamp. I did not think of the possibility that the lower layer puts the value of delay_resp.receiveTimestamp into this field. Sorry for broadcasting my confusion, I should have dug deeper in the code :) Thanks for clearing this up, Wolfgang |
|
From: Richard C. <ric...@gm...> - 2013-07-31 04:30:36
|
On Wed, Jul 31, 2013 at 09:03:52AM +0800, Jason Lin wrote: > > So, can we evaluate the performance of PI controller > by calculating the averages (closer to zero) or standard deviation of > "c->master_offset" in a period? > > Does it make sense? Yes, it does make sense to consider the apparent offset at the slaved clock. Also you can look at the frequency adjustment (or drift). You can increase the observation interval by using the 'summary_interval' configuration option. > But, it is best to evaluate the pulse per second, if hw-supported. Yes. Thanks, Richard |
|
From: Jason L. <ker...@gm...> - 2013-07-31 01:03:58
|
Dear all: After reading some past posts (http://sourceforge.net/mailarchive/message.php?msg_id=30759331), I have a little realization about PI controller. I also find some resources about PID controller: https://controls.engin.umich.edu/wiki/index.php/Recorded_Lectures And definition of synchronization (Frequency synchronization and Time synchronization): http://huawei.com/ilink/cnenterprise/download/HW_194944 There are three states in clock_synchronize(), clock.c, namely SERVO_UNLOCKED, SERVO_JUMP, and SERVO_LOCKED. I think SERVO_JUMP state does time synchronization, and SERVO_LOCKED state does frequency synchronization. The ideal condition is that if the frequency of master clock and ordinary clock is the same, after doing time synchronization, the following "c->master_offset" is zero. So, can we evaluate the performance of PI controller by calculating the averages (closer to zero) or standard deviation of "c->master_offset" in a period? Does it make sense? But, it is best to evaluate the pulse per second, if hw-supported. F.Y.I. Thanks. Jason. 2013/7/26 Keller, Jacob E <jac...@in...> > On Thu, 2013-07-25 at 14:55 +0800, Jason Lin wrote: > > Dear all: > > I am confused about the value of HWTS_KP, HWTS_KI, SWTS_KP, > > and SWTS_KI. > > How are these values decided? > > > > > > Any recommended resources about proportional integral? > > > > > > Thanks. > > Jason. > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > The values are set by the configuration files, and the defaults may be > good for you. Miroslav and Richard know a bit more about how the values > are determined. If I recall, we currently generate these values from > other settings based on the PTP sync rate. > > There are some good resources in the mailing list history via discussion > about servos between Miroslav and Richard that you might try to find. > > I don't have any particularly good resources I could link to you > though.. Clock discipline is somewhat complex. > > The HWTS_KP and HWTS_KI are for hardware timestamping modes, where as > the SWTS_KP and SWTS_KI values are used when we are in software > timestamping mode. Software timestamping is done in the driver just > before handing the data to be transmitted. Hardware timestamping is done > either in the PHY or in the MAC (depends on what type of hardware). > Either type requires that the driver supports it. > > The software timestamp constants are different because software > timestamping has higher latency and so requires different values to > converge in a smooth and stable manner. > > - Jake > |
|
From: Keller, J. E <jac...@in...> - 2013-07-30 20:25:20
|
> -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Tuesday, July 30, 2013 1:12 AM > To: Keller, Jacob E > Cc: Ledda William EXT; lin...@li... > Subject: Re: [Linuxptp-users] HWTSTAMP_TX_ONESTEP_SYNC vs > HWTSTAMP_TX_ON > > On Mon, Jul 29, 2013 at 07:12:20PM +0000, Keller, Jacob E wrote: > > > > FYI, the i210 should have hardware support for doing onestep (no one > > enabled it) > > It is useless, because: > > 1. you have to tell it the offset (different for udp4/udp6/layer2) > 2. it does not correct the udp checksum > > Thanks, > Richard Yep. That would limit it to L2 or UDP without checksum... Which is kind of pointless. It's difficult to get the hardware guys here to care too much about the feature. - Jake |
|
From: Keller, J. E <jac...@in...> - 2013-07-30 20:20:59
|
It is not :( the i210 is a newer part. - Jake > -----Original Message----- > From: Ledda William EXT [mailto:Wil...@it...] > Sent: Tuesday, July 30, 2013 12:49 AM > To: Keller, Jacob E; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] HWTSTAMP_TX_ONESTEP_SYNC vs > HWTSTAMP_TX_ON > > Sorry Jake, but I have a i350 not a i210. Is it true also for i350? > > Thanks > > > -----Original Message----- > From: Keller, Jacob E [mailto:jac...@in...] > Sent: 29 July 2013 21:12 > To: Richard Cochran > Cc: Ledda William EXT; lin...@li... > Subject: Re: [Linuxptp-users] HWTSTAMP_TX_ONESTEP_SYNC vs > HWTSTAMP_TX_ON > > On Mon, 2013-07-29 at 20:18 +0200, Richard Cochran wrote: > > On Mon, Jul 29, 2013 at 01:34:41PM +0000, Ledda William EXT wrote: > > > > > > From my understanding of the PTP protocol, the one-step clock is > "significant" only for the MASTER, e.g. it doesn't send the FOLLOW_UP > because the "tx timestamp" is included in the SYNC. Is it correct? > > > > Yes and no. > > > > This statement is true for E2E delay mechanism. > > > > Theoretically, one step is also possible for the P2P mechanism, but I > > don't think any hardware implements that yet (and neither does > > linuxptp). > > > > HTH, > > Richard > > FYI, the i210 should have hardware support for doing onestep (no one > enabled it) and it could be configured to do either sync, or p2p delay, but > I don't believe it could do both. The i210 is configured by putting in an > offset of where in the packet you want the timestamp to go, but you can't > store different types of packets so it wouldn't work for P2P packets. > > - Jake |
|
From: Miroslav L. <mli...@re...> - 2013-07-30 15:47:13
|
On Tue, Jul 30, 2013 at 03:06:28PM +0200, Wolfgang Wallner wrote:
> I'm not sure, but I think the "receiveTimestamp of Delay_Resp
> message"-part is not implemented correctly in LinuxPTP.
>
> The function process_delay_resp() calls clock_path_delay() as follows:
>
> clock_path_delay(p->clock, p->delay_req->hwts.ts, m->ts.pdu,
> m->header.correction);
>
> The third argument is used by clock_path_delay() as what is called t4 in
> the standard.
> As far as I understand the code, the third argument (m->ts.pdu) is the
> ingress timestamp on the slave of the DelayResp-message.
> But I think what should be passed here should be the ingress timestamp on
> the master of the DelayReq-message, which is contained in the
> "receiveTimestamp"-field of the DelayResp-message (rsp->receiveTimestamp).
To me, it seems it's the DelayResp receiveTimestamp in the ts.pdu
field and used as t4 in the delay calculation. It's filled by the
following code in the msg_post_recv() function.
case DELAY_RESP:
timestamp_post_recv(m, &m->delay_resp.receiveTimestamp);
Why do you think it's the ingress time of the DelayResp message?
--
Miroslav Lichvar
|
|
From: Richard C. <ric...@gm...> - 2013-07-30 13:16:08
|
On Tue, Jul 30, 2013 at 06:18:06PM +0530, Aman Sharma wrote: > > Is there any way to add some delay between the Sync and Follow_up , sync > follow-up and peer delay request in linuxptp. Actually whenever the ptp > application sends 2-3 or more messages very quickly (less than a us ) then > reception logic of our board behaves abruply. So just want to add some > delay in between messages. You can add a delay into the function, port_tx_sync(), in port.c [ This is just a hack. You should really fix your board. ] HTH, Richard |
|
From: Wolfgang W. <wol...@gm...> - 2013-07-30 13:06:36
|
Hello, I have a question about the calculation of the meanPathDelay by the functions process_delay_resp() and clock_path_delay(). The standard says the following about the meanPathDelay computation (section 11.3.2): <meanPathDelay> shall be computed as: <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message – originTimestamp of Sync message) – correctionField of Sync message – correctionField of Delay_Resp message]/2. I'm not sure, but I think the "receiveTimestamp of Delay_Resp message"-part is not implemented correctly in LinuxPTP. The function process_delay_resp() calls clock_path_delay() as follows: clock_path_delay(p->clock, p->delay_req->hwts.ts, m->ts.pdu, m->header.correction); The third argument is used by clock_path_delay() as what is called t4 in the standard. As far as I understand the code, the third argument (m->ts.pdu) is the ingress timestamp on the slave of the DelayResp-message. But I think what should be passed here should be the ingress timestamp on the master of the DelayReq-message, which is contained in the "receiveTimestamp"-field of the DelayResp-message (rsp->receiveTimestamp). Any comments on what is actually correct are welcome :) I'm new to LinuxPTP and try to use it to improve my understanding of 1588. regards, Wolfgang Wallner |
|
From: Aman S. <ama...@gm...> - 2013-07-30 12:48:13
|
Hi All, Is there any way to add some delay between the Sync and Follow_up , sync follow-up and peer delay request in linuxptp. Actually whenever the ptp application sends 2-3 or more messages very quickly (less than a us ) then reception logic of our board behaves abruply. So just want to add some delay in between messages. Thanks for Support in advance. -- regards Aman |
|
From: Miroslav L. <mli...@re...> - 2013-07-30 08:51:50
|
On Tue, Jul 30, 2013 at 10:32:50AM +0200, Richard Cochran wrote: > On Tue, Jul 30, 2013 at 10:12:51AM +0200, Miroslav Lichvar wrote: > > > > Just curious, would it be possible to use the launch time feature of > > i210 to do onestep in software? > > I thought about this, but it might be tricky: > > 1. user sends an event message. > 2. network stack passes skb to driver. > 3. driver picks a future time to send, updates the skb data. > 4. driver places skb into the special queue. > > The tricky part is to pick a safe future transmit time. I was thinking about collecting statistics for successful delays and aiming for a percentage. I'm wondering what is the maximum packet rate one can get with it. Also, if it's not a reply, it might be necessary to read the PTP clock over the bus to calculate the launch time or perhaps it could be derived from the system clock. -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2013-07-30 08:33:09
|
On Tue, Jul 30, 2013 at 10:12:51AM +0200, Miroslav Lichvar wrote: > > Just curious, would it be possible to use the launch time feature of > i210 to do onestep in software? I thought about this, but it might be tricky: 1. user sends an event message. 2. network stack passes skb to driver. 3. driver picks a future time to send, updates the skb data. 4. driver places skb into the special queue. The tricky part is to pick a safe future transmit time. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2013-07-30 08:13:01
|
On Mon, Jul 29, 2013 at 07:12:20PM +0000, Keller, Jacob E wrote: > FYI, the i210 should have hardware support for doing onestep (no one > enabled it) and it could be configured to do either sync, or p2p delay, > but I don't believe it could do both. The i210 is configured by putting > in an offset of where in the packet you want the timestamp to go, but > you can't store different types of packets so it wouldn't work for P2P > packets. Just curious, would it be possible to use the launch time feature of i210 to do onestep in software? -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2013-07-30 08:12:21
|
On Mon, Jul 29, 2013 at 07:12:20PM +0000, Keller, Jacob E wrote: > > FYI, the i210 should have hardware support for doing onestep (no one > enabled it) It is useless, because: 1. you have to tell it the offset (different for udp4/udp6/layer2) 2. it does not correct the udp checksum Thanks, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-30 07:49:02
|
Sorry Jake, but I have a i350 not a i210. Is it true also for i350? Thanks -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: 29 July 2013 21:12 To: Richard Cochran Cc: Ledda William EXT; lin...@li... Subject: Re: [Linuxptp-users] HWTSTAMP_TX_ONESTEP_SYNC vs HWTSTAMP_TX_ON On Mon, 2013-07-29 at 20:18 +0200, Richard Cochran wrote: > On Mon, Jul 29, 2013 at 01:34:41PM +0000, Ledda William EXT wrote: > > > > From my understanding of the PTP protocol, the one-step clock is "significant" only for the MASTER, e.g. it doesn't send the FOLLOW_UP because the "tx timestamp" is included in the SYNC. Is it correct? > > Yes and no. > > This statement is true for E2E delay mechanism. > > Theoretically, one step is also possible for the P2P mechanism, but I > don't think any hardware implements that yet (and neither does > linuxptp). > > HTH, > Richard FYI, the i210 should have hardware support for doing onestep (no one enabled it) and it could be configured to do either sync, or p2p delay, but I don't believe it could do both. The i210 is configured by putting in an offset of where in the packet you want the timestamp to go, but you can't store different types of packets so it wouldn't work for P2P packets. - Jake |
|
From: Keller, J. E <jac...@in...> - 2013-07-29 19:12:47
|
On Mon, 2013-07-29 at 20:18 +0200, Richard Cochran wrote: > On Mon, Jul 29, 2013 at 01:34:41PM +0000, Ledda William EXT wrote: > > > > From my understanding of the PTP protocol, the one-step clock is "significant" only for the MASTER, e.g. it doesn't send the FOLLOW_UP because the "tx timestamp" is included in the SYNC. Is it correct? > > Yes and no. > > This statement is true for E2E delay mechanism. > > Theoretically, one step is also possible for the P2P mechanism, but I > don't think any hardware implements that yet (and neither does > linuxptp). > > HTH, > Richard FYI, the i210 should have hardware support for doing onestep (no one enabled it) and it could be configured to do either sync, or p2p delay, but I don't believe it could do both. The i210 is configured by putting in an offset of where in the packet you want the timestamp to go, but you can't store different types of packets so it wouldn't work for P2P packets. - Jake |
|
From: Keller, J. E <jac...@in...> - 2013-07-29 19:10:54
|
On Mon, 2013-07-29 at 13:12 +0200, Richard Cochran wrote: > On Mon, Jul 29, 2013 at 08:51:58AM +0000, Ledda William EXT wrote: > > > My question is: which is the real difference between HWTSTAMP_TX_ON > > and HWTSTAMP_TX_ONESTEP_SYNC? I mean, what problems could I have if > > I use a modified version without the HWTSTAMP_TX_ONESTEP_SYNC > > support? > > This is just a number passed in the tx_type field of the SIOCSHWTSTAMP > ioctl. It is only used if you set configuration option "twoStepFlag" > to false. So there is no harm in defining it in EXTRA_CFLAGS or in > missing.h. > > Thanks, > Richard If I have a bit of time later today I think I will submit a patch on missing.h to add it, since a proper driver implementation should return invalid if onestep is not supported. - Jake |
27 messages has been excluded from this view by a project administrator.
