Re: [Linuxptp-devel] connecting two devices clock via GPIO

2018-02-28 Thread Frantisek Rysanek 
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

2018-02-16 Thread Frantisek Rysanek 
...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

2018-02-13 Thread Frantisek Rysanek 
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

2018-02-13 Thread Frantisek Rysanek 
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

Re: [Linuxptp-devel] connecting two devices clock via GPIO

2018-02-13 Thread Frantisek Rysanek 
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

2018-02-13 Thread Frantisek Rysanek 
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(_request, 0, sizeof(extts_request));
>   extts_request.index = index;
>   extts_request.flags = enable ? PTP_ENABLE_FEATURE : 0;
>   if (ioctl(fd, PTP_EXTTS_REQUEST, _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(, 0, sizeof(desc));
>   desc.index = pin_index;
>   desc.func = PTP_PF_EXTTS;
>   desc.chan = index;
>   if (ioctl(fd, PTP_PIN_SETFUNC, )) {
>   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(, 0, sizeof(desc));
>   desc.index = pin_index;
>   desc.func = PTP_PF_PEROUT;
>   desc.chan = index;
>   if (ioctl(fd, PTP_PIN_SETFUNC, )) {
>   pr_err("PTP_PIN_SETFUNC");
>   return -1;
>   }
>   pr_info("set pin function okay");
>   return 0;
> }
> 
> static int

Re: [Linuxptp-devel] connecting two devices clock via GPIO

2017-12-11 Thread Richard Cochran 
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

2017-12-11 Thread Richard Cochran 
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

2017-12-11 Thread Frantisek Rysanek 
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

Re: [Linuxptp-devel] connecting two devices clock via GPIO

2017-12-11 Thread Frantisek Rysanek 
...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

2017-12-08 Thread Richard Cochran 
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(_request, 0, sizeof(extts_request));
extts_request.index = index;
extts_request.flags = enable ? PTP_ENABLE_FEATURE : 0;
if (ioctl(fd, PTP_EXTTS_REQUEST, _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(, 0, sizeof(desc));
desc.index = pin_index;
desc.func = PTP_PF_EXTTS;
desc.chan = index;
if (ioctl(fd, PTP_PIN_SETFUNC, )) {
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(, 0, sizeof(desc));
desc.index = pin_index;
desc.func = PTP_PF_PEROUT;
desc.chan = index;
if (ioctl(fd, PTP_PIN_SETFUNC, )) {
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, )) {
pr_err("clock_gettime");
return -1;
}
memset(_request, 0, sizeof(perout_request));
perout_request.index = index;
/*disable old setting*/
if (ioctl(fd, PTP_PEROUT_REQUEST, _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, _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], )) {
pr_err("clock_gettime");
return -1;
}
for (i = 1; i < N_PHC; i++) {
if (clock_settime(clkid[i], )) {
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 = config_create();
if

[Linuxptp-devel] connecting two devices clock via GPIO

2017-12-08 Thread Keller, Jacob E 
Hey Richard and others,

I've been recently investigating a setup where two ethernet devices with 
support for PHCs have hooked up one GPIO pin from one device into a GPIO of the 
second device. The intent was to have the first device trigger a PPS signal on 
the pin, while the second device measures timestamps essentially replicating 
what the /dev/ppsX devices do but scoped to the second device's clock instead 
of under the system time.

I see that there's already code for tuning systime using a PPS device, but am 
wondering what the best way to expose this setup. The goal is to use phc2sys in 
order to tune the second device's clock from the generated timestamps of the 
pps signal on the first device.

The end goal is to setup a boundary clock with higher precision than the jbod 
setup (since we'd have the GPIO pin connection).

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?

Thanks,
Jake

--
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