From: Wojciech O. <woj...@ow...> - 2013-05-27 10:14:50
|
Hi Jan, 1) Fair point, it's an easy fix the current way, we can merge the functions later 2) I'm working on config file implementation, we won't need to worry about switches soon, more info coming. 3) I thought so, just haven't looked into it 4) Fair point and easy fix again. Regards, Wojciech - Wojciech Owczarek On 27 May 2013, at 08:09, Jan Breuer <jan...@ja...> wrote: > Hi All, > > this is great! > > I didn't test it, but I look into the code and I have some proposals. > > 1) P2P mode will not work, because it uses multicast address 224.0.0.107. P2P for Ethernet mode is just not implementet. We should unify netSend and netRecv functions. We should use defines in constant_dep.h for port numbers and addresses. > > 2) We can save the -e switch for the future by adding modifier defining the Network Protocol - for now UDP_IPV4, IEEE_802_3 and in the future for example UDP_IPV6. This can avoid wasting of switches like for "Delay Mechanism". > Example: ptpd -g -e IEEE_802_3 > > 3) If I remember it correctly, solving ICMP problem is easy. I played with PCAP years ago for windows port. If using PCAP you should call recv on the eventSock or generalSock and just discard the packet. > > 4) Ethernet mode should not join to UDP/IPv4 multicast groups. > > If you don't work on these problems, I can prepare some patches - at least for 2 and 4. > > Best, > Jan > > > 2013/5/27 Wojciech Owczarek <woj...@ow...> > George, > > It's similar on Linux - PCAP gets the data even before they hit IPFilter / IPTables - straight off the driver. The latest pcap versions allow you to set the timestamp resolution (using arbitrary keywords like HIGH/LOW) but I still need to establish if you can get ns resolution in the newer kernels. > > So basically very similar to FreeBSD, however I'm not sure how the performance actually compares. The SyncLab / RADClock guys did some benchmarks with BPF included, but Linux unfortunately was not tested. > > Regards > Wojciech > > > On 27 May 2013 02:36, George Neville-Neil <gn...@ne...> wrote: > > On May 26, 2013, at 18:33 , Wojciech Owczarek <woj...@ow...> wrote: > > > George, All, > > > > I just submitted some minor fixes to the PCAP code - tested on Linux: RHEL6 and Ubuntu. Hybrid and unicast modes should be working OK with PCAP now [ only slave mode tested! ] > > > > Great, I'll check them on FreeBSD in the next day or so. > > > Naturally PCAP works fine on Linux. I don't think there is a more portable solution in userspace. > > > > Observations so far: > > > > - accuracy improved by approx 5us straight away, precision improved as well due to lower jitter > > - unfortunately servo output will be a little jittery (short-term jitter in smaller scale - "thicker" plots basically), reason being that pcap we're back to microsecond timestamp resolution - not much can be done about it it seems, even with the latest libpcap > > - need to double check socket initialisation and handling when using pcap: ptpd is currently bounding back ICMP unreachables in reaction to unicast delay responses. Doesn't break anything on the slave side but shouldn't be happening. > > So one thing that will happen on FreeBSD, but I"m not sure on Linux is that with BPF > we take the timestamp right above the network driver, before any other part of the system > sees the packet. That was one of my main motivations for doing that. The other thing > that will eventually go into the code is that BPF/PCAP on FreeBSD can now have > nanosecond timestamps, as of FreeBSD 10 (CURRENT). Once I test that I'll add those > switches to the code. > > Best, > George > > > > > -- > - > > Wojciech Owczarek > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Ptpd-announce mailing list > Ptp...@li... > https://lists.sourceforge.net/lists/listinfo/ptpd-announce > > |