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] -=-=-=-=-=-=-=-=-=-=-=-