> On Sun, Feb 12, 2017 at 03:07:34PM +, Mintz, Yuval wrote:
> > Your algorithm ignores the HW limitation. Consider (ppb == 1):
> > your logic would output N == 7, *M == 70,
> >Which has perfect accuracy [N / *M is 1 / 10^9].
> > But the solution for
> >'period' * 16 + 8 == 7 * 1
On Sun, Feb 12, 2017 at 03:07:34PM +, Mintz, Yuval wrote:
> Your algorithm ignores the HW limitation. Consider (ppb == 1):
> your logic would output N == 7, *M == 70,
>Which has perfect accuracy [N / *M is 1 / 10^9].
> But the solution for
>'period' * 16 + 8 == 7 * 10^9
> isn't
On Sun, Feb 12, 2017 at 11:52:23AM +, Mintz, Yuval wrote:
> Just to clarify [since it's bit a meaningless otherwise] -
> this +8 is a HW-bug workaround.
Can you please explain exactly what the problem is?
Your code does
period1 = div_s64(val * 10, ppb);
> The original would return val == 1, period == 6249; While this does have
> some error [val / (period * 16 + 8) is slightly bigger than 1 / 10^9, error at
> 18[?] digit after dot], it's the best we can configure for the HW.
Correction. That's actually not *the best* we could configure -
due
> > Your suggestion seems to:
> > a. Assume that the required period should be in ns, not in
> > 16*ns units.
> > b. mishandles the +8/-8 in the calculation.
> > c. Doesn't seem to consider the upper bound on period.
>
> Duh, you would have to convert the result into the proper form fo
On Sun, Feb 12, 2017 at 11:27:16AM +, Mintz, Yuval wrote:
> Richard, there are quite a bit of inaccuracies in the calculation here.
Where?
If you compare this algorithm with yours, you will discover that it
produces significantly lower error for ppm < 60.
> Your suggestion seems to:
> a. A
> The '+8' is not some sort of rounding correction, but rather part of the
> required configuration.
Just to clarify [since it's bit a meaningless otherwise] -
this +8 is a HW-bug workaround.
> On Sat, Feb 11, 2017 at 09:58:10AM +0100, Richard Cochran wrote:
> > If I am not mistaken, then you can skip the cases val==2 and val==3,
> > because they are equivalent to val==4 and 6.
>
> I took a stab at this, and you can see the result, below. My version has
> lower average error than your
On Sat, Feb 11, 2017 at 09:58:10AM +0100, Richard Cochran wrote:
> If I am not mistaken, then you can skip the cases val==2 and val==3,
> because they are equivalent to val==4 and 6.
I took a stab at this, and you can see the result, below. My version
has lower average error than yours in the int
On Tue, Feb 07, 2017 at 10:43:13PM -0800, Sudarsana Kalluru wrote:
> +/* Adjust the HW clock by a rate given in parts-per-billion (ppb) units.
> + * FW/HW accepts the adjustment value in terms of 3 parameters:
> + * Drift period - adjustment happens once in certain number of nano
> seconds.
> +
From: Sudarsana Reddy Kalluru
The patch adds the required qed interfaces for configuring/reading
the PTP clock on the adapter.
Signed-off-by: Sudarsana Reddy Kalluru
Signed-off-by: Yuval Mintz
---
drivers/net/ethernet/qlogic/qed/Makefile | 2 +-
drivers/net/ethernet/qlogic/qed/qed.h
11 matches
Mail list logo
