Re: [Linuxptp-devel] connecting two devices clock via GPIO
On Mon, Dec 11, 2017 at 04:17:14PM +0100, Frantisek Rysanek wrote: > ...oops... ...forgot to post this to the mailing list... and again, my reply was: On Mon, Dec 11, 2017 at 12:42:20PM +0100, Frantisek Rysanek wrote: > If I provide an UTC-synchronous PPS externally (from a GPS receiver), > to maybe 4 ports of i210, how do I reference that precise timestamp > to UTC "time of day" when analyzing a resulting PCAP file ? By the > time of last modification of the file? Or do the four separate PHC's > get synchronized to UTC somehow automagically? No, you must synchronize them. The program I posted shows how to synchronize them to each other. If you have a PPS available, then simply use that as an input to the four cards. You will have to adapt the program in that case. If you don't have a local PPS, but you do have a GM, then you can synchronize one card to the GM via PTP, and then synchronize the other cards to the first card, either using phc2sys (with best effort SW time stamping) or using the SDP signals (with HW time stamping). > The PCAP file normally seems to have an initial absolute timestamp in > the header, consequently Wireshark can show absolute UTC-referenced > timestamps per packet if asked to... Will it work like that with > adapter_unsynced ? Yes, I think so. But remember the HW time stamps will be TAI when using a GM. Wireshark will not know what the timescale actually was. If you interpret what you see on the screen from Wireshark as UTC, then you will be off by the number of leap seconds. > Is the HW timestamping support dependent on the internal metallic > PHY, or does it work with an external SGMII-based fiber PHY as well? On the i210, the time stamps are generated in the MAC (probably from the MII bus) and not in the PHY, and so I would expect fiber to work as well. You can always ask your Intel rep. just to be sure. HTH, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] connecting two devices clock via GPIO
On Mon, Dec 11, 2017 at 04:25:42PM +0100, Frantisek Rysanek wrote: > Oh... and this one also went to Mr. Cochran directly. Apologies. > I already got an answer from him and I'm past this stage, > but I'm forwarding this into the mailing-list "for the record", > to give some food to the Google spider. And also for the record, my off-list reply: On Sun, Dec 10, 2017 at 06:23:07PM +0100, Frantisek Rysanek wrote: > To me, the most unclear parts are especially the "general > timestamping" bits. From the user space, I've noticed the > SO_TIMESTAMPNS and SOF_TIMESTAMPING_RX_HARDWARE = some flags > available from the Linux kernel. They appear to be "mutually > exclusive" ? But the latter should be sufficient for nanosec-level > timestamping? What is the difference between > SOF_TIMESTAMPING_RX_HARDWARE and SOF_TIMESTAMPING_RAW_HARDWARE ? linux/Documentation/networking/timestamping.txt explains everything. > Am i right to assume, that the Intel NIC's can provide RX timestamps > to any packets received, rather than just PTP exclusively? > And, is this capability reachable via the networking driver's > in-kernel API? Yes. > Another point is how to actually capture the data, from user space, > preferably using tools that are ready. > Use libpcap? > Are there any other libraries in Linux along those lines? > Or, should I roll my own capture library? > I'm asking this with respect to nanosecond-level resolution. Just use tcpdump \ -j adapter_unsynced \ --time-stamp-precision=nano \ ... other options TL;DR the rest... > hackable with my tools either :-) So again, if the board maker leaves > the footprint pads unconnected, these are difficult to wiretap with a > hand-held iron. Just get the i210 adapter. The newer ones I've seen already have the header. > So... looking at the proggie from Mr. Cochran, > to configure the PHC in a NIC chip to be a PPS slave, > using a particular SDP pin as an input, I need to open its respective > /dev/phcX and run some fine-tipped ioctl()s on the open fd. Just use the program I posted. Or use the 'testptp' program from the Linux kernel. It can configure the pins via command line. HTH, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] connecting two devices clock via GPIO
Oh... and this one also went to Mr. Cochran directly. Apologies. I already got an answer from him and I'm past this stage, but I'm forwarding this into the mailing-list "for the record", to give some food to the Google spider. FR On 8 Dec 2017 at 15:59, Richard Cochran wrote: > On Fri, Dec 08, 2017 at 11:09:40PM +, Keller, Jacob E wrote: > > I'm thinking the best way is to use the external timestamp events setup, > > and then plug that in as the pps source into phc2sys? > > > > Does this make any sense, or am I paddling up the wrong creek? > > So you *could* extend phc2sys, but that program is complex enough as > is. I have made thoughts about a successor to phc2sys that would > handle gpio based measurements, including setting the pin functions > using the PHC ioctls. > > But for now, I would just write a simple program for your specific > setup. Below is an example for using three i210 cards whose first SDP > are connected. The first card is hard coded as the PPS producer. In > a more realistic JBOD setting, you would want to switch the PPS > producer to be the PHC of the port that takes on the SLAVE role. > > HTH, > Richard Apologies for the intrusion gentlemen... I'm just an end user passing by, but this thread coincides with a related topic that's currently on my mind :-) I've been wondering for a few days, if I could use Intel NIC hardware to capture misc network traffic (libpcap style), with hardware timestamping of incoming packets, at nanosecond resolution. Timestamps on any packets captured, not just PTP - such as, to implement the capturing back-end of a poor man's precision network traffic analyzer. There are several question marks along the way. In the following text, note that I'll answer some questions myselfs, as I'm studying and experimenting (with freshmost upstream GIT code). To me, the most unclear parts are especially the "general timestamping" bits. From the user space, I've noticed the SO_TIMESTAMPNS and SOF_TIMESTAMPING_RX_HARDWARE = some flags available from the Linux kernel. They appear to be "mutually exclusive" ? But the latter should be sufficient for nanosec-level timestamping? What is the difference between SOF_TIMESTAMPING_RX_HARDWARE and SOF_TIMESTAMPING_RAW_HARDWARE ? https://stackoverflow.com/questions/41805687/linux-kernel-udp-receptio n-timestamp Am i right to assume, that the Intel NIC's can provide RX timestamps to any packets received, rather than just PTP exclusively? And, is this capability reachable via the networking driver's in-kernel API? Another point is how to actually capture the data, from user space, preferably using tools that are ready. Use libpcap? Are there any other libraries in Linux along those lines? Or, should I roll my own capture library? I'm asking this with respect to nanosecond-level resolution. There appears to be a common wisdom, permeating the interwebs, that tcpdump and libpcap do not support nanoseconds resolution, that they stick to microseconds. At a closer look, I have to say that it definitely is true about the PCAP file format - that alone appears to be a non-issue. PCAP-NG supports fairly arbitrary resolution, with "microseconds" and "nanoseconds" being popular choices that get actually implemented in libraries available to manipulate those file formats. Wireshark/tshark has nanoseconds support in PCAP-NG files mentioned in the docs for version 2.5.0, but I can actually see nanoseconds resolution in the textual output of tshark 2.4.1. in Linux, precisely "tshark -i eth1" with no custom options... I'm wondering how to find out if tshark uses the HW timestamping capabilities of the kernel and hardware. Interestingly, a nightly build of Wireshark and TShark 2.5.0 still shows microseconds on Windows 64bit (capturing from a local Ethernet interface) and I haven't found any configuration options to switch it to nanoseconds... TCPdump the user-space app doesn't seem to support PCAP-NG, except for some options specific to MacOS X... LibPCAP the capture library DOES seem to support nanoseconds precision! In the changelog of libpcap source code (currently at 1.8/1.9 release), I've found notes that support for nanoseconds was added in 1.5.0 back in 2013 or so... A good keyword to grep for appears to be PCAP_TSTAMP_PRECISION_NANO, and grep also finds references to SOF_TIMESTAMPING_SYS_HARDWARE and SOF_TIMESTAMPING_RAW_HARDWARE in the libpcap source code (pcap-linux.c). Support for pcap-ng seems to be in the current libpcap source code too. Heheh - when I downloaded and compiled fresh libpcap and tcpdump from GIT, the following prints nanosecond timestamps: tcpdump -i eth1 --time-stamp-precision=nano # tcpdump --version tcpdump version 4.10.0-PRE-GIT libpcap version 1.9.0-PRE-GIT (with TPACKET_V3) Only I can't seem to save the data in PCAP-NG format, as tcpdump still doesn't seem to support that... :-( The tcpdump manual mentions some option to save a modified PCAP for
Re: [Linuxptp-devel] connecting two devices clock via GPIO
...oops... ...forgot to post this to the mailing list... On 10 Dec 2017 at 19:20, Richard Cochran wrote: > Just use > > tcpdump \ > -j adapter_unsynced \ > > > > > --time-stamp-precision=nano \ > > > > > ... other options > I've read 'man pcap-tstamp' to see what -j adapter_unsynced means. "High-precision timestamp, not synchronized to the operating system's clock". If I provide an UTC-synchronous PPS externally (from a GPS receiver), to maybe 4 ports of i210, how do I reference that precise timestamp to UTC "time of day" when analyzing a resulting PCAP file ? By the time of last modification of the file? Or do the four separate PHC's get synchronized to UTC somehow automagically? The PCAP file normally seems to have an initial absolute timestamp in the header, consequently Wireshark can show absolute UTC-referenced timestamps per packet if asked to... Will it work like that with adapter_unsynced ? > TL;DR the rest... > TL, admittedly, yes :-) > Just get the i210 adapter. The newer ones I've seen already have the > header. > That's my conclusion too. I'm still wondering if all this is useable for *fiber* tapping / capturing. When speaking about the i210, so far it was in the context of 1000Base-TX (or 10/100/1000) i.e. the built-in PHY. The i210 has another SKU that can directly drive a dumb SERDES transceiver (at 1Gb rate) or can talk to an intelligent external PHY via SGMII. Hence my uncertainty: Is the HW timestamping support dependent on the internal metallic PHY, or does it work with an external SGMII-based fiber PHY as well? I've actually found an off-the-shelf NIC with the i210 and an SFP slot: http://www.delock.de/produkte/G_89481/merkmale.html?setLanguage=en For my "application", I've noticed that there are 100Base-FX SFP transceivers with SGMII interface which would make it feasible to grab 100 Mbit fiber optic traffic using an i210. And, apparently, chances are that they are compatible with the i210: https://embedded.communities.intel.com/thread/8856 > > So... looking at the proggie from Mr. Cochran, > > to configure the PHC in a NIC chip to be a PPS slave, > > using a particular SDP pin as an input, I need to open its respective > > /dev/phcX and run some fine-tipped ioctl()s on the open fd. > > Just use the program I posted. > > Or use the 'testptp' program from the Linux kernel. It can configure > the pins via command line. > coool. Thanks for those pointers :-) Frank Rysanek WPM$SQDV.PM$ Description: Mail message body -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Despite the patch, "timed out while polling for tx timestamp" keeps happening
Dear everyone (Mr. Keller in particular), in the process of fiddling with an addon i210-T1 received today (original Intel board SKU) I have discovered minor havoc in my previously posted data. Over the past few days/weeks I was delighted at how marvellous the onboard i219LM was, while in fact, it turns out that I've been using the second onboard NIC, the i210, all along for PTP. All the praise goes to the i210. The i219LM is inferior in my PC. I'm re-attaching some samples from a running ptp4l. The files also contain a corresponding dump of ethtool -T . I was originally orienting myself by the contents of "dmesg". By the eth0 vs. eth1 originally reported upon device detection. Only today I started to smell a rat (because the addon i210 behaved so very good) and after some fumbling in dmesg, I have noticed that systemd would rename (swap) eth1 for eth0, all along, probably since my kernel upgrade (which I did very early on). Today with the addon board, systemd does a triple rename: eth0 -> eth1 eth1 -> eth2 eth2 -> eth0 :-) Trying to trace the renames in dmesg is prone to confusion. Ultimately my favourite way of mapping the netdevice names to PCI devices is a combination of the following two commands: ethtool -i and lspci The output of ethtool -i contains a row labeled "bus-info", which quotes the familiar bus:device.function triplet, matching those listed by lspci. Which means that I have a tool that's capable of HW timestamping with an error within maybe 20-30 ns. Now for the PPS input and distribution across some 4 boards... I've already ordered some 74LVC1G125 to work as level shifters. Frank Rysanek The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. File information --- File: i210_onboard_arbor.txt Date: 11 Dec 2017, 15:06 Size: 2576 bytes. Type: Unix-text i210_onboard_arbor.txt Description: Binary data The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. File information --- File: i219LM_onboard_arbor_PCH_LOM.txt Date: 11 Dec 2017, 15:05 Size: 2729 bytes. Type: Unix-text i219LM_onboard_arbor_PCH_LOM.txt Description: Binary data The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. File information --- File: i210_addon_intel_original_i210-T1.txt Date: 11 Dec 2017, 15:07 Size: 2504 bytes. Type: Unix-text i210_addon_intel_original_i210-T1.txt Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH] clock: Don't forward management requests to UDS port.
The UDS port is not expected to be used by PTP clocks and forwarding of management messages to the port can be limited to responses. This prevents ptp4l from printing error messages when a management request is received from a non-UDS port and the last client which used the UDS port is no longer listening. Signed-off-by: Miroslav Lichvar --- clock.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/clock.c b/clock.c index 41c8f81..6dbc45e 100644 --- a/clock.c +++ b/clock.c @@ -1243,6 +1243,17 @@ static int clock_do_forward_mgmt(struct clock *c, { if (in == out || !forwarding(c, out)) return 0; + + /* Don't forward any requests to the UDS port. */ + if (out == c->uds_port) { + switch (management_action(msg)) { + case GET: + case SET: + case COMMAND: + return 0; + } + } + if (!*pre_sent) { /* delay calling msg_pre_send until * actually forwarding */ -- 2.9.5 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel