unknown
1970-01-01 00:00:00 UTC
You could probably modify ptp4l to enable some form of transmit software ti=
mestamping. It would be very high jitter, and I'm not 100% sure where to pu=
t 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 be=
cause most of the ptp4l development is focused on Ethernet networking, whic=
h should have the SW timestamping enabled (as it is a 1 line, low impact pa=
tch) 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 accurat=
e 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.
t I don't know the details of this, and it wouldn't be likely accepted upst=
ream into the application. I assume the best place to do this would be the =
sk.c layer in the transmit section. But again this wouldn't bare any resemb=
lance to real performance.
optimal. You might try looking at the 802.1AS standard which includes
gPTP which is similar (and there is some support in ptp4l for this
standard) But the IEEE standard document describes some of the issues
for wireless transmission, and may have more information to help you
here.
=20
What is the essential difference between 802.1AS and PTP ? I am
looking at some presentations, but I still did not quite figured it
out.
=20
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 tra=
nsmit/receive types and layers about how to handle them. 802.1AS is a mostl=
y compatible but has a few differences to PTP. I don't know exactly all th=
e details as it's been a while since I read both specification documents.
mestamping. It would be very high jitter, and I'm not 100% sure where to pu=
t 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 be=
cause most of the ptp4l development is focused on Ethernet networking, whic=
h should have the SW timestamping enabled (as it is a 1 line, low impact pa=
tch) 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 accurat=
e 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.
=20
software is simpler and works regardless of the driver/connection type
used. But there were design issues implementing TX timestamping the
same 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
variance in delay from point to point.)
=20
OK, so from what I understand here, both TX and RX timestamping are
needed, and ptp4l does not provide the mechanism that this can be
done
on the application layer, but it must be done in the kernel.
=20
Also, I understood that RX mechanism already exists in the kernel - no
changes needed.
Rx already works, for any driver, as far as I know.Also, can it work without TX timestamping in kernel, because I think
that kernel already has some kind of mechanism of RX timestamping
independent of driver used...
No. You need some form of TX timestamping. The RX timestamping forthat kernel already has some kind of mechanism of RX timestamping
independent of driver used...
used. But there were design issues implementing TX timestamping the
same 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
variance in delay from point to point.)
=20
OK, so from what I understand here, both TX and RX timestamping are
needed, and ptp4l does not provide the mechanism that this can be
done
on the application layer, but it must be done in the kernel.
=20
Also, I understood that RX mechanism already exists in the kernel - no
changes needed.
=20
TX timestamping however do not exist in the kernel and must be done
on
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).
=20
You could conceivably add Tx timestmaping to the ptp4l application layer bu=TX timestamping however do not exist in the kernel and must be done
on
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).
=20
t I don't know the details of this, and it wouldn't be likely accepted upst=
ream into the application. I assume the best place to do this would be the =
sk.c layer in the transmit section. But again this wouldn't bare any resemb=
lance to real performance.
PTP is designed for Ethernet like networks where delay exists but is
relatively stable. That doesn't mean you can't use PTP, but it may not beoptimal. You might try looking at the 802.1AS standard which includes
gPTP which is similar (and there is some support in ptp4l for this
standard) But the IEEE standard document describes some of the issues
for wireless transmission, and may have more information to help you
here.
=20
What is the essential difference between 802.1AS and PTP ? I am
looking at some presentations, but I still did not quite figured it
out.
=20
says are optional, and the specification goes into detail for different tra=
nsmit/receive types and layers about how to handle them. 802.1AS is a mostl=
y compatible but has a few differences to PTP. I don't know exactly all th=
e details as it's been a while since I read both specification documents.
Best regards,
Drasko
Drasko