Re: [Linuxptp-users] Expected throughput of the ptp4l

[Ledda W. E. <Wil...@it...>]

I'm working for a project with very stringent requirements (50 ns RMS accuracy) and we are able to reach this requirements using the "default" Sync delay of 1 second and a Delay request of 8 seconds. I'm attaching a simple picture that is probably one of the most best result I've observed after hundreds of tests. Results collected with an Intel i350 network chipset on Red Hat 6.5 with MRG-R kernel. Without real time kernel the results observed are quite near, just a little more jitter. 

The point is: Which is your requirement? Is it about the synch rate? (why?) Is it about the ns accuracy? If it is about the accuracy why to insist on 512 sync packets per seconds if you can reach the same results at 1Hz? 

As Richard says...

> If you really want to run 512 packets per second, then you are going to have to do some careful hardware selection and some serious system tuning.
> It won't be easy.
> Good luck,

HTH
William

-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...] 
Sent: 18 March 2015 09:29
To: Chandra Mallela
Cc: lin...@li...
Subject: Re: [Linuxptp-users] Expected throughput of the ptp4l

On Wed, Mar 18, 2015 at 02:58:46AM +0000, Chandra Mallela wrote:
> From my interactions with the customer as an architect, I could see the need for 512 syncs per second, due to high-end frequency correction (think of a 1588 application to replace/compete with SyncE applicationIn a pure telecom application, high frequency Sync packets might encroach into datatraffic. However, in back-hauling (be it telecom or networking), where high-throughput is already a given parameter, high frequency Sync packets are desirable for frequency corrections. ). On offset correction, I can take liberties on DelayReq sets.

If you have SyncE in place already, then you don't need the 512 rate.
In fact, all you need is *one* offset measurement in order to correct the offset, once the clocks are locked.

If you are trying to replace a SyncE system with a non-SyncE PTP system, then you can forget trying to match the SyncE synchronization performance.  It just is not feasible, to my knowledge.
 
> Do we have the performance metrics of the ptp4l in a standard Linux OS? At what rates of the packets, does the stack break down? If we have any data, it will be good for us to know. If you have any ideas as to how to arrive at the numbers, please let me know - I can try it out with the system at my hand.

The answer is, "it depends."

I have seen good results with 1, 2, 4, and 8, packets per second on a low end embedded system.  With 128, some time stamps are dropped due to hardware/driver constraints.

Any performance metric is tied to the particular hardware used, and so even if I had such metrics, they would not help you too much.

I already told you this more than once: If you really want to run 512 packets per second, then you are going to have to do some careful hardware selection and some serious system tuning.

It won't be easy.

Good luck,
Richard


------------------------------------------------------------------------------
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
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users