Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

pevsonic
Copy link

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.

@pevsonic pevsonic force-pushed the pevsonic/socketcan_enable_hw_timestamps branch 2 times, most recently from 0ad787e to deb6c79 Compare October 30, 2024 16:46
@pevsonic pevsonic force-pushed the pevsonic/socketcan_enable_hw_timestamps branch 3 times, most recently from e1a7050 to 84e002c Compare October 30, 2024 22:17
can/interfaces/socketcan/socketcan.py Outdated Show resolved Hide resolved
@@ -46,6 +46,13 @@ def _create_base_argument_parser(parser: argparse.ArgumentParser) -> None:
choices=sorted(can.VALID_INTERFACES),
)

parser.add_argument(
Copy link
Collaborator

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

Copy link
Author

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?

Copy link
Collaborator

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.

can/interfaces/socketcan/socketcan.py Outdated Show resolved Hide resolved
can/interfaces/socketcan/socketcan.py Outdated Show resolved Hide resolved
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.
@pevsonic pevsonic force-pushed the pevsonic/socketcan_enable_hw_timestamps branch from 84e002c to 865866d Compare November 1, 2024 12:35
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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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(
Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Use raw hardware timestamp for can messages if available instead
Use raw hardware timestamp for CAN messages if available instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants