2

I have an ASUS Pro WS X570-ACE motherboard, with AMD Ryzen 5700G, with on-board Intel I211 Ethernet, running driver igb ver. 5.11.0-27. This also has a Realtek onboard Ethernet, but that is disabled in BIOS. The OS is Linux Mint 20.2 running kernel 5.11.0-27-generic.

Whenever the OS boots up, the following is shown in 'dmesg' output:

 pps_core: LinuxPPS API ver. 1 registered
 pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
 pps pps0: new PPS source ptp0
 pps_ldisc: PPS line discipline registered

And 2 devices show up: /dev/pps0 and /dev/ptp0

I know that it is the Intel I211 port that is doing this because if I run ethtool -T enp5s0 on the adapter, it says:

Time stamping parameters for enp5s0:
Capabilities:
    hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
    software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
    hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
    software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
    software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
    hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
    off                   (HWTSTAMP_TX_OFF)
    on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
    none                  (HWTSTAMP_FILTER_NONE)
    all                   (HWTSTAMP_FILTER_ALL)

The PTP Hardware Clock: 0 means that this creates the /dev/ptp0 and thus /dev/pps0. Here is a list of relevant devices in /dev/:

/dev/port  /dev/ppp  /dev/pps0  /dev/pps1  /dev/psaux  /dev/ptmx  /dev/ptp0  /dev/ptp1  /dev/ptp2

The reason why this PTP is a problem for me is because I use a GPS receiver to set time.

I have a GPS receiver connected via the onboard COM/Serial DB9 connector, which I use to set the time on the computer to micro-second precision using the Pulse Per Second (PPS) coming in onto Pin 1 over the serial. GPSD and CHRONY take care of the rest...but the problem is that GPSD creates its PPS device at /dev/pps1, rather than /dev/pps0 due to the PTP. GPSD normally expects its PPS source to be /dev/pps0. GPSD does work if I specify in the command line to refer to /dev/pps1 as the PPS source...but it takes several more minutes to lock and sync versus a computer that has no PTP at all...

pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
pps pps0: new PPS source ptp0
pps_ldisc: PPS line discipline registered
pps pps1: new PPS source serial0
pps pps1: source "/dev/ttyS0" added

I looked at the Ethtool manual and Intel IGB driver build guide, but there is no parameter that can be set to turn off HARDWARE_TIMESTAMPS. Ethtool only has the -T switch, that shows the timestamping capability...but no actual options you can set via ethtool -T/-t.

Question: Is there a way for me to completely disable this PTP system entirely ?

  • can't you just rebuild you kernel with it disabled, or if it is a module, blacklist that module? maybe add output from `lsmod` – NiKiZe Aug 29 '21 at 18:22
  • Sounds like this is maybe more of a gpsd issue than anything else. Why does gpsd perform differently if you specify a non-default device? Also, another possibile solution is to use udev rules to rename the devices on boot. – alex.forencich Aug 30 '21 at 07:45
  • I would use a different approach: use the honest, simple Realtek net interface and throw away the Intel one. – fraxinus Aug 30 '21 at 08:06

1 Answers1

3

The code to support HC on some intel cards has been added around 2011. The Intel® Ethernet Controller I211-AT supports hardware-based precision time synchronization. It is enabled because the module developers think of it in the following way: (source)

If a MAC has PTP features, then users will sure want it enabled.

Shorter: Your conclusion is correct. Still, you can do several things:

  • Contact the module developers and show your use-case. Convince them that there are good reasons to disable a functionality even if it is generally considered as wanted and turned on by default.
  • Recompile the module with the HC removed.
  • Try to use the Realtek NIC instead.
  • Try to configure gpsd to ignore devices as /dev/pps0 or /dev/ptp0 - according to the documentation is should be possible:

To tell the daemon that a device has been disconnected and is no longer available, send a minus sign ('-') followed by the device name followed by LF or CR-LF. Thus, to remove /dev/foo from the search list, send "-/dev/foo\n".

This should also work automated, by modifying the files under /etc/gpsd/device-hook.

Lutz Willek
  • 653
  • 1
  • 10