Hi,
The issue isn't the actual network, but the fact of how transmit
timestamps are are returned. The stack requests a particular packet to
be timestamped, then the driver and device have to send it. Once sent,
driver and device determine the transmission time, usually via some set
of registers, and then have to report this information to the userspace
again. Most devices only support timestamping a few packets at a time,
some even only one. Thus, when you transmit too many syncs too fast, you
can lose transmit timestamps. Even if you don't lose them, they may not
be returned to ptp4l process in time.
LinuxPTP is very careful, and causes a full reset when it loses a
timestamp. Theoretically you could have it keep trying until you got
more failures, but it becomes difficult to say for sure why you lost a
timestamp and whether resetting is better than not.
Regards,
Jake
On Tue, 2015-03-17 at 16:15 +0000, Chandra Mallela wrote:
>
>
>
>
> Hi Friends,
>
>
>
> Do we have any performance numbers for the ptp4l stack performance on
> a 10Gbps link? When I increase the sync packet frequency to 512 and
> the DelayReq packet frequency to 512, I see many synchronization
> faults, meaning that the ptp4l runs for some time, faces
> synchronization faults, resumes the sync operation, faces the sync
> faults and resumes the operation showing a lot of instability in the
> overall ptp stack operation.
>
>
>
> Is it due to the limitation from the stack performance as the HW
> supports a 10G link? The 512 packets per sync and 512 packet sets of
> {DelayReq, DelayResp} donot occupy even 1% of the 10Gbps bandwidth.
>
>
>
> Could you elaborate your experience with the ptp4l performance?
>
>
>
> Thanking you in anticipation,
>
> Regards,
>
> Chandra
>
>
>
> © : 0175508142
>
> (O): 701.6412
>
>
>
> “Knowledge speaks, Wisdom listens”
>
>
>
>
>
>
> ______________________________________________________________________
>
> Confidentiality Notice.
> This message may contain information that is confidential or otherwise
> protected from disclosure. If you are not the intended recipient, you
> are hereby notified that any use, disclosure, dissemination,
> distribution, or copying of this message, or any attachments, is
> strictly prohibited. If you have received this message in error,
> please advise the sender by reply e-mail, and delete the message and
> any attachments. Thank you.
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________ Linuxptp-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Linuxptp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
