search

Avnu / OpenAvnu

OpenAvnu - an Avnu sponsored repository for Time Sensitive Network (TSN and AVB) technology
464 stars 289 forks source link

ERROR : GPTP [20:00:17:754] Received Follow up but there is no valid link delay #818

Open hrdksny opened 5 years ago

hrdksny commented 5 years ago

Hi When I am running gPTP at both machines, I am getting below error at listener side. ERROR : GPTP [20:00:17:754] Received Follow up but there is no valid link delay. On further investigation. I am curious about why "ONE_WAY_DELAY_DEFAULT = INVALID_LINKDELAY" is set in the common_port.hpp ? Dose ONE_WAY_DELAY_DEFAULT value should be setup specific ? or Above configuration is fine ? As due to above condition (!port->getLiknDelay()) always been true and observing above error. How can I get rid of above gPTP error ? Should I change the ONE_WAY_DELAY_DEFAULT value as per one way ethernet cable delay ? My setup is two x86 machines connected directly through Ethernet cable.

PawelModrzejewski commented 5 years ago

You can see this error, when gPTP daemon's processing SyncFollowUp and PathDelay hasn't been calculated yet. If it occurs once or twice during start up, it shouldn't be a problem. If you observe this all the time, it points to some general issue with link delay calculation ...

andrew-elder commented 5 years ago

Maybe you can increase the log level to see what is going on.

hrdksny commented 5 years ago

After debugging . . I have changed ONE_WAY_DELAY_DEFAULT value to 200 and neighborPropDelayThresh as 1300. So I can't get the error. Is this ok ? Can I change those values to use gPTP daemon ?

andrew-elder commented 5 years ago

Both machines have i210s in them?

hrdksny commented 5 years ago

No

andrew-elder commented 5 years ago

Do both machines support hardware timestamping of 802.1AS packets?

hrdksny commented 5 years ago

yes

sugnanprabhu commented 5 years ago

I observed a similar issue, when I tried running daemon_cl on one station with the priority 255. On another station with the default priority. @andrew-elder is this an expected behaviour.

andrew-elder commented 5 years ago

The priority should only affect which device is the master. Not the actual timing between them. What is the reported link delay?

Shuchish commented 2 years ago

Getting the same issue, changed ONE_WAY_DELAY_DEFAULT value to 200 and neighborPropDelayThresh as 1300 also but still getting the same results