RPi5-PTP-server/ShowCommands.md

# On Grand Master 

```bash
sudo pmc -u -b 0 'GET CURRENT_DATA_SET'
sudo pmc -u -b 0 'GET PARENT_DATA_SET'
sudo pmc -u -b 0 'GET TIME_STATUS_NP'
sudo pmc -u -b 0 'GET PORT_DATA_SET'
```


Additionally 

chronyc tracking 

and

chronyc sources -v 

can be used 



# On Boundary clocks


```bash
sudo pmc -u -b 0 'GET CURRENT_DATA_SET'
sudo pmc -u -b 0 'GET PARENT_DATA_SET'
sudo pmc -u -b 0 'GET TIME_STATUS_NP'
sudo pmc -u -b 0 'GET PORT_DATA_SET'
```


# On clients


```bash
sudo pmc -u -b 0 'GET TIME_STATUS_NP'
sudo pmc -u -b 0 'GET CURRENT_DATA_SET'
```


# On NYATER


```bash
show ptp clock
show ptp brief
show ptp parent
show ptp packet
```



# Extras



```
journalctl -fu ptp4l-
journalctl -fu phc2sys-
```


# Description




## GET TIME_STATUS_NP

Typical output includes values like:

master_offset              -34
ingress_time                ...
cumulativeScaledRateOffset ...
scaledLastGmPhaseChange     ...
gmTimeBaseIndicator         ...
lastGmPhaseChange           ...
gmPresent                   true
gmIdentity                  88a29efffe826ce6


The interesting bits are:

master_offset
gmPresent
gmIdentity


**master_offset** is in nanoseconds, so something like:

master_offset -34

means the local PTP clock is about 34 ns from its master.



## CURRENT_DATA_SET


This gives you:

stepsRemoved
offsetFromMaster
meanPathDelay

So on my topology I had:

RPi5 GM                 stepsRemoved 0
WOLF-HUNTER BC          stepsRemoved 1
NYATER Nexus BC         stepsRemoved 2
Linux client            stepsRemoved 3

On a client you'll get something along the lines of:

stepsRemoved        3
offsetFromMaster    -21
meanPathDelay       318

Again, the time quantities are effectively nanosecond-scale values.

This is probably the closest thing to a quick **chronyc tracking**


## PARENT_DATA_SET

Look for:

parentPortIdentity
grandmasterIdentity
grandmasterClockQuality
grandmasterPriority1
grandmasterPriority2

You should see your RPi5's MAC:

grandmasterIdentity 88a29efffe826ce6



That confirms the hierarchy:


## GET PORT_DATA_SET

Per-port state


This is especially useful because you can see whether each port is:

SLAVE / CLIENT
MASTER / SERVER
PASSIVE
LISTENING
FAULTY

On boundary clocl you should roughly have:

eno4 (port to GrandMaster)        SLAVE
enp5s0 (port to another boundaryClock)      MASTER
enp5s0d1 (port to another boundaryClock)    MASTER

while upstream device from enp5s0 and enp5s0d1 has:

Eth1/5      Slave
Eth1/6      Passive