On Wed, Jul 23, 2014 at 02:36:24AM +0000, Dylan Davis wrote:

> Interestingly, the reported delay under
> load is 12us less than when unloaded.

Hm..
 
> These results are unintuitive, and I can't come up with a solid explanation 
> for
> them. Assuming the reported offsets are accurate (which may be a poor
> assumption), my best guess is that somehow the 'stress' workload is forcing
> ptp4l to be scheduled more consistently, but that's only speculation. Can
> anybody shed some light on what's happening here?

The effects that you see are indeed unintuitive, and I have also seen
improved timing behavior under high load. There are at least three
different ways that a load might have this effect.

1. Cache Effects. The high load might cause more cache misses in the
   time stamping path in the driver, resulting in a longer duration
   between the packet arrival time and the SW time stamp, but with
   more consistent timing.

2. Driver and networking stack. Depending on how your MAC hardware
   works and how the driver is written, there can be long and variable
   delays between the time stamp point and the actual transmission or
   reception time. The load can cause more consistent run time
   behavior, but the details of how this happens can be hard to
   understand.

3. NTP. Due to bugs in the kernel's NTP servo, high load can improve
   the clock regulation. I have seen this with nohz=on, but there
   might be other problems in that code as well. This is an area in
   the kernel that is still wanting improvement.

The 12 us smaller delay is a sign that the load is making the driver
or the stack time stamps more consistent.

Thanks,
Richard

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Linuxptp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Reply via email to