First, it's very great project. I need to achieve a sub-microsecond sync with ptpd. For doing this, I need ptpd support hardware timestamping. I want to know if this upgrade is in your plan. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes it's in the plan, but, if you want to try something experimental, you can check out the v2_bpf branch and see if the pcap code works for you. This has only been tested on FreeBSD but it ought to work fine on other OSs.
Best,
George
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-09-26
Thank for the tip. It's not working for me. I use Ubuntu 12.04 32 bit. I will try to debug it. The pcap mode is interesting, because it's easy to activate hardware timestamping with this library. in the v2_bpf branch, what mean bpf? Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bpf -> Berkeley Packet Filter. PTPd is developed on top of FreeBSD, and also on Linux. The BSDs have had BPF as a way of getting low level access to the NIC for a long time. I think on Linux this is called a tap, but I forget. At any rate, the code may work on Linux, I have not gotten to the point of testing it there, but others on the project might.
Best,
George
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-09-27
Thanks for your fast response, it's very appreciated. I modified some code to getting ptpd working on my setup. Now I work on the pcap option. It's working but it's have a lot of error message during the running. When my setup work as a attemp, I will send the little modification I have done on the code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I look forward to the patch. Note that the pcap code is a work in progress, and is not yet fully debugged. I'd be very interested in seeing any debugging output, as well as any tcpdump packet captures, that you come up with.
Best,
George
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I built the v2-bpf branch today and gave it a try on my target HW. I didn't try to run in the pcap mode, I just tried to run it as I always have run it. (ptpd2 -g -C). It failed with the following errors:
(ptpd error) 23:43:24.576274 (init) failed query network interfaces (strerror: No such file or directory)
(ptpd error) 23:43:24.576427 (init) failed to initialize network
I ran strace on it and believe this is where the failure occured:
I'm sure this is something simple, but for whatever reason, I can't figure it out!
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-10-03
Hi Chris, I have run into the same issue. In the file src/dep/net.c at line 520, you need to put socket openning berfore interface searching. In my case the switch resolved the problem.
Hi George, I have find a way to get my sub-microsecond sync. It's very easy because I use ptpd in slave mode. I have debug the pcap section in the net.c. After that, I have tell to pcap to take the hardware timestamping on my device. For better result, I have slighty modified pcap to get the nanosecond timestamp of my device.
OK, I've read this over. It requires a change to libpcap so that's something that will have to be worked out with those folks. We can probably form a patch to allow people to update their systems if they so wish. I'm going to look at a way to generalize this patch for FreeBSD and Linux so that both systems are happy with it.
Best,
George
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I applied the ptpd patch and no longer have the regression when running it in the regular UDP multicast mode.
I then started the daemon in pcap mode but it exited because the NIC didn't support HW timestamping on the platform I was testing on. Later this week, I'll try running it on a different platform that does support HW timestamping.
I think it would be good to call "pcap_list_tstamp_types()" during startup to see what timestamp formats are supported and list the supported formats if HW timestamping is not supported.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I may be up a creek with this functionality. The different platform I thought had HW timestamping only has SW TX timestamping (Intel 82579LM). I have one last NIC that I will try which I believe has full 802.1AS support. It's an Intel i210 controller.
I am a little confused thought regarding the e1000e functionality as it does state that it supports "timestamping" but when I run ethtool, it states that it is "SW" timestamping. What is this?
First, it's very great project. I need to achieve a sub-microsecond sync with ptpd. For doing this, I need ptpd support hardware timestamping. I want to know if this upgrade is in your plan. Thanks.
Yes it's in the plan, but, if you want to try something experimental, you can check out the v2_bpf branch and see if the pcap code works for you. This has only been tested on FreeBSD but it ought to work fine on other OSs.
Best,
George
Thank for the tip. It's not working for me. I use Ubuntu 12.04 32 bit. I will try to debug it. The pcap mode is interesting, because it's easy to activate hardware timestamping with this library. in the v2_bpf branch, what mean bpf? Thanks.
bpf -> Berkeley Packet Filter. PTPd is developed on top of FreeBSD, and also on Linux. The BSDs have had BPF as a way of getting low level access to the NIC for a long time. I think on Linux this is called a tap, but I forget. At any rate, the code may work on Linux, I have not gotten to the point of testing it there, but others on the project might.
Best,
George
Thanks for your fast response, it's very appreciated. I modified some code to getting ptpd working on my setup. Now I work on the pcap option. It's working but it's have a lot of error message during the running. When my setup work as a attemp, I will send the little modification I have done on the code.
I look forward to the patch. Note that the pcap code is a work in progress, and is not yet fully debugged. I'd be very interested in seeing any debugging output, as well as any tcpdump packet captures, that you come up with.
Best,
George
I built the v2-bpf branch today and gave it a try on my target HW. I didn't try to run in the pcap mode, I just tried to run it as I always have run it. (ptpd2 -g -C). It failed with the following errors:
(ptpd error) 23:43:24.576274 (init) failed query network interfaces (strerror: No such file or directory)
(ptpd error) 23:43:24.576427 (init) failed to initialize network
I ran strace on it and believe this is where the failure occured:
write(1, "2012-09-29 23:35:08.688036, init"…, 352012-09-29 23:35:08.688036, init, ) = 35
setsockopt(0, SOL_IP, IP_DROP_MEMBERSHIP, "\0\0\0\0\0\0\0\0", 8) = -1 ENOTSOCK (Socket operation on non-socket)
setsockopt(0, SOL_IP, IP_DROP_MEMBERSHIP, "\0\0\0\0\0\0\0\0", 8) = -1 ENOTSOCK (Socket operation on non-socket)
setsockopt(0, SOL_IP, IP_DROP_MEMBERSHIP, "\0\0\0\0\0\0\0\0", 8) = -1 ENOTSOCK (Socket operation on non-socket)
setsockopt(0, SOL_IP, IP_DROP_MEMBERSHIP, "\0\0\0\0\0\0\0\0", 8) = -1 ENOTSOCK (Socket operation on non-socket)
ioctl(-1, SIOCGIFCONF, {320, 7ed0c958}) = -1 EBADF (Bad file descriptor)
write(2, " (ptpd error) ", 19 (ptpd error) ) = 19
gettimeofday({1348961708, 689751}, NULL) = 0
open("/etc/localtime", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "23:35:08.689751 ", 1623:35:08.689751 ) = 16
write(2, " (init) ", 9 (init) ) = 9
write(2, "failed query network interfaces "…, 75failed query network interfaces (strerror: No such file or directory)
When doing the same with the 2.2.1 codebase, I get the following output:
write(1, "2012-09-29 23:33:10.305260, init"…, 352012-09-29 23:33:10.305260, init, ) = 35
setsockopt(0, SOL_IP, IP_DROP_MEMBERSHIP, "\0\0\0\0\0\0\0\0", 8) = -1 ENOTSOCK (Socket operation on non-socket)
setsockopt(0, SOL_IP, IP_DROP_MEMBERSHIP, "\0\0\0\0\0\0\0\0", 8) = -1 ENOTSOCK (Socket operation on non-socket)
setsockopt(0, SOL_IP, IP_DROP_MEMBERSHIP, "\0\0\0\0\0\0\0\0", 8) = -1 ENOTSOCK (Socket operation on non-socket)
setsockopt(0, SOL_IP, IP_DROP_MEMBERSHIP, "\0\0\0\0\0\0\0\0", 8) = -1 ENOTSOCK (Socket operation on non-socket)
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 6
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 7
ioctl(6, SIOCGIFCONF, {64, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"eth0", {AF_INET, inet_addr("172.16.1.126")}}}}) = 0
ioctl(6, SIOCGIFFLAGS, {ifr_name="lo", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0
ioctl(6, SIOCGIFFLAGS, {ifr_name="eth0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(6, SIOCGIFHWADDR, {ifr_name="eth0", ifr_hwaddr=ec:fa:aa:00:48:df}) = 0
ioctl(6, SIOCGIFADDR, {ifr_name="eth0", ifr_addr={AF_INET, inet_addr("172.16.1.126")}}) = 0
setsockopt(6, SOL_SOCKET, SO_REUSEADDR, , 4) = 0
setsockopt(7, SOL_SOCKET, SO_REUSEADDR, , 4) = 0
bind(6, {sa_family=AF_INET, sin_port=htons(319), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
bind(7, {sa_family=AF_INET, sin_port=htons(320), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
setsockopt(6, SOL_SOCKET, SO_BINDTODEVICE, , 4) = 0
setsockopt(7, SOL_SOCKET, SO_BINDTODEVICE, , 4) = 0
setsockopt(6, SOL_IP, IP_MULTICAST_IF, , 4) = 0
setsockopt(7, SOL_IP, IP_MULTICAST_IF, , 4) = 0
setsockopt(6, SOL_IP, IP_ADD_MEMBERSHIP, "\340\0\1\201\254\20\1~", 8) = 0
setsockopt(7, SOL_IP, IP_ADD_MEMBERSHIP, "\340\0\1\201\254\20\1~", 8) = 0
setsockopt(6, SOL_IP, IP_MULTICAST_IF, , 4) = 0
setsockopt(7, SOL_IP, IP_MULTICAST_IF, , 4) = 0
setsockopt(6, SOL_IP, IP_ADD_MEMBERSHIP, "\340\0\0k\254\20\1~", 8) = 0
setsockopt(7, SOL_IP, IP_ADD_MEMBERSHIP, "\340\0\0k\254\20\1~", 8) = 0
setsockopt(6, SOL_IP, IP_MULTICAST_TTL, , 4) = 0
setsockopt(7, SOL_IP, IP_MULTICAST_TTL, , 4) = 0
setsockopt(6, SOL_IP, IP_MULTICAST_LOOP, , 4) = 0
setsockopt(7, SOL_IP, IP_MULTICAST_LOOP, , 4) = 0
setsockopt(6, SOL_SOCKET, 0x23 /* SO_??? */, , 4) = 0
setsockopt(7, SOL_SOCKET, 0x23 /* SO_??? */, , 4) = 0
rt_sigaction(SIGALRM, {SIG_IGN, , SA_RESTART|0x4000000}, {SIG_DFL, , 0}, 8) = 0
rt_sigaction(SIGALRM, {0x190e8, , SA_RESTART|0x4000000}, {SIG_IGN, , SA_RESTART|0x4000000}, 8) = 0
setitimer(ITIMER_REAL, {it_interval={0, 62500}, it_value={0, 62500}}, NULL) = 0
adjtimex({modes=ADJ_FREQUENCY, offset=0, freq=0, maxerror=16000000, esterror=16000000, status=STA_UNSYNC, constant=2, precision=1, tolerance=32768000, time={1348961590, 313408}, tick=10000, ppsfreq=0, jitter=0, shift=0, stabil=0, jitcnt=0, calcnt=0, errcnt=0, stbcnt=0}) = 5 (TIME_ERROR)
I'm sure this is something simple, but for whatever reason, I can't figure it out!
Chris
Hi Chris, I have run into the same issue. In the file src/dep/net.c at line 520, you need to put socket openning berfore interface searching. In my case the switch resolved the problem.
Hi George, I have find a way to get my sub-microsecond sync. It's very easy because I use ptpd in slave mode. I have debug the pcap section in the net.c. After that, I have tell to pcap to take the hardware timestamping on my device. For better result, I have slighty modified pcap to get the nanosecond timestamp of my device.
I have bundle the 2 patch and the result on this link http://dl.dropbox.com/u/12301620/ptpd-hwts.tar.gz.
I hope this will help you!!
Thanks, I've got the files now and will take a look at them presently.
OK, I've read this over. It requires a change to libpcap so that's something that will have to be worked out with those folks. We can probably form a patch to allow people to update their systems if they so wish. I'm going to look at a way to generalize this patch for FreeBSD and Linux so that both systems are happy with it.
Best,
George
I applied the ptpd patch and no longer have the regression when running it in the regular UDP multicast mode.
I then started the daemon in pcap mode but it exited because the NIC didn't support HW timestamping on the platform I was testing on. Later this week, I'll try running it on a different platform that does support HW timestamping.
I think it would be good to call "pcap_list_tstamp_types()" during startup to see what timestamp formats are supported and list the supported formats if HW timestamping is not supported.
OK, I may be up a creek with this functionality. The different platform I thought had HW timestamping only has SW TX timestamping (Intel 82579LM). I have one last NIC that I will try which I believe has full 802.1AS support. It's an Intel i210 controller.
I am a little confused thought regarding the e1000e functionality as it does state that it supports "timestamping" but when I run ethtool, it states that it is "SW" timestamping. What is this?
chealy@chealy-Latitude-E6520:~/v2-bpf/src$ sudo ethtool -i eth0
driver: e1000e
version: 2.0.0-k
firmware-version: 0.13-3
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
chealy@chealy-Latitude-E6520:~/v2-bpf/src$ sudo 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
Also, what is everyone else using NIC wise for HW timestamping?