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] Despite the patch, "timed out while polling for tx timestamp" keeps happening

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

2017-12-11 Thread Miroslav Lichvar 
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