On 2/2/2021 10:31 AM, PATRICK KEROULAS wrote:
> Hello,
> 
> On Fri, Dec 11, 2020 at 4:20 PM PATRICK KEROULAS
> <patrick.kerou...@radio-canada.ca
> <mailto:patrick.kerou...@radio-canada.ca>> wrote:
>>
>> Hello,
>>
>> I use a DPDK-based application to capture network traffic for which high
>> bandwidth and packet timestamp precision are mandatory. The hardware
>> timestamping is provided by a Mellanox ConnectX-5 card. As a receiving
>> endpoint, the system is configured as a normal clock.
>>
>> When the app is running, the whole traffic is redirected to DPDK,
>> depriving ptpl4 from PTP messages. Given a very stable source of
>> packets, I can notice a small drift of the packet timestamps (few
>> 10usec/s). Sure a drift is to be expected but here is what's surprised
>> me. When shutting down ptpl4 before the capture app is started, no drift
>> can be noticed.
>>


So in the "failure" case, ptp4l is running but not receiving any packet
data?

Where as in the "success" case, you've stopped ptp4l and thus are sure
that nothing is tuning the clock at all?

>> My question is: how can a locally-controlled clock give worse results than
>> no control at all?
>>
>> The result is similar for linuxptp v2.0 vs v3.1, slave-only vs
>> master-capable. The config is very close to default, not sure which
>> part would be relevant to inspect.
>>
>> Regards,
>>
>> Patrick
> 


_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Reply via email to