Re: [Linuxptp-devel] connecting two devices clock via GPIO
Just a short update along the lines of this thread: On top of the previous work on PPS input to i210, I've cobbled together a simple PLL synth with a 25MHz VCXO, good enough to take an external 10 MHz reference and "influence" the crystal on an i210 to run in step with the PPS. (I could as well just desolder the original crystal, but ahh well.) I'm attaching the resulting output of "my" i210 PPS proggie :-) (again based heavily on Mr. Cochran's example.) As for the capturing side of things, both TCPDUMP (PCAP file format) and T-Shark (PCAP-NG file format) work for nanosecond-level capturing. I'm working on a crude analyzer of PTP traffic. I've given up tapping into the Wireshark dissector framework or using raw libpcap (and writing my own PTP dissector from scratch). Instead, I tend to run tshark -V and parse what I need from its textual output. I got through the text parsing and transaction recombination/inference, I have yet to write the output side (dump per-transaction timing data into CSV files suitable for gnuplot). The key bit I'm still looking forward to is the decoding of various timing deltas. I have a "time of capture" timestamp, and the PTP's own payload timestamps, and the correction value... If I understand correctly, the slave will tell me in PDelay Response (+FollowUp, if 2-step) its own timestamp, which should give me a clue about *the slave's* performance... I got this far using a DIY powered tap for metallic 100Mb Ethernet. And then there's the hope that I'd be able to convert (reconfigure) the DeLock gigabit i210 with SFP from SERDES mode into SGMII mode... That's coming up. The 100Mb SGMII SFP's seem quite exotic. If you care, keep your fingers crossed :-) 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_ext_pps.txt Date: 28 Feb 2018, 14:16 Size: 5795 bytes. Type: Text i210_ext_pps.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: capture_parser.txt Date: 28 Feb 2018, 14:24 Size: 2285 bytes. Type: Text capture_parser.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
Re: [Linuxptp-devel] connecting two devices clock via GPIO
...due to problems with direct attachments in this list, please download the attachments mentioned in message text from here: http://support.fccps.cz/download/adv/frr/ptp/i210_ext_pps.zip On 13 Feb 2018 at 17:11, frantisek.rysa...@post.cz wrote: > > Dear everyone (maybe Mr. Cochran especially), > > my setup with external PPS has started showing basic signs of life. > [...] > I'm attaching a crude beta of my servo proggie, based on Mr. > Cochran's example. > For the record, I've implemented a simple software-side filter on the ext_PPS events, so that only leading edges are considered by the servo. And I've re-written the program a bit, but it's mostly convenience addons (getopt parsing, comments...) - the key parts by Mr. Cochran are still firmly in place. I'm attaching my "release candidate", along with a manpage. As the program depends on existing parts of the linuxptp project, I've also added a Makefile patch that adds my i210_ext_pps to the build process. Attached you'll also find a minimal pinout of the common Intel/HP/etc i210 PCI-e nic (board) - note: the input is not 5V tolerant, 3.3V only! ...and an example output (trace, log) from the proggie. I cannot stop grinning... within 10 ns with the basic uncompensated Xtals. Unbelievable. Unlike Mr. Cochran's original that used the first NIC as a PPS source, my cut of the program depends on an external PPS source, all the NIC's are PPS consumers. The program needs to run all the time, as it propels the servo loops that keep the NIC PHC's aligned to external PPS (this is not an autonomous function of the i210 hardware). I hope it helps someone. Frank Rysanek -- 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
Just for the record: On 13 Feb 2018 at 8:05, Richard Cochran wrote: > > The reason for this is that that the i210 latches the time on both > rising and falling edges of the input signal. You can't program it > for rising edge only, for example. > I've checked the datasheet again and you're right, no way to set the polarity of the SDP pins in general, and no way to trigger an auxiliary timestamp on a rising or falling edge only. Ahh well. There are several specific functions of the chip where you can configure the active polarity, but this is not the case with the SDP I/O in general. So I'm gonna have to do this in software. Well at least I can make it polarity-agnostic :-) Frank -- 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
Dear everyone (maybe Mr. Cochran especially), my setup with external PPS has started showing basic signs of life. Interestingly, my two i210 cards seem to be throwing an event on both PPS edges, rising and falling :-) They're spaced 200 ms apart. And, somehow the system converges to the "wrong" edge, which probably is not a problem, and which I could readily correct by flipping polarity at the Meinberg clock, but for other reasons (a 25MHz synth that I'm working on) I would prefer to reconfigure the i210 accordingly. I seem to recall notes from the i210 chip datasheet that the polarity can be adjusted. If you can give me a shortcut on how to do this in the code of your example proggie, it would save me some more time... Maybe I should just check the tools from kernel.org that you've mentioned in your other message. Or back to devmem2. I'm attaching a crude beta of my servo proggie, based on Mr. Cochran's example. See its output below. BTW: Yippeee!! :-D Frank Rysanek i210_ext_pps[1477.035]: ptp4 offset -3 s2 freq -22542 i210_ext_pps[1477.835]: ptp1 offset -200015399 s2 freq -10 i210_ext_pps[1477.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1478.035]: ptp1 offset -3 s2 freq -3720 i210_ext_pps[1478.035]: ptp4 offset 5 s2 freq -22534 i210_ext_pps[1478.835]: ptp1 offset -200015391 s2 freq -10 i210_ext_pps[1478.835]: ptp4 offset -200012381 s2 freq -10 i210_ext_pps[1479.035]: ptp1 offset -4 s2 freq -3722 i210_ext_pps[1479.035]: ptp4 offset -1 s2 freq -22539 i210_ext_pps[1479.835]: ptp1 offset -200015390 s2 freq -10 i210_ext_pps[1479.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1480.035]: ptp1 offset -2 s2 freq -3721 i210_ext_pps[1480.035]: ptp4 offset -3 s2 freq -22541 i210_ext_pps[1480.835]: ptp1 offset -200015389 s2 freq -10 i210_ext_pps[1480.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1481.035]: ptp1 offset 6 s2 freq -3714 i210_ext_pps[1481.035]: ptp4 offset 5 s2 freq -22534 i210_ext_pps[1481.835]: ptp1 offset -200015394 s2 freq -10 i210_ext_pps[1481.835]: ptp4 offset -200012382 s2 freq -10 i210_ext_pps[1482.035]: ptp1 offset 1 s2 freq -3717 i210_ext_pps[1482.035]: ptp4 offset -1 s2 freq -22539 i210_ext_pps[1482.835]: ptp1 offset -200015397 s2 freq -10 i210_ext_pps[1482.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1483.035]: ptp1 offset -2 s2 freq -3720 i210_ext_pps[1483.035]: ptp4 offset -3 s2 freq -22541 i210_ext_pps[1483.835]: ptp1 offset -200015398 s2 freq -10 i210_ext_pps[1483.835]: ptp4 offset -200012385 s2 freq -10 i210_ext_pps[1484.035]: ptp1 offset -2 s2 freq -3720 i210_ext_pps[1484.035]: ptp4 offset -4 s2 freq -22543 i210_ext_pps[1484.835]: ptp1 offset -200015390 s2 freq -10 i210_ext_pps[1484.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1485.035]: ptp1 offset -3 s2 freq -3722 i210_ext_pps[1485.035]: ptp4 offset 5 s2 freq -22535 i210_ext_pps[1485.835]: ptp1 offset -200015397 s2 freq -10 i210_ext_pps[1485.835]: ptp4 offset -200012381 s2 freq -10 i210_ext_pps[1486.035]: ptp1 offset -2 s2 freq -3722 i210_ext_pps[1486.035]: ptp4 offset 0 s2 freq -22539 i210_ext_pps[1486.835]: ptp1 offset -200015396 s2 freq -10 i210_ext_pps[1486.835]: ptp4 offset -200012384 s2 freq -10 i210_ext_pps[1487.035]: ptp1 offset -1 s2 freq -3721 i210_ext_pps[1487.035]: ptp4 offset -3 s2 freq -22542 On 13 Feb 2018 at 11:45, linuxptp-devel@lists.sourcefo wrote: > > Dear Mr. Cochran, > > I've finally got back to my plan (ext.PPS to 2-4 i210 chips for > tcpdump timestamping) and I'm reviewing your proggie. > Yes the code is pretty self-explanatory :-) and packed with gems. > > If I understand correctly, setting up the SDP0 GPIO for external > PPS input (which takes two function calls in your program) > results in the respective phc throwing "events" on every PPS > leading edge - passing them to the user space proggie that > keeps waiting in a poll(), and keeps processing the events > thus received. The event essentially contains a precise timestamp (as > per the i210's timebase) of the PPS leading edge. > And, the "servo" is not autonomous (in hardware or in kernel), it is > in fact implemented by the synbc program, which has to explicitly > instruct the PHC to adjust stepwise or frequency-wise accordingly... > the required "ppb" value actually comes from the servo->sample() > PTP4l library function... > > Interestingly to me, your program seems to instruct the "slave PHC" > (PPS master) to send the pulses every 2 seconds, rather than every 1 > second... am I reading this correctly? > > int index = 0, perout = 20; > > I understand that the PHC's work in wall time, > and I should be able to prime them with the system time, > once on program startup (as I won't have a PPS
Re: [Linuxptp-devel] connecting two devices clock via GPIO
Ohh... excellent, that answers a question from my next message :-) In fact I don't mind if I see the falling edges as well - only I should detect them somehow, by timing calculation if there's no other way, and ignore them in the servo policing loop. As my application is tcpdump timestamping (rather than serving ptp), I'd prefer to use UTC for the timestamps. Oh wait. I'll be timestamping PTP traffic. So I'd better use TAI to have a common timescale inside the packets captured and in the timestamps :-) Allright, I'll probably just subtract a few seconds when setting the PHC's. Frank On 13 Feb 2018 at 8:05, Richard Cochran wrote: > On Tue, Feb 13, 2018 at 11:45:37AM +0100, Frantisek Rysanek wrote: > > Interestingly to me, your program seems to instruct the "slave PHC" > > (PPS master) to send the pulses every 2 seconds, rather than every 1 > > second... am I reading this correctly? > > > > int index = 0, perout = 20; > > The reason for this is that that the i210 latches the time on both > rising and falling edges of the input signal. You can't program it > for rising edge only, for example. > > > I understand that the PHC's work in wall time, > > and I should be able to prime them with the system time, > > once on program startup (as I won't have a PPS master / PTP slave PHC > > in my system). It's just a matter of asking clock_gettime() of the > > system timebase, rather than a particular PHC, in your function > > synbc_settime(). > > Normally the PHC time scale is TAI, which is offset from the system's > UTC by an integer number of seconds. You *can* use whatever time > scale you want, but PTP nodes will expect TAI by default. > > 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 Tue, Feb 13, 2018 at 11:45:37AM +0100, Frantisek Rysanek wrote: > Interestingly to me, your program seems to instruct the "slave PHC" > (PPS master) to send the pulses every 2 seconds, rather than every 1 > second... am I reading this correctly? > > int index = 0, perout = 20; The reason for this is that that the i210 latches the time on both rising and falling edges of the input signal. You can't program it for rising edge only, for example. > I understand that the PHC's work in wall time, > and I should be able to prime them with the system time, > once on program startup (as I won't have a PPS master / PTP slave PHC > in my system). It's just a matter of asking clock_gettime() of the > system timebase, rather than a particular PHC, in your function > synbc_settime(). Normally the PHC time scale is TAI, which is offset from the system's UTC by an integer number of seconds. You *can* use whatever time scale you want, but PTP nodes will expect TAI by default. 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
Dear Mr. Cochran, I've finally got back to my plan (ext.PPS to 2-4 i210 chips for tcpdump timestamping) and I'm reviewing your proggie. Yes the code is pretty self-explanatory :-) and packed with gems. If I understand correctly, setting up the SDP0 GPIO for external PPS input (which takes two function calls in your program) results in the respective phc throwing "events" on every PPS leading edge - passing them to the user space proggie that keeps waiting in a poll(), and keeps processing the events thus received. The event essentially contains a precise timestamp (as per the i210's timebase) of the PPS leading edge. And, the "servo" is not autonomous (in hardware or in kernel), it is in fact implemented by the synbc program, which has to explicitly instruct the PHC to adjust stepwise or frequency-wise accordingly... the required "ppb" value actually comes from the servo->sample() PTP4l library function... Interestingly to me, your program seems to instruct the "slave PHC" (PPS master) to send the pulses every 2 seconds, rather than every 1 second... am I reading this correctly? int index = 0, perout = 20; I understand that the PHC's work in wall time, and I should be able to prime them with the system time, once on program startup (as I won't have a PPS master / PTP slave PHC in my system). It's just a matter of asking clock_gettime() of the system timebase, rather than a particular PHC, in your function synbc_settime(). Interesting stuff. Thank you :-) Frank Rysanek 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 > > --->8--- > /** > * @file synbc.c > * @brief Synchronize the ports of a JBOD Boundary Clock. > * @note Copyright (C) 2015 Richard Cochran > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > * the Free Software Foundation; either version 2 of the License, or > * (at your option) any later version. > * > * This program is distributed in the hope that it will be useful, > * but WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > * GNU General Public License for more details. > * > * You should have received a copy of the GNU General Public License along > * with this program; if not, write to the Free Software Foundation, Inc., > * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > */ > #include > #include > #include > #include > #include > > #include > > #include "clockadj.h" > #include "config.h" > #include "phc.h" > #include "print.h" > #include "servo.h" > #include "util.h" > > #define N_PHC 3 > > static int synbc_extts(int fd, int enable) > { > struct ptp_extts_request extts_request; > int index = 0; > memset(&extts_request, 0, sizeof(extts_request)); > extts_request.index = index; > extts_request.flags = enable ? PTP_ENABLE_FEATURE : 0; > if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) { > pr_err("PTP_EXTTS_REQUEST"); > return -1; > } > pr_info("external time stamp request okay"); > return 0; > } > > static int synbc_pin_input(int fd) > { > struct ptp_pin_desc desc; > int index = 0, pin_index = 0; > > memset(&desc, 0, sizeof(desc)); > desc.index = pin_index; > desc.func = PTP_PF_EXTTS; > desc.chan = index; > if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) { > pr_err("PTP_PIN_SETFUNC"); > return -1; > } > pr_info("set pin function okay"); > return 0; > } > > static int synbc_pin_output(int fd) > { > struct ptp_pin_desc desc; > int index = 0, pin_index = 0; > > memset(&desc, 0, sizeof(desc)); > desc.index = pin_index; > desc.func = PTP_PF_PEROUT; > desc.chan = index; > if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) { > pr_err("PTP_PIN_SETFUNC"); > return -1; > } > pr_info("set pin function okay"); > return 0; > } > > static int synbc_pps_out
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] connecting two devices clock via GPIO
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 --->8--- /** * @file synbc.c * @brief Synchronize the ports of a JBOD Boundary Clock. * @note Copyright (C) 2015 Richard Cochran * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. */ #include #include #include #include #include #include #include "clockadj.h" #include "config.h" #include "phc.h" #include "print.h" #include "servo.h" #include "util.h" #define N_PHC 3 static int synbc_extts(int fd, int enable) { struct ptp_extts_request extts_request; int index = 0; memset(&extts_request, 0, sizeof(extts_request)); extts_request.index = index; extts_request.flags = enable ? PTP_ENABLE_FEATURE : 0; if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) { pr_err("PTP_EXTTS_REQUEST"); return -1; } pr_info("external time stamp request okay"); return 0; } static int synbc_pin_input(int fd) { struct ptp_pin_desc desc; int index = 0, pin_index = 0; memset(&desc, 0, sizeof(desc)); desc.index = pin_index; desc.func = PTP_PF_EXTTS; desc.chan = index; if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) { pr_err("PTP_PIN_SETFUNC"); return -1; } pr_info("set pin function okay"); return 0; } static int synbc_pin_output(int fd) { struct ptp_pin_desc desc; int index = 0, pin_index = 0; memset(&desc, 0, sizeof(desc)); desc.index = pin_index; desc.func = PTP_PF_PEROUT; desc.chan = index; if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) { pr_err("PTP_PIN_SETFUNC"); return -1; } pr_info("set pin function okay"); return 0; } static int synbc_pps_output(clockid_t clkid, int fd) { struct ptp_perout_request perout_request; struct timespec ts; int index = 0, perout = 20; if (clock_gettime(clkid, &ts)) { pr_err("clock_gettime"); return -1; } memset(&perout_request, 0, sizeof(perout_request)); perout_request.index = index; /*disable old setting*/ if (ioctl(fd, PTP_PEROUT_REQUEST, &perout_request)) { pr_err("PTP_PEROUT_REQUEST"); return -1; } perout_request.start.sec = ts.tv_sec + 2; perout_request.start.nsec = 0; perout_request.period.sec = 0; perout_request.period.nsec = perout; if (ioctl(fd, PTP_PEROUT_REQUEST, &perout_request)) { pr_err("PTP_PEROUT_REQUEST"); return -1; } pr_info("periodic output request okay"); return 0; } static int synbc_settime(clockid_t *clkid) { struct timespec ts; int i; if (clock_gettime(clkid[0], &ts)) { pr_err("clock_gettime"); return -1; } for (i = 1; i < N_PHC; i++) { if (clock_settime(clkid[i], &ts)) { pr_err("clock_settime"); return -1; } } return 0; } int main() { int fd[N_PHC], i; clockid_t clkid[N_PHC]; struct config *config; struct pollfd pfd[N_PHC - 1]; struct servo *servo[N_PHC - 1]; char device[64]; handle_term_signals(); print_set_progname("synbc"); print_set_verbose(1); print_set_syslog(0); config