On Thu, Feb 20, 2014 at 05:58:32PM +0100, [email protected] wrote:
> From: Delio Brignoli <[email protected]>
>
> Previouly the peer delay was not taking into account the
> frequency offset between the local clock and the peer's clock.
> Reset neighborRateRatio to 1.0 in port_nrate_initialize().
>
> Signed-off-by: Delio Brignoli <[email protected]>
> ---
> port.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/port.c b/port.c
> index 523970e..eb64047 100644
> --- a/port.c
> +++ b/port.c
> @@ -855,6 +855,7 @@ static void port_nrate_initialize(struct port *p)
> p->nrate.ingress1 = tmv_zero();
> p->nrate.max_count = (1 << shift);
> p->nrate.count = 0;
> + p->nrate.ratio = 1.0;
Yes, is an obvious fix.
> p->nrate.ratio_valid = 0;
> }
>
> @@ -1782,7 +1783,7 @@ static void port_peer_delay(struct port *p)
> t3 = timestamp_to_tmv(fup->ts.pdu);
> c2 = correction_to_tmv(fup->header.correction);
> calc:
> - pd = tmv_sub(tmv_sub(t4, t1), tmv_sub(t3, t2));
> + pd = tmv_sub(p->nrate.ratio * tmv_dbl(tmv_sub(t4, t1)), tmv_sub(t3,
> t2));
This is okay, but I would like to stick with the tmv types. Something
like this.
double tmp = p->nrate.ratio * tmv_dbl(tmv_sub(t4, t1));
pd = tmv_sub(dbl_tmv(tmp), tmv_sub(t3, t2));
You will have to invent dbl_tmv(), see tmv.h.
Thanks,
Richard
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
