Hi,
and all goes well. I upgraded to linuxptp 4.0 in order to activate some
of the newer options and now in the exact same context I am unable to
lock with the messages
don't you use automotive profile or 802.1 AS profiles? Because if so,
there was a change in computations of the time differe
Just make sure the filenames you pass as the "-i" argument are unique if
the two pmc instances can run at the same time.
Martin
Dne 3.10.2022 v 19:19 Rich Schmidt napsal(a):
Thank you Martin,
Indeed the sockets must be rw.
Regards,
Rich Schmidt
$ sudo chmod o+r,o+w /var/run/ptp*
$ ls
t
US Naval Observatory
Washington, DC
On Mon, Oct 3, 2022 at 9:56 AM Martin Pecka wrote:
Hi Jason, that's what the readonly UDS socket is for. With default
configuration and PTP4L master branch, this is how you can query
TIME_STATUS_NP without root:
pmc -u -s /var/run/ptp4lro -i
y point it to /tmp
(this socket is practically useless).
Martin
--
Mgr. Martin Pecka, Ph.D.
Researcher at Vision for Robotics and Autonomous Systems group
Faculty of Electrical Engineering
Czech Technical University in Prague
Phone: +420 22435 7269
smime.p7s
Desc
Hi, I've started getting into this issue too on one of my test computers
(Jetson TX2 + Orbitty Carrier running Ubuntu 18.04). I usually "resolve"
it by rebooting the computer. After a fresh reboot, software
timestamping works.
Does a reboot help in your case?
Martin
Hi,
The command I am try
0 2 0 0x0001 2
Dne 27. 06. 22 v 10:27 Miroslav Lichvar napsal(a):
On Fri, Jun 24, 2022 at 03:50:46PM +0200, Martin Pecka wrote:
38000 ns. But when I turn filling the corrections on, it seems linuxptp is
really struggling to understand what is going on. The master
hought this does not
matter to the PTP protocol.
Thank you for any ideas!
Martin
--
Mgr. Martin Pecka, Ph.D.
Researcher at Vision for Robotics and Autonomous Systems group
Faculty of Electrical Engineering
Czech Technical University in Prague
Phone: +420 22435 7269
___
Hi Patrick,
The use case is: we have a bunch of slave clocks that we would like
to monitor by running pmc on each (+ snmp eventually). If this feature
would allow running pmc without sudo, it would provide an elegant
solution.
I proposed to linuxptp-devel on 29 March patch ([PATCH] UDS: added
On Mar 31, 2022 22:16, "Keller, Jacob E" wrote:
Change the uds_open function to pass in the file mode.
I can do that, but that would require changing the transport_open interface (and thus also raw_open, udp_open etc.) and probably also either port_initialize or adding a member variable to port
You can make two global options, one for each flavor.
I'm sorry, I don't understand your suggestion. Can you explain in a bit more
detail, please?
Right now we have:
uds_address /var/run/ptp4l
uds_ro_address /var/run/ptp4lro
You could add:
uds_address_filemode0660
uds_ro_address_fi
On Wed, Mar 30, 2022 at 04:57:14PM +0200, Martin Pecka wrote:
That works, but it loses the beauty of having a "public" RO port and a
root-only RW port.
You can make two global options, one for each flavor.
I'm sorry, I don't understand your suggestion. Can you explain i
Make it a global option and not a port specific option.
That works, but it loses the beauty of having a "public" RO port and a
root-only RW port.
Martin
smime.p7s
Description: Elektronicky podpis S/MIME
___
Linuxptp-users mailing list
Linuxptp-
Right, the config sections are for network interfaces only.
Is there a way to configure the RO socket without having this side-effect?
What are you trying to accomplish?
That goes along with my proposal (on linuxptp-devel) to allow specifying
file mode for the UDS sockets. Ideally, I'd set
I added the following to my config to set some properties of the
read-only UDS port:
[/var/run/ptp4lro]
# options
However, when I start ptp4l, it creates a superfluous socket that brings
in many problems:
ptp4l[215.643]: ioctl SIOCETHTOOL failed: No such device
ptp4l[215.752]: port 1 (enp2s0
You said this is an Nvidia vendor kernel on the jetson?
I would try a mainline kernel without their hacks.
I've already tried that with this card in a normal x86 Ubuntu computer
with kernels 5.4 and 5.15. The behavior was exactly the same, though.
Martin
smime.p7s
Description: Elektronicky
So it seems the card timestamps FOLLOW_UP and DELAY_RESP packets, but does
not timestamp SYNC packets. Why could this be? Can it somehow mismatch SYNC
and FOLLOW_UP messages in the chip and stamp the wrong one? (I think
FOLLOW_UP stamps are not good for anything, are they?). Or is it still some
pr
mestamp SYNC packets. Why could this be? Can it somehow
mismatch SYNC and FOLLOW_UP messages in the chip and stamp the wrong
one? (I think FOLLOW_UP stamps are not good for anything, are they?). Or
is it still some problem with ptp4l not reading the socket?
--
Mgr. Martin Pecka, Ph.D.
Researc
Okay, I got the Linux 5.11 version compiling on the 4.9 kernel (5.15
version was too new).
This is what I get (not sure if I'm running it correctly):
$ sudo ./timestamp eth2 SOF_TIMESTAMPING_RX_HARDWARE PTPV2
SOF_TIMESTAMPING_TX_HARDWARE IP_MULTICAST_LOOP
SOF_TIMESTAMPING_RAW_HARDWARE SO_TIME
Dne 31. 12. 21 v 1:41 Keller, Jacob E napsal(a):
You won't see igb_process_skb_fields in the grep for ptp, because it
doesn't have ptp in its name, nor does its caller.
Did not mention it, but of course I searched for it with a different
grep pattern. There were none, though! Could there be anot
g/tracing/current_tracer
In January, I'll be able to provide ftrace comparison with the working
igb card.
Thanks for further guidance here.
Martin
--
Mgr. Martin Pecka, Ph.D.
Researcher at Vision for Robotics and Autonomous Systems group
Faculty of Electrical Engineering
Czech Technical U
Thanks for the very prompt reply, Jake. My answers below.
What version of the kernel and drivers are you using?
Linux clone-robot-jetson 4.9.253-tegra #1 SMP PREEMPT Mon Jul 26
12:19:28 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux
driver: igb
version: 5.4.0-k
firmware-version: 1.2.1
driver: ixg
out. So
everything seems okay, yet the sync does not work.
Thank you for any help or hint.
Martin Pecka
smime.p7s
Description: Elektronicky podpis S/MIME
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforg
22 matches
Mail list logo