-
Notifications
You must be signed in to change notification settings - Fork 604
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
socketcan: support use of SO_TIMESTAMPING for hardware timestamps #1882
base: main
Are you sure you want to change the base?
socketcan: support use of SO_TIMESTAMPING for hardware timestamps #1882
Conversation
0ad787e
to
deb6c79
Compare
e1a7050
to
84e002c
Compare
@@ -46,6 +46,13 @@ def _create_base_argument_parser(parser: argparse.ArgumentParser) -> None: | |||
choices=sorted(can.VALID_INTERFACES), | |||
) | |||
|
|||
parser.add_argument( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not necessary, interface specific parameters can be passed like --can-hardware-timestamps=True
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my perspective, enabling hardware timestamping is a core feature I use and I imagine others might see it that way too. As an argument, it's availability is advertised by --help. Sending as you suggest would (I don't believe?) have any way for the user to see the args availability without understanding the mechanism and digging into the code to find the arg name. Additionally theres no validation on them so if I used --can-hard-we-ar-timestamps=True
there'd be no detection of this, failure or feedback to the user.
Ive not got a big issue with this if you'd like me to drop the argument, but I think there's a solid case for leaving as an argument?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If only one interface supports this argument, i'd prefer to remove it. Otherwise we could add 100 more interface specific "important" arguments.
The current implemenation of socketcan utilises SO_TIMESTAMPNS which only offers system timestamps. I've looked at how can-utils candump.c configures hardware timestamping and implemented this in socketcan as a new option 'can_hardware_timestamps' which is disabled by default to avoid any potential adverse impact on existing usage. Additionally modify logger.py to provide an additional '-H' flag in the same way that candump does in order to use this functionality.
84e002c
to
865866d
Compare
Use raw hardware timestamp for can messages if available instead | ||
of the system timestamp. By default we use the SO_TIMESTAMPNS | ||
interface which provides ns resolution but low accuracy. If your | ||
can hardware supports it you can use this parameter to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can hardware supports it you can use this parameter to | |
CAN hardware supports it you can use this parameter to |
@@ -46,6 +46,13 @@ def _create_base_argument_parser(parser: argparse.ArgumentParser) -> None: | |||
choices=sorted(can.VALID_INTERFACES), | |||
) | |||
|
|||
parser.add_argument( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If only one interface supports this argument, i'd prefer to remove it. Otherwise we could add 100 more interface specific "important" arguments.
alternatively use the SO_TIMESTAMPING interface and request raw | ||
hardware timestamps. These are much higher precision but will | ||
almost certainly not be referenced to the time of day. There | ||
may be other pitfalls to such as loopback packets reporting with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may be other pitfalls to such as loopback packets reporting with | |
may be other pitfalls too such as loopback packets reporting with |
@@ -642,6 +656,17 @@ def __init__( | |||
channel using :attr:`can.Message.channel`. | |||
:param receive_own_messages: | |||
If transmitted messages should also be received by this bus. | |||
:param bool can_hardware_timestamps: | |||
Use raw hardware timestamp for can messages if available instead |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use raw hardware timestamp for can messages if available instead | |
Use raw hardware timestamp for CAN messages if available instead |
The current implemenation of socketcan utilises SO_TIMESTAMPNS which only offers system timestamps.
I've looked at how can-utils candump.c configures hardware timestamping and implemented this in socketcan as an option which is disabled by default to avoid any potential adverse impact on existing usage. This is using the same param 'use_system_timestamp' as established by neovi_bus.py.
I've also modified logger.py to provide an additional '-H' flag in the same way that candump does in order to use this functionality.