Thread: Re: [Linuxptp-users] PHC not being updated correctly
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: prathosh s. <pra...@gm...> - 2022-11-15 12:59:13
|
Hello team, I had no issue with using software time stamping and also I am able to see the hardware timestamping support by building new kernel. But when I try to use the PHC, I see the PHC clock not being updated correctly. I see only the nSec bits being updated. Here are some of the tests I did. --------------------- *root@sama7g5ek-sd:~# phc_ctl eth0 get* *phc_ctl[60533.796]: clock time is 1.010098874 or Thu Jan 1 00:00:01 1970* *root@sama7g5ek-sd:~# phc_ctl eth0 get* *phc_ctl[60536.812]: clock time is 1.015383981 or Thu Jan 1 00:00:01 1970* *root@sama7g5ek-sd:~# phc_ctl eth0 get* *phc_ctl[60541.072]: clock time is 1.022850092 or Thu Jan 1 00:00:01 1970* *------------------------* And also, I tried the PHC sanity check, and it fails to get the correct PHC time. ------------------------- *root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0 get* *phc_ctl[61677.633]: adjusted clock frequency offset to 100000000.000000ppb* *phc_ctl[61677.638]: set clock time to 0.000000000 or Thu Jan 1 00:00:00 1970* *phc_ctl[61687.640]: process slept for 10.000000 seconds* *phc_ctl[61687.641]: clock time is 0.048045447 or Thu Jan 1 00:00:00 1970* *root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0 get* *phc_ctl[61700.096]: adjusted clock frequency offset to 100000000.000000ppb* *phc_ctl[61700.101]: set clock time to 0.000000000 or Thu Jan 1 00:00:00 1970* *phc_ctl[61710.103]: process slept for 10.000000 seconds* *phc_ctl[61710.104]: clock time is 0.088698838 or Thu Jan 1 00:00:00 1970* It would be great, if you could provide any information on this behaviour. Thanks Warm regards Prathosh |
|
From: Miroslav L. <mli...@re...> - 2022-11-15 13:27:21
|
On Tue, Nov 15, 2022 at 12:58:53PM +0000, prathosh shastry wrote: > Hello team, > > I had no issue with using software time stamping and also I am able to see > the hardware timestamping support by building new kernel. But when I try to > use the PHC, I see the PHC clock not being updated correctly. I see only > the nSec bits being updated. Here are some of the tests I did. > > --------------------- > *root@sama7g5ek-sd:~# phc_ctl eth0 get* > > *phc_ctl[60533.796]: clock time is 1.010098874 or Thu Jan 1 00:00:01 1970* It's most likely a bug in the driver. What hardware are you using? -- Miroslav Lichvar |
|
From: prathosh s. <pra...@gm...> - 2022-11-15 14:04:51
|
Hello Miroslav, thanks for your reply. I am using Microchip SAMA7G54, it is an arm cortex A7-based MPU and it does have a PTP time stamping unit at the MAC layer. Enabled the hardware PTP support in the kernel by adding MACB_CAPS_GEM_HAS_PTP and CONFIG_MACB_USE_HWTIMESTAMP. Regards Prathosh On Tue 15 Nov 2022 at 1:27 p.m., Miroslav Lichvar <mli...@re...> wrote: > On Tue, Nov 15, 2022 at 12:58:53PM +0000, prathosh shastry wrote: > > Hello team, > > > > I had no issue with using software time stamping and also I am able to > see > > the hardware timestamping support by building new kernel. But when I try > to > > use the PHC, I see the PHC clock not being updated correctly. I see only > > the nSec bits being updated. Here are some of the tests I did. > > > > --------------------- > > *root@sama7g5ek-sd:~# phc_ctl eth0 get* > > > > *phc_ctl[60533.796]: clock time is 1.010098874 or Thu Jan 1 00:00:01 > 1970* > > It's most likely a bug in the driver. What hardware are you using? > > -- > Miroslav Lichvar > > |
|
From: Jacob K. <jac...@in...> - 2022-11-15 16:39:30
|
On 11/15/2022 4:58 AM, prathosh shastry wrote: > Hello team, > > I had no issue with using software time stamping and also I am able to > see the hardware timestamping support by building new kernel. But when I > try to use the PHC, I see the PHC clock not being updated correctly. I > see only the nSec bits being updated. Here are some of the tests I did. > > --------------------- > /root@sama7g5ek-sd:~# phc_ctl eth0 get/ > > /phc_ctl[60533.796]: clock time is *1.010098874* or Thu Jan 1 > *00:00:01* 1970/ > > /root@sama7g5ek-sd:~# phc_ctl eth0 get____/ > > /phc_ctl[60536.812]: clock time is *1.015383981* or Thu Jan 1 > *00:00:01* 1970/ > > /root@sama7g5ek-sd:~# phc_ctl eth0 get____/ > > /phc_ctl[60541.072]: clock time is *1.022850092* or Thu Jan 1 > *00:00:01* 1970/ > Have you tried set to set the time? At a glance it looks like the MACB driver is doing a bunch of logic that should be replaced by a timecounter+cyclecounter. I can't tell immediately if things are wrong but it looks odd. > /------------------------/ > > And also, I tried the PHC sanity check, and it fails to get the correct > PHC time. > > ------------------------- > /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0 > get____/ > > /phc_ctl[61677.633]: adjusted clock frequency offset to > 100000000.000000ppb____/ > > /phc_ctl[61677.638]: set clock time to 0.000000000 or Thu Jan 1 > 00:00:00 1970____/ > > /phc_ctl[61687.640]: process slept for 10.000000 seconds____/ > > /phc_ctl[61687.641]: clock time is *0.048045447* or Thu Jan 1 00:00:00 > 1970____/ > > /__ __/ > This is asking to set a full 10% faster, and we would expect to see a value of 10 but we get a value 100x slower? This could be a frequency bug. > /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait 10.0 > get____/ > > /phc_ctl[61700.096]: adjusted clock frequency offset to > 100000000.000000ppb____/ > > /phc_ctl[61700.101]: set clock time to 0.000000000 or Thu Jan 1 > 00:00:00 1970____/ > > /phc_ctl[61710.103]: process slept for 10.000000 seconds____/ > > /phc_ctl[61710.104]: clock time is *0.088698838* or Thu Jan 1 00:00:00 > 1970/ > > It would be great, if you could provide any information on this > behaviour. Thanks > > Does a set (without the time value) work? This tries to set the clock to match the current time of day according to the system. That is what the MACB driver appears to do during init, so its curious you see such a small value.. Unless the particular hardware has a much different interval value than the driver expects. Your best bet would probably be to talk to the maintainer of the driver/hardware. Thanks, Jake |
|
From: prathosh s. <pra...@gm...> - 2022-11-15 16:51:36
|
Hello Jacob, Thanks for your reply. Yes, I can use the phc_ctl set and I see the phc being updated to the current time of the day. If I try phc get, again I see only the nSec bits being updated. Looks like it is something to do with the drivers. Regards Prathosh On Tue 15 Nov 2022 at 4:42 p.m., Jacob Keller <jac...@in...> wrote: > > > On 11/15/2022 4:58 AM, prathosh shastry wrote: > > Hello team, > > > > I had no issue with using software time stamping and also I am able to > > see the hardware timestamping support by building new kernel. But when I > > try to use the PHC, I see the PHC clock not being updated correctly. I > > see only the nSec bits being updated. Here are some of the tests I did. > > > > --------------------- > > /root@sama7g5ek-sd:~# phc_ctl eth0 get/ > > > > /phc_ctl[60533.796]: clock time is *1.010098874* or Thu Jan 1 > > *00:00:01* 1970/ > > > > /root@sama7g5ek-sd:~# phc_ctl eth0 get____/ > > > > /phc_ctl[60536.812]: clock time is *1.015383981* or Thu Jan 1 > > *00:00:01* 1970/ > > > > /root@sama7g5ek-sd:~# phc_ctl eth0 get____/ > > > > /phc_ctl[60541.072]: clock time is *1.022850092* or Thu Jan 1 > > *00:00:01* 1970/ > > > > Have you tried set to set the time? > > At a glance it looks like the MACB driver is doing a bunch of logic that > should be replaced by a timecounter+cyclecounter. > > I can't tell immediately if things are wrong but it looks odd. > > > /------------------------/ > > > > And also, I tried the PHC sanity check, and it fails to get the correct > > PHC time. > > > > ------------------------- > > /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait > 10.0 > > get____/ > > > > /phc_ctl[61677.633]: adjusted clock frequency offset to > > 100000000.000000ppb____/ > > > > /phc_ctl[61677.638]: set clock time to 0.000000000 or Thu Jan 1 > > 00:00:00 1970____/ > > > > /phc_ctl[61687.640]: process slept for 10.000000 seconds____/ > > > > /phc_ctl[61687.641]: clock time is *0.048045447* or Thu Jan 1 00:00:00 > > 1970____/ > > > > /__ __/ > > > > This is asking to set a full 10% faster, and we would expect to see a > value of 10 but we get a value 100x slower? This could be a frequency bug. > > > /root@sama7g5ek-sd:~# phc_ctl /dev/ptp0 freq 100000000 set 0.0 wait > 10.0 > > get____/ > > > > /phc_ctl[61700.096]: adjusted clock frequency offset to > > 100000000.000000ppb____/ > > > > /phc_ctl[61700.101]: set clock time to 0.000000000 or Thu Jan 1 > > 00:00:00 1970____/ > > > > /phc_ctl[61710.103]: process slept for 10.000000 seconds____/ > > > > /phc_ctl[61710.104]: clock time is *0.088698838* or Thu Jan 1 00:00:00 > > 1970/ > > > > It would be great, if you could provide any information on this > > behaviour. Thanks > > > > > > Does a set (without the time value) work? This tries to set the clock to > match the current time of day according to the system. > > That is what the MACB driver appears to do during init, so its curious > you see such a small value.. Unless the particular hardware has a much > different interval value than the driver expects. > > Your best bet would probably be to talk to the maintainer of the > driver/hardware. > > Thanks, > Jake > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: Jacob K. <jac...@in...> - 2022-11-15 18:02:02
|
On 11/15/2022 8:51 AM, prathosh shastry wrote: > Hello Jacob, > > Thanks for your reply. Yes, I can use the phc_ctl set and I see the phc > being updated to the current time of the day. If I try phc get, again I > see only the nSec bits being updated. Looks like it is something to do > with the drivers. > > Regards > Prathosh > It is most likely a bug in the frequency calculations done in the MACB driver. I looked at the driver code and it seems suspicious in how it has separated seconds from the small set of nanoseconds. I assume that if you wait a while it just keeps rolling over the nanoseconds? At this point I'd suggest reaching out to netdev and cc'ing the driver maintainers for the MACB drivers in the MAINTAINERS file of Linux. Alternatively you could reach out through whatever other customer support methods you have access to. Thanks, Jake |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X