No problem. This is a very complex subject, with a lot of nuance, and quite a bit still left "up to implementation"
-----Original Message-----
Sent: Friday, May 17, 2013 6:52 AM
To: Keller, Jacob E
Subject: Re: [Linuxptp-devel] Compiling core kernel
Hi Jacob,
First thanks again for these fantastic explanations. This subject seem
to be quite tricky and your comments really helping a lot.
On Thu, May 16, 2013 at 8:15 PM, Keller, Jacob E
Post by Keller, Jacob EHello,
You could probably modify ptp4l to enable some form of transmit
software timestamping. It would be very high jitter, and I'm not 100%
sure where to put it in this application layer. It definitely wouldn't bare
much on results with a real solution. We don't have the ability to do
application layer because most of the ptp4l development is focused on
Ethernet networking, which should have the SW timestamping enabled
(as it is a 1 line, low impact patch) but due to the way the Tx path works,
it requires modification of the driver, and not all driver owners have
done so. This is due to attempts at trying to perform Tx timestamps
outside the driver layer not being accurate enough, or causing other
issues due to the methods used. The mailing list discussion over this
was so long ago I don't have links to the reasons for this anymore. You
might be able to find it by searching netdev archives.
OK, I guess I will use ptpd for the first measurements, just to set-up
my testbench (find correct GPIOs, connect oscilloscopes, find testing
strategies), to try with and without synchronization.
Then I will start going into the kernel with ptp4l.
think
timestamping
for
Post by Keller, Jacob EPost by Keller, Jacob Esoftware is simpler and works regardless of the driver/connection
type
Post by Keller, Jacob EPost by Keller, Jacob Eused. But there were design issues implementing TX timestamping
the
Post by Keller, Jacob EPost by Keller, Jacob Esame way, as there is too much non-constant delay before the driver
hands the packet to the hardware. PTP is not designed to work in an
environment where delay has high jitter (as in each packet has a
large
Post by Keller, Jacob EPost by Keller, Jacob Evariance in delay from point to point.)
OK, so from what I understand here, both TX and RX timestamping
are
Post by Keller, Jacob EPost by Keller, Jacob Eneeded, and ptp4l does not provide the mechanism that this can be
done
on the application layer, but it must be done in the kernel.
Also, I understood that RX mechanism already exists in the kernel -
no
Post by Keller, Jacob ERx already works, for any driver, as far as I know.
Post by Keller, Jacob ETX timestamping however do not exist in the kernel and must be
done
Post by Keller, Jacob EPost by Keller, Jacob Eon
per-driver basis, and I absolutely have to dig in the driver code to
enable my test set-up (which I absolutely try to avoid, just in order
to have first test set-up very quickly).
You could conceivably add Tx timestmaping to the ptp4l application
layer but I don't know the details of this, and it wouldn't be likely
accepted upstream into the application.
I do not expect this, there must be a good reasons why it was thrown
out in the first place. I was just wondering what is the amount of
work for this to be done.
Post by Keller, Jacob EI assume the best place to do this would be the sk.c layer in the
transmit section. But again this wouldn't bare any resemblance to real
performance.
I guess first idea is to move it there.
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2
&ved=0CEcQFjAB&url=http%3A%2F%2Fwww.iiss.oeaw.ac.at%2Ffiles%2
Fpub%2FMahmood2010.pdf&ei=VTCWUe21H4y4hAe3zYDwAg&usg=AFQ
jCNEmP2nw2jxDPaKP4UsJpu_OP-
gepQ&sig2=i_jB2XO1IYXZ_zk7FSAFfQ&bvm=bv.46751780,bs.1,d.Yms
Here ath5k (madwifi) driver has a part of MAC firmware that moved from
chipset to kernel driver. This way an interrupt can be provoked each
time a packet has been sent out. This way it is not affetced by
carrier sense multiple access/ collision avoidance (CSMA/CA) scheme
imptobabilities, which would introduce the jitter if packed was
timestamped before it was handed to PHY.
The paper reports that with this method the final clock offset
achieved has been 23m6 µS with a standard deviation of 6.1 µSl, which
seems impressive for me having in mind the WiFi connection
drawbacks.
Post by Keller, Jacob EPost by Keller, Jacob EWhat is the essential difference between 802.1AS and PTP ? I am
looking at some presentations, but I still did not quite figured it
out.
I honestly don't know a whole lot. 802.1AS has a few requirements
that PTP says are optional, and the specification goes into detail for
different transmit/receive types and layers about how to handle them.
802.1AS is a mostly compatible but has a few differences to PTP. I don't
know exactly all the details as it's been a while since I read both
specification documents.
In the meantime, in "IEEE P802.1AS proposed clause 7" I found the
7.5 Differences between gPTP and 1588 PTP
1. gPTP assumes all communication between time-aware systems is done
only using 802 MAC PDUs
and addressing, while 1588 supports various layer 2 and layer 3-4
communication methods.
2. gPTP specifies a media-independent sublayer that simplifies the
integration within a single timing
domain of multiple different networking technologies with radically
different media access protocols.
The information exchanged between time-aware systems has been
generalized to support different
packet formats and management schemes appropriate to the particular
networking technology. 1588,
on the other hand, is fully specified only for Ethernet-type LANs and
similar technology.
3. In gPTP there are only two types of time-aware systems: end-points
and bridges, while 1588 has ordinary
clocks, boundary clocks, end-to-end transparent bridges and
peer-to-peer transparent bridges.
A time-aware endpoint corresponds to a 1588 ordinary clock, and a
time-aware bridge is a type of
1588 boundary clock where its operation is very tightly defined . so
much so that a time-aware
bridge with Ethernet ports can be shown to be mathematically
equivalent to a peer-to-peer transparent
bridge, as shown in clause 11.1.3.
4. Time-aware systems only communicate gPTP information directly with
other time-aware systems. I.e,
a gPTP domain consists ONLY of time-aware systems. Non-time-aware
bridges cannot be used to
relay gPTP information. In 1588 it is possible to use non-1588-aware
bridges in a 1588 domain, although
this will slow timing convergence and introduce extra jitter that must
be filtered by any 1588
clock.
5. For Ethernet full-duplex links, gPTP requires the use of the peer
delay mechanism, while 1588 also
allows the use of end-to-end delay measurement.
6. For Ethernet full-duplex links, gPTP requires the use of two-step
processing (use of Follow_up and
Pdelay_resp_follow_up messages to communicate timestamps), while 1588
allows single step processing
(embedding timestamps in messages "on the fly" as they are being
transmitted).
7. In steady state, there is only a single active grandmaster in a
time-aware network. I.e., there is only a
single gPTP domain, whereas 1588 allows multiple overlapping timing domains.
8. All time-aware systems in a gPTP domain are logically syntonized,
meaning that they all measure
time intervals using the same frequency. This is done by the process
described in x, and is mandatory.
Syntonization in 1588 is optional, and the method used is not as
direct and takes longer to converge.
9. The BMCA used in gPTP is the same as that used in 1588 with the
following exceptions: (i) Announce
messages received on a slave port that were not sent by the receiving
time-aware system are
used immediately, i.e., there is no foreign-master qualification, (ii)
a port that the BMCA determines
should be a master port enters the master state immediately, i.e.,
there is no pre-master state, (iii) the
uncalibrated state is not needed and, therefore, not used, and (iv)
all time-aware systems are required
to participate in best master selection (even if it is not grandmaster capable).
10. Finally, this standard includes a formal services definition for
the time-aware applications. (See clause
9.) 1588 does not define how an application provides or obtains time
information.)
Best regards,
Drasko
This is the difference between the standards, but inside the 802.1AS gPTP document there are appendixes which describe methods for syncing across wireless devices. The IEEE 1588 standard doesn't include these, even though it would work with them because it was mainly focused on the Ethernet connections. I believe you can download the standard for free, and read this appendix to get some ideas about how to sync wireless.
The link you gave above seems to be a good result as well.