re is simpler and works regardless of the driver/connection type used. But =
there were design issues implementing TX timestamping the same way, as ther=
e 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 hig=
h jitter (as in each packet has a large variance in delay from point to poi=
nt.)

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.

Also, I understood that RX mechanism already exists in the kernel - no
changes needed.

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).
tively stable. That doesn't mean you can't use PTP, but it may not be optim=
al. 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 transmissi=
on, and may have more information to help you here.

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.

Best regards,
Drasko