Thanks Dave.
Yes I have taken care of that in my code. I always use the highest
value seen as the ceiling in the logic of my code. If I see a lower
value I use the ceiling else move on and record the new ceiling.
Earlier math counted on an increasing value, so bad things were
happening in my code, looks ok now.

Regards
-Prashant

On Mon, Jun 15, 2020 at 7:07 PM Dave Barach (dbarach) <dbar...@cisco.com> wrote:
>
> That's within reason given that thread time offsets are not recalculated 
> immediately, and that (for stability reasons) the clock-rate update algorithm 
> uses exponential smoothing.
>
> Aside from accounting for the issue in your code, there probably isn't much 
> to be done about it...
>
> D
>
> -----Original Message-----
> From: Prashant Upadhyaya <praupadhy...@gmail.com>
> Sent: Monday, June 15, 2020 8:58 AM
> To: Dave Barach (dbarach) <dbar...@cisco.com>
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Regarding vlib_time_now
>
> Hi Dave,
>
> Thanks, on a VM I am observing the reduction from a couple of microseconds to 
> 50 microseconds at times NTP was turned on. After turning it off, I don't see 
> the time reduction.
> The output of the command is below
>
> vppctl show clock verbose
>
> Time now 16712.719968, reftime 16712.719967, error .000001, clocks/sec
> 2596982853.770165
>
> Time last barrier release 16709.938950671
>
> 1: Time now 16710.417730, reftime 16710.417730, error 0.000000, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279669 error -.000000032
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16715.621101, reftime 16715.621101, error 0.000000, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16712.721636492
>
> 1: Time now 16713.318854, reftime 16713.318854, error 0.000000, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279482 error -.000000008
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16718.249427, reftime 16718.249427, error 0.000000, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16715.621212275
>
> 1: Time now 16715.947179, reftime 16715.947179, error 0.000000, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279562 error -.000000008
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16719.646461, reftime 16719.646461, error 0.000000, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16718.249525477
>
> 1: Time now 16717.344206, reftime 16717.344206, error 0.000000, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279598 error -.000000009
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16721.162232, reftime 16721.162232, error 0.000000, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16720.702629716
>
> 1: Time now 16718.859979, reftime 16718.859979, error 0.000000, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279598 error -.000000008
>
> [root@bfs-dl360g9-16-vm4 iptabl]#
> /opt/opwv/integra/SystemActivePath/tools/vpp/bin/vppctl show clock verbose
>
> Time now 16722.313997, reftime 16722.313997, error 0.000000, clocks/sec 
> 2596982853.770165
>
> Time last barrier release 16721.162470894
>
> 1: Time now 16720.011753, reftime 16720.011753, error 0.000000, clocks/sec 
> 2596982875.038256
>
> Thread 1 offset 2.302279597 error -.000000009
>
> Regards
> -Prashant
>
> On Sun, Jun 14, 2020 at 8:12 PM Dave Barach (dbarach) <dbar...@cisco.com> 
> wrote:
> >
> > What is the magnitude of the delta that you observe? What does "show clock 
> > verbose" say about the state of clock-rate convergence? Is a deus ex 
> > machina (e.g. NTP) involved?
> >
> >
> >
> > -----Original Message-----
> > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Prashant
> > Upadhyaya
> > Sent: Sunday, June 14, 2020 10:32 AM
> > To: vpp-dev@lists.fd.io
> > Subject: [vpp-dev] Regarding vlib_time_now
> >
> >
> >
> > Hi,
> >
> >
> >
> > I am using VPP 19.08
> >
> > In my worker threads, I am observing that when I am making successive calls 
> > to vlib_time_now in a polling node, sometimes the value of the time reduces.
> >
> > Is this expected to happen ? (presumably because of the implementation 
> > which tries to align the times in workers ?) I have an implementation which 
> > is extremely sensitive to time at microsecond level and depends on the the 
> > vlib_time_now only increasing monotonically across calls individually in 
> > the workers (or remain the same but never decrease) on a per worker basis 
> > even if the times within the workers are not synchronized.
> >
> >
> >
> > Regards
> >
> > -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16730): https://lists.fd.io/g/vpp-dev/message/16730
Mute This Topic: https://lists.fd.io/mt/74875583/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to