Hi all,
I'm trying to synchronize a beaglebone black with a VM (master) running ubuntu, but I'm not able to get the offset from master to decrease below 0.003.
This are that I run
If you want to do anything better than milliseconds, do not use VMs for timing, especially do not run your master in a VM! Unless you use hardware PTP and your VM has direct access to the NIC hardware.
You also seem to be running your slave from USB Ethernet. USB is the second worst option for time sync, just after VMs.
With your current setup, you will not get much better results than NTP - it is good for demo purposes at most. You can try using high message rates like 128/s and enabling filtering - stat filter and outlier filter for both sync and delay messages. Check the ptpd2.conf man page.
Is there any specific reason why you are running the master in a VM, or is this the only "hardware" you have available to test PTP? VMs are just not fit for this purpose.
Thanks,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Wojciech,
thanks for your reply!
Regarding the VM, I had till this morning troubles with the network configuration of a linux pc, so for the time being I was using a VM.
Thankfully the problem now is solved, i tried with the modified message rate, and outlier filter enabled (i still have ptpd 2.3.1) and tried first still using usb0 interface and then via ethernet cable in unicast mode running:
Master: sudo ptpd2 -C - V -u xxx.xxx.169.41 -m -i eth0
Slave: sudo ptpd2 -C - V -u xxx.xxx.169.122 -s -i eth0
Starngely enough the master to slave delay is not that different in these two cases, in both of them it doesn't converge and swings between positive and negative values. definitely better than how it was with the VM though!
You will find it that even with hardware timestamping, the value never completely converges and will always oscillate somewhat. You will not get very good timing when running PTPd without hardware timestamping, especially when it's running as master. However, you can increase the message rates to something like 16/sec or more and it should improve.
Since you have a Beaglebone Black and it supports h/w timestamping, you can switch to using this source: https://github.com/wowczarek/ptpd/tree/wowczarek-2.3.2-hwtest - this is going into PTPd soon. This version has got full h/w intergration for both master and slave. It builds on the BBB fine (I have two Beaglebone Black), however the TI CPSW / CPTS timestamping hardware in the BBB only supports multicast, it will not timestamp unicast PTP packets. There is an example config file test/linuxphc_hw.conf you can use. On the master side you probably want to serve system time, so you can do "clock:master_clock_name=syst". One word of warning - this version of PTPd uses "ptpd" instead of "ptpd2" everywhere.
If both your master and slave support hardware timestamping, you should get good results.
Also unless you plan to make plots of the data, it is best to use the status file (global:status_file=/var/run/ptpd.status). You can watch it in realtime: watch -n 1 cat /var/run/ptpd.status
Regards,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Wojciech,
thanks for the answer and sorry for the late reply i didn't check the forum this past two weeks. Awesome for the 3.2 version! Unfortunately my beagle is running an old kernel with capemgr support and no hw timestamping and I 'm not allowed' to upgrade to a v. 4.1.x! An other question, how the capability of the slave to follow the master is influenced by the Ki and kp of the filters?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no simple answer I'm afraid. There have been multiple books written, courses taught and PHDs received all trying to answer it - not in the context of time sync but of what kP and kI are. The kP and kI parameters are not connected to filters; they are the gains of a Proportional-Integral (PI) controller model which is what's behind the clock control feedback loop used by PTPd. Please refer to basics of control theory and PID/PI controller descriptions, there is plenty of material online. Sufficient to say, they both have influence how quickly the slave adapts to time changes, how long it takes it to stabilise and whether or not it will actually ever stabilise.
4.1.x supports capemanager now, you just need to recompile the overlays with a 4.1 compatible version of dtc, there should be scripts available in /opt/scripts/tools to upgrade, at least on Debian. Unless you are using a very old kernel and/or distribution - recent BBBs come with 3.8 which supports h/w timestamping.
Thanks,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes I know about the 4.1 and dtc, but for my university project I'm using the PRUs as well and I'm not able to upload the overlay I need correctly and we decided to stick with what we are sure that works!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the actual kernel version you're running (uname -r)? My recent BBBs from Element14 came with 3.8.13-bone70 I think, possibly earlier like bone59, and they supported h/w timestamping from the start. It might be worthwhile for you guys to upgrade the kernel and OS to latest versions, test it on one board and deploy to the rest if works. You can always take a copy of the flash and re-image the board if it's not behaving, or just downgrade the kernel. But if you have other dependencies and need to stick to what you have, there is obviously not much that can be done.
Cheers,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
.
mine is bone49! the one we are using is not from element14, but an 'original' one shipping with angstrom, I'm not sure that's the reason. Anyway tomorrow I ll'have to discuss my results, I guess I'll list all this (and patching the beagle with PREEMPT_RT) as ''future works''!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I'm trying to synchronize a beaglebone black with a VM (master) running ubuntu, but I'm not able to get the offset from master to decrease below 0.003.
This are that I run
VM: sudo ptpd2 -V -C -i eth1 -m
beaglebone: ptpd2 -V -C -i usb0 -s
(I've disabled ntpd in both)
this is a sample of the log file:
2016-02-29 14:43:40.777991, slv, 9059affffe549042(unknown)/1, 0.005458132, -0.005968574, 0.009539637, 0.002014966, -311411.403605469, S, 0.000000000, 0, 0.000000000, 0, 0, 0, 0.002014966, 0.009539637
2016-02-29 14:43:41.768214, slv, 9059affffe549042(unknown)/1, 0.005458132, -0.008207207, 0.009539637, -0.007513117, -317379.977605469, S, 0.000000000, 0, 0.000000000, 0, 0, 0, -0.007513117, 0.009539637
2016-02-29 14:43:42.379618, slv, 9059affffe549042(unknown)/1, 0.005314045, -0.008207207, 0.009425633, -0.007513117, -325587.184605469, D, 0.000000000, 0, 0.000000000, 0, 0, 0, -0.007513117, 0.009425633
2016-02-29 14:43:42.561229, slv, 9059affffe549042(unknown)/1, 0.005131601, -0.008207207, 0.009342148, -0.007513117, -325587.184605469, D, 0.000000000, 0, 0.000000000, 0, 0, 0, -0.007513117, 0.009342148
2016-02-29 14:43:42.779386, slv, 9059affffe549042(unknown)/1, 0.005131601, -0.007208955, 0.009342148, 0.003684938, -325587.184605469, S, 0.000000000, 0, 0.000000000, 0, 0, 0, 0.003684938, 0.009342148
2016-02-29 14:43:43.551925, slv, 9059affffe549042(unknown)/1, 0.005072664, -0.007208955, 0.009118708, 0.003684938, -332796.139605469, D, 0.000000000, 0, 0.000000000, 0, 0, 0, 0.003684938, 0.009118708
2016-02-29 14:43:43.769094, slv, 9059affffe549042(unknown)/1, 0.005072664, -0.006579930, 0.009118708, -0.006640534, -332796.139605469, S, 0.000000000, 0, 0.000000000, 0, 0, 0, -0.006640534, 0.009118708
2016-02-29 14:43:44.653371, slv, 9059affffe549042(unknown)/1, 0.005026349, -0.006579930, 0.009310819, -0.006640534, -339376.069605469, D, 0.000000000, 0, 0.000000000, 0, 0, 0, -0.006640534, 0.009310819
2016-02-29 14:43:44.771261, slv, 9059affffe549042(unknown)/1, 0.005026349, -0.010735044, 0.009310819, -0.004730541, -339376.069605469, S, 0.000000000, 0, 0.000000000, 0, 0, 0, -0.004730541, 0.009310819
2016-02-29 14:43:45.782999, slv, 9059affffe549042(unknown)/1, 0.005026349, -0.003831379, 0.009310819, 0.007120482, -350111.113605469, S, 0.000000000, 0, 0.000000000, 0, 0, 0, 0.007120482, 0.009310819
2016-02-29 14:43:45.995645, slv, 9059affffe549042(unknown)/1, 0.005018781, -0.003831379, 0.009497259, 0.007120482, -353942.492605469, D, 0.000000000, 0, 0.000000000, 0, 0, 0, 0.007120482, 0.009497259
2016-02-29 14:43:46.774576, slv, 9059affffe549042(unknown)/1, 0.005018781, -0.003251196, 0.009497259, -0.003577744, -353942.492605469, S, 0.000000000, 0, 0.000000000, 0, 0, 0, -0.003577744, 0.009497259
Hi,
The slave syncs, just very poorly.
If you want to do anything better than milliseconds, do not use VMs for timing, especially do not run your master in a VM! Unless you use hardware PTP and your VM has direct access to the NIC hardware.
You also seem to be running your slave from USB Ethernet. USB is the second worst option for time sync, just after VMs.
With your current setup, you will not get much better results than NTP - it is good for demo purposes at most. You can try using high message rates like 128/s and enabling filtering - stat filter and outlier filter for both sync and delay messages. Check the ptpd2.conf man page.
Is there any specific reason why you are running the master in a VM, or is this the only "hardware" you have available to test PTP? VMs are just not fit for this purpose.
Thanks,
Wojciech
Hi Wojciech,
thanks for your reply!
Regarding the VM, I had till this morning troubles with the network configuration of a linux pc, so for the time being I was using a VM.
Thankfully the problem now is solved, i tried with the modified message rate, and outlier filter enabled (i still have ptpd 2.3.1) and tried first still using usb0 interface and then via ethernet cable in unicast mode running:
Master: sudo ptpd2 -C - V -u xxx.xxx.169.41 -m -i eth0
Slave: sudo ptpd2 -C - V -u xxx.xxx.169.122 -s -i eth0
Starngely enough the master to slave delay is not that different in these two cases, in both of them it doesn't converge and swings between positive and negative values. definitely better than how it was with the VM though!
log file of the unicast case
2016-03-01 16:26:40.704766, slv, 001d60fffe661ad4(unknown)/1, 0.000012875, -0.000009847, 0.000019157, -0.000003018, 38192.622580078, S, 0.000012241, 139, 0.000002252, 5156, 38084, 23, -0.000003018, 0.000019157
2016-03-01 16:26:41.704917, slv, 001d60fffe661ad4(unknown)/1, 0.000012875, -0.000008260, 0.000019157, 0.000012246, 38182.775580078, S, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000012246, 0.000019157
2016-03-01 16:26:41.891099, slv, 001d60fffe661ad4(unknown)/1, 0.000012891, -0.000008260, 0.000015155, 0.000012246, 38174.515580078, D, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000012246, 0.000015155
2016-03-01 16:26:42.499823, slv, 001d60fffe661ad4(unknown)/1, 0.000012918, -0.000008260, 0.000018812, 0.000012246, 38174.515580078, D, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000012246, 0.000018812
2016-03-01 16:26:42.704623, slv, 001d60fffe661ad4(unknown)/1, 0.000012918, -0.000006899, 0.000018812, -0.000000252, 38174.515580078, S, 0.000012241, 139, 0.000002252, 5156, 38084, 23, -0.000000252, 0.000018812
2016-03-01 16:26:43.694388, slv, 001d60fffe661ad4(unknown)/1, 0.000012879, -0.000006899, 0.000010960, -0.000000252, 38167.616580078, D, 0.000012241, 139, 0.000002252, 5156, 38084, 23, -0.000000252, 0.000010960
2016-03-01 16:26:43.704934, slv, 001d60fffe661ad4(unknown)/1, 0.000012879, 0.000017485, 0.000010960, 0.000061020, 38167.616580078, S, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000061020, 0.000010960
2016-03-01 16:26:44.440914, slv, 001d60fffe661ad4(unknown)/1, 0.000012987, 0.000017485, 0.000007323, 0.000061020, 38185.101580078, D, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000061020, 0.000007323
2016-03-01 16:26:44.704620, slv, 001d60fffe661ad4(unknown)/1, 0.000012987, 0.000022885, 0.000007323, 0.000010617, 38185.101580078, S, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000010617, 0.000007323
2016-03-01 16:26:44.940162, slv, 001d60fffe661ad4(unknown)/1, 0.000013173, 0.000022885, 0.000020629, 0.000010617, 38207.986580078, D, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000010617, 0.000020629
2016-03-01 16:26:45.438016, slv, 001d60fffe661ad4(unknown)/1, 0.000013196, 0.000022885, 0.000016771, 0.000010617, 38207.986580078, D, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000010617, 0.000016771
2016-03-01 16:26:45.704941, slv, 001d60fffe661ad4(unknown)/1, 0.000013196, 0.000002753, 0.000016771, 0.000021073, 38207.986580078, S, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000021073, 0.000016771
2016-03-01 16:26:46.179119, slv, 001d60fffe661ad4(unknown)/1, 0.000013251, 0.000002753, 0.000018389, 0.000021073, 38210.739580078, D, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000021073, 0.000018389
2016-03-01 16:26:46.683104, slv, 001d60fffe661ad4(unknown)/1, 0.000013360, 0.000002753, 0.000020321, 0.000021073, 38210.739580078, D, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000021073, 0.000020321
2016-03-01 16:26:46.704623, slv, 001d60fffe661ad4(unknown)/1, 0.000013360, 0.000003069, 0.000020321, 0.000011622, 38210.739580078, S, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000011622, 0.000020321
2016-03-01 16:26:47.704886, slv, 001d60fffe661ad4(unknown)/1, 0.000013360, 0.000000603, 0.000020321, 0.000016305, 38213.808580078, S, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000016305, 0.000020321
2016-03-01 16:26:48.123552, slv, 001d60fffe661ad4(unknown)/1, 0.000013451, 0.000000603, 0.000019036, 0.000016305, 38214.411580078, D, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000016305, 0.000019036
2016-03-01 16:26:48.704595, slv, 001d60fffe661ad4(unknown)/1, 0.000013451, -0.000004410, 0.000019036, 0.000001687, 38214.411580078, S, 0.000012241, 139, 0.000002252, 5156, 38084, 23, 0.000001687, 0.000019036
You will find it that even with hardware timestamping, the value never completely converges and will always oscillate somewhat. You will not get very good timing when running PTPd without hardware timestamping, especially when it's running as master. However, you can increase the message rates to something like 16/sec or more and it should improve.
Since you have a Beaglebone Black and it supports h/w timestamping, you can switch to using this source: https://github.com/wowczarek/ptpd/tree/wowczarek-2.3.2-hwtest - this is going into PTPd soon. This version has got full h/w intergration for both master and slave. It builds on the BBB fine (I have two Beaglebone Black), however the TI CPSW / CPTS timestamping hardware in the BBB only supports multicast, it will not timestamp unicast PTP packets. There is an example config file test/linuxphc_hw.conf you can use. On the master side you probably want to serve system time, so you can do "clock:master_clock_name=syst". One word of warning - this version of PTPd uses "ptpd" instead of "ptpd2" everywhere.
If both your master and slave support hardware timestamping, you should get good results.
Also unless you plan to make plots of the data, it is best to use the status file (global:status_file=/var/run/ptpd.status). You can watch it in realtime: watch -n 1 cat /var/run/ptpd.status
Regards,
Wojciech
Hi Wojciech,
thanks for the answer and sorry for the late reply i didn't check the forum this past two weeks. Awesome for the 3.2 version! Unfortunately my beagle is running an old kernel with capemgr support and no hw timestamping and I 'm not allowed' to upgrade to a v. 4.1.x! An other question, how the capability of the slave to follow the master is influenced by the Ki and kp of the filters?
Hi Valeria,
There is no simple answer I'm afraid. There have been multiple books written, courses taught and PHDs received all trying to answer it - not in the context of time sync but of what kP and kI are. The kP and kI parameters are not connected to filters; they are the gains of a Proportional-Integral (PI) controller model which is what's behind the clock control feedback loop used by PTPd. Please refer to basics of control theory and PID/PI controller descriptions, there is plenty of material online. Sufficient to say, they both have influence how quickly the slave adapts to time changes, how long it takes it to stabilise and whether or not it will actually ever stabilise.
4.1.x supports capemanager now, you just need to recompile the overlays with a 4.1 compatible version of dtc, there should be scripts available in /opt/scripts/tools to upgrade, at least on Debian. Unless you are using a very old kernel and/or distribution - recent BBBs come with 3.8 which supports h/w timestamping.
Thanks,
Wojciech
I've linux 3.8.13 and:
root@arm:/var# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none
Yes I know about the 4.1 and dtc, but for my university project I'm using the PRUs as well and I'm not able to upload the overlay I need correctly and we decided to stick with what we are sure that works!
Hi,
What is the actual kernel version you're running (uname -r)? My recent BBBs from Element14 came with 3.8.13-bone70 I think, possibly earlier like bone59, and they supported h/w timestamping from the start. It might be worthwhile for you guys to upgrade the kernel and OS to latest versions, test it on one board and deploy to the rest if works. You can always take a copy of the flash and re-image the board if it's not behaving, or just downgrade the kernel. But if you have other dependencies and need to stick to what you have, there is obviously not much that can be done.
Cheers,
Wojciech
...by latest version I mean the latest version of 3.8.13.
.
mine is bone49! the one we are using is not from element14, but an 'original' one shipping with angstrom, I'm not sure that's the reason. Anyway tomorrow I ll'have to discuss my results, I guess I'll list all this (and patching the beagle with PREEMPT_RT) as ''future works''!