I try to synchronize a slave on a grand master PTP sever (Meinberg) with following command launched with ptpd master branch daemon:
ptpd2 -ibond0.3064 -d0 --slaveonly --ptpengine:announce_receipt_grace_period=2 -V
The trouble I get is that if I let the slave unsynchronized during multiples hours, when I'll try to synchronize this slave, the time to synchronize can take more than 10 minutes which is very problematic for us (need to be synchronised around 1 or 2 minutes).
With version 2.1.1 of ptpd or with linuxptp on same machine it takes 2 minutes to synchronize (offset from master < 10 micro seconds is enought for us) and with linuxptp around 30 seconds.
Is it still a known bug or is there a parameter I can set to decrease this synchronisation time around 1-2minutes?
I tried many things but this unfortunately does not work.
On our platforms we cannot use linuxptp because ethernet drivers does not support this (even in software mode) and using version ptpd version 2.1.1 does not please me as many improvements seems to be found in 2.3.1
For information here is the command launched with 2.1.1 version.
ptpd2 -D -b bond0.3064 -i 0 -g -f /tmp/ptpd.log
If someone could help me a bit in ptpd configuration it would be very kind.
Regards
Nicolas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PTPd 2.1.1. used to reset the frequency offset on re-sync, also filtering slows the sync down a little, and PTPd 2.3+ scales down the servo integral gain when message rates are higher than 1/second. This can be disabled. Also as far as I remember, linuxptp resets the clock if the offset is above a certain value. Would you be comfortable with just stepping the clock on re-sync?
Does this happen often in your environment that systems are left free-running for long periods of time? If so, would you mind sharing the use case? What message rates are you running at?
It would be helpful if you could share the ptpd log output from a re-sync event so we could see how the offset and frequency correction are behaving and what values they take.
When I find a moment I can give you a few settings that could potentially help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, Thanks for your quick answer.
Before answering to your questions I'll quick explain you the context.
In fact we need to have many platforms synchronized (for audio encryption) around 500 micro seconds and each of those platforms can be stopped during long period. So when they restart it would be a big restriction if we had to wait for many minutes for being synchronized. For those 2 reasons we try to implements ptp instead of ntp protocol for time management.
This week end I stopped my 3 tests platforms ptpd daemon and restarts it this morning, launched ptpd daemon and here are the results of the sync on Grand Master: On the first platform the offset was above 1s so clock was stepped and as you can see in following logs the clock has been quite quicky synchronized. On the second platform the clocks are unsynchronized around 200ms so servo slew the clock with max frequency and it tooks around 15mn to be synchronized with GM (<100 microseconds with GM).
* On the third platform the clock are unsynchronized around 900ms so has with second platform servo slew the clock with max frequency and it took more than 1 hour minutes to be synchronized with GM.
In the attached file I put parts of the three logs (first plt, second plt, third plt). If it is not enough or you want me to add traces, do not hesitate, I can recompile ptpd.
For our use case it would be very helpfull if the time synchronisation with GM (around 100 micro seconds is enough for us) could be less than 2 minutes.
Is it possible with ptpd ? Is there one or multiple parameters to set (I saw that there are multiples and try some but with no results unfortunately today)?
For our purpose we do not need ptpd to be optimized for "precision" but it should be optimized for "quick time convergence".
I think those 2 requests are opposites, so could you please explain me what ptpd parameters should be used for best "quick time convergence" ?
Regards
Nicolas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I found a solution for my trouble, in fact even if I forcethe clock to sync at startup and after to adjtime with max offset ppm set to 1000 (shift 1ms / second), in the worst case I'll be sync in
499ms / 60 = around 8mn.
This is too much for us, so I had this little patch in servo.c end of updateOffset function:
So now step is force until clock is > 10ms and after this it is adjusted. So now I have my ptpd slave that synchronize on GM in less that 10s and it seems to work great!
Maybe it could be usefull to have a parameter in future that could force clock to sync above a certain value (not only if > 1s).
Regards.
Nicolas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I try to synchronize a slave on a grand master PTP sever (Meinberg) with following command launched with ptpd master branch daemon:
ptpd2 -ibond0.3064 -d0 --slaveonly --ptpengine:announce_receipt_grace_period=2 -V
The trouble I get is that if I let the slave unsynchronized during multiples hours, when I'll try to synchronize this slave, the time to synchronize can take more than 10 minutes which is very problematic for us (need to be synchronised around 1 or 2 minutes).
With version 2.1.1 of ptpd or with linuxptp on same machine it takes 2 minutes to synchronize (offset from master < 10 micro seconds is enought for us) and with linuxptp around 30 seconds.
I saw that another post on quite same topics was open 3 years ago.
https://sourceforge.net/p/ptpd/discussion/469208/thread/7cc2a8e1/
Is it still a known bug or is there a parameter I can set to decrease this synchronisation time around 1-2minutes?
I tried many things but this unfortunately does not work.
On our platforms we cannot use linuxptp because ethernet drivers does not support this (even in software mode) and using version ptpd version 2.1.1 does not please me as many improvements seems to be found in 2.3.1
For information here is the command launched with 2.1.1 version.
ptpd2 -D -b bond0.3064 -i 0 -g -f /tmp/ptpd.log
If someone could help me a bit in ptpd configuration it would be very kind.
Regards
Nicolas
Nicolas,
PTPd 2.1.1. used to reset the frequency offset on re-sync, also filtering slows the sync down a little, and PTPd 2.3+ scales down the servo integral gain when message rates are higher than 1/second. This can be disabled. Also as far as I remember, linuxptp resets the clock if the offset is above a certain value. Would you be comfortable with just stepping the clock on re-sync?
Does this happen often in your environment that systems are left free-running for long periods of time? If so, would you mind sharing the use case? What message rates are you running at?
It would be helpful if you could share the ptpd log output from a re-sync event so we could see how the offset and frequency correction are behaving and what values they take.
When I find a moment I can give you a few settings that could potentially help.
Hi Wojciech
First, Thanks for your quick answer.
Before answering to your questions I'll quick explain you the context.
In fact we need to have many platforms synchronized (for audio encryption) around 500 micro seconds and each of those platforms can be stopped during long period. So when they restart it would be a big restriction if we had to wait for many minutes for being synchronized. For those 2 reasons we try to implements ptp instead of ntp protocol for time management.
This week end I stopped my 3 tests platforms ptpd daemon and restarts it this morning, launched ptpd daemon and here are the results of the sync on Grand Master:
On the first platform the offset was above 1s so clock was stepped and as you can see in following logs the clock has been quite quicky synchronized.
On the second platform the clocks are unsynchronized around 200ms so servo slew the clock with max frequency and it tooks around 15mn to be synchronized with GM (<100 microseconds with GM).
* On the third platform the clock are unsynchronized around 900ms so has with second platform servo slew the clock with max frequency and it took more than 1 hour minutes to be synchronized with GM.
In the attached file I put parts of the three logs (first plt, second plt, third plt). If it is not enough or you want me to add traces, do not hesitate, I can recompile ptpd.
For our use case it would be very helpfull if the time synchronisation with GM (around 100 micro seconds is enough for us) could be less than 2 minutes.
Is it possible with ptpd ? Is there one or multiple parameters to set (I saw that there are multiples and try some but with no results unfortunately today)?
Regards
Nicolas
Hi Wojciech
For our purpose we do not need ptpd to be optimized for "precision" but it should be optimized for "quick time convergence".
I think those 2 requests are opposites, so could you please explain me what ptpd parameters should be used for best "quick time convergence" ?
Regards
Nicolas
Hi Wojciech
I think I found a solution for my trouble, in fact even if I forcethe clock to sync at startup and after to adjtime with max offset ppm set to 1000 (shift 1ms / second), in the worst case I'll be sync in
499ms / 60 = around 8mn.
This is too much for us, so I had this little patch in servo.c end of updateOffset function:
if(! ptpClock->offsetFromMaster.seconds && ptpClock->offsetFromMaster.nanoseconds > 1*1E7)
{
ptpClock->clockControl.stepRequired= TRUE;
}
So now step is force until clock is > 10ms and after this it is adjusted. So now I have my ptpd slave that synchronize on GM in less that 10s and it seems to work great!
Maybe it could be usefull to have a parameter in future that could force clock to sync above a certain value (not only if > 1s).
Regards.
Nicolas