porting ptpd-2.3.0 on Lynxos

[Caterina]

Hi all,

I need once again your help.
I succesfully compiled and run ptpd 2.3.0 on two RedHat6.1 machines (directly connected with a cable).
Now, I have to port ptpd on a Lynxos machine. One of the most difficult issue is the lacking of the timex.h. How do you suggest to me to proceed with the porting?

Many thans,
Caterina

[Jan Breuer]

Hi Caterina,
before porting, you can create some test programs to help you understand everything.

I thing, that it has some sort of POSIX API support so you just need to port time manipulating functions and network layer.

Time manipulation:
There are three main functions you need to implement getTime, setTime and adjTime. You can create simple test programs to implement these funcionality in separate source to see if it works properly. If your system does not have any support of adjusting frequency of time base (adjtimex on linux), you can have a look at OSX port - there are no frequency adjustments at all.

Network manipulation:
You need to reimplement function to find network interface - it can be stupid and return MAC, IP and name of your only one interface.
You need to verify UDP multicast support of your OS.
You also need to implement some type of RX packet timestamping. You need to verify multicast loopback support or implement also TX packet timestamping.

Everything other should work or can be commented out (like in OSX port).

Best regards,
Jan

[Caterina]

Dear Jan,

I'm following your suggestions, so I'm using as guideline the define APPLE in ptpd 2.3.0 code.
But during compiling(linking) I get the following error:

servo.o: In function updatePtpEngineStats': servo.o(.text+0x21bc): undefined reference tosaveDrift'

That's because the updatePtpEngineStats function uses the saveDrift function which is in the sys.c source but it's not defined for the APPLE platform. I don't have an Mac available so I'm not able to understand whether the saveDrift is really needed. Do you have any suggestion?

In addition, looking into sys.c: At line 1611 (function restoreDrift) there is a #if defined(APPLE) test. But this should be ruled out by the #if !defined(APPLE) at line 1486.

Am I getting something wrong?
Many thanks,

Caterina

[Jan Breuer]

Hi Caterina,
maybe it is a bug. I thing that saveDrift is not needed in your situation.

Jan

[Caterina]

Dear Jan,

Many thanks for your support.
I'll let you know the progress about the work.

Best regards,
Caterina

[Caterina]

I’ve successfully compiled and run ptpd-2.3.0 over a Lynxos machine. So, first of all thanks for your support.
Now I’m doing some tests with a RedHat6.1 machine (masteronly mode) directly connected to the Lynx machine (slaveonly mode).
I made a first rough test: I changed the system clock of the RedHat machine and I verified (using the “date” command) that the Lynxos machine itself changes its system clock.
In the statistics file generated by the ptpd application, the offset has the behavior you can see in the attached .jpg file: it is a ramp that wraps whenever the offset reaches the 1 second mark. Initially I thought it was because of the lack of the adjFreq on Lynxos but changing the frequency of the Sync message (as suggested in
https://sourceforge.net/p/ptpd/discussion/469208/thread/e8b86f0f/#991b
) but nothing seems to change: the offset always reaches 1 second and then it is reset to zero. In fact, as you can see in the ptpd2.log (I’ll attach it in the next post , just the part where the fault happens) the offset reaches the zero mark because of a fault and not because of a sync message reception.

Using the RedHat machine as slaveonly and the Lynx machine as masteronly the offset seems good, with a max value of 48 us, a mean of -0.1 us and a standard deviation of 11us.

Have you got any suggestions about the offset behavior of the Lynx machine in slave mode?
Many thanks,
Caterina

[Caterina]

Please find attached the ptpd.log related to the previous post.
Many thanks,

Caterina

[Wojciech Owczarek]

The issue behind the compile error on OSX and other systems without adjtimex() has been fixed in subversion some time ago - there's no reference to APPLE for this any more but instead there's an autoconf check for timex.h. I would also say that LynxOS has little similarity to OSX.

Anyway - we don't have access to your platform so we can't see what's happening.

A good test would be to compile on Linux without ADJTIMEX support. This is very easy - after you've run the configure script, you edit config.h and comment the line:

//#define HAVE_SYS_TIMEX_H 1

then run make again and test sync between two Linux machines - if the same behaviour shows, this may be a wider problem and not LynxOs specific.

[Jan Breuer]

I'm afraid that undefinig this will not work. At least in current trunk.

Imagine this situation and suppose HAVE_SYS_TIMEX_H is not defined

        if (!rtOpts->noAdjust)
#ifdef HAVE_SYS_TIMEX_H
          adjFreq_wrapper(rtOpts, ptpClock, 0);
#endif /* HAVE_SYS_TIMEX_H */
        ptpClock->servo.observedDrift = 0;

At least in sys.c, these constructs are multiple times and they are wrong. It should be

        if (!rtOpts->noAdjust) {
#ifdef HAVE_SYS_TIMEX_H
          adjFreq_wrapper(rtOpts, ptpClock, 0);
#endif /* HAVE_SYS_TIMEX_H */
        }
        ptpClock->servo.observedDrift = 0;

or

#ifdef HAVE_SYS_TIMEX_H
        if (!rtOpts->noAdjust)
          adjFreq_wrapper(rtOpts, ptpClock, 0);
#endif /* HAVE_SYS_TIMEX_H */
        ptpClock->servo.observedDrift = 0;

[Wojciech Owczarek]

Well spotted - luckily this was introduced after 2.3.0.

[Wojciech Owczarek]

I'm afraid that your log doesn't show much. Perhaps you should increase the debug level.

[Caterina]

Hi Wojciech,

Thanks for your suggestion. I had some more tests during these days.
I think that there is a bug in the ptpd version I'm using which is ptpd-2.3.0.
In the source file src/dep/servo.c , in the function updateClock , line 908 the right call to adjtime shoud be:

if defined(APPLE)

adjTime( -ptpClock->offsetFromMaster.nanoseconds);

else

...

endif

I mean with che minus sign passing the actual argument to the function.

Just to be more understandable, please find in attachment the upDateClock function with this change.
Are you agree or am I wrong?

Many thanks,
Caterina

[Jan Breuer]

I don't know if it is correct or not, I have never try it, but I thing that you should rather modify adjTime function implementation for your platform to use different sign.

We should at least investigate this situation because there are now some other bugs.

[Wojciech Owczarek]

Jan - what other bugs? The place where observedDrift is not reset? I don't think this is necessarily a bug. [EDIT: I looked closer - it is].

I don't think adjtime can take a negative or positive argument on different platforms. It's an old function originating from 4.3 BSD and Unix (although not part of POSIX spec).

Regarding the code Catarina mentioned, she is correct. This code has appeared in r134 along with OSX support and I think it has been wrong from the start. It's logical that when your offset is X us, you want to shift the frequency by -X ppm. With the current code the servo winds up to maximum shift until it shifts by a second, then steps, and so on.

I have OpenBSD to hand which will also use adjtime (it has a separate adjfreq but that's a whole different story). I had the same wind-up issue with it. I'm going to try this now. Although it will only run in software CPU emulation and is excruciatingly slow.

Going by this, I think nobody (bar Kyle maybe) has tested ptpd on OSX beyond just checking if it builds.

[Jan Breuer]

Wojciech, I just thought that LynxOS does not have adjtime system call, my fault. And the bug I mean was ifdef HAVE_SYS_TIMEX_H. You solved everything at a glance. Thank you.

[Wojciech Owczarek]

Caterina,

This has been commited to the source repository and will be included in the 2.3.1 version due soon.

[Wojciech Owczarek]

Confirmed working on OpenBSD and on Linux with adjtimex disabled.

Once 2.3.1rc1 is out we can get some OSX user(s) to test.