StopWatch vs Current Time Bug

I’ve just made a countdown patch for someone, and it all works fine except I was using stop watch, and it turns out that 1 second in stopwatch, is not 1 second!
Attached is an example of stop watch vs current time, they’re quite different!

Stopwatch bug (7.4 kB)

Ok LFO behaves the same, there is a serious timing error in vvvv!
I’ve checked this against a stopwatch in the real world too, LFO and Stopwatch are using the same time base it seems.

works good here… make sure that the processor clock is not changing while the patch is open.

the stopwatch is unsing the high resolution cpu counter while the current time is using the mainboard clock, they can have a drift, as they are two different clock sources. but this should only be a few milliseconds per hour…

Well, funny, I noticed this before, and figured there was a difference in time source for current time and all the vvvv time nodes. So do not use Currentime for timing I would suggest.

When I tested it before I had arround 0.5 seconds difference, and now it is like 0.0010 seconds off.

I add some S+H so you can see the difference.

StopWatchBug2.v4p (14.5 kB)

when it started ~2000s ago,
the output read ~+0.0030

Well my client, told me it was 15m per hour off, so I’d say thats a little more than a few milliseconds!
That is supported by my tests…

by make sure that the processor clock is not changing while the patch is open.
Are you talking about the i7 etc clocking up and down through load?
How do you stop it doing that?

Maybe try Increase Timing Precision on Mainloop?

1 second in 10 with timing precision on… :/

You could write your own stopwatch-plugin using:
And then use Frequency and IsHighResolution for “debugging”.

Using current time works for this project, I’m more concerned about the internal precision of vvvv in general, given a 10% error in timing for things like lfo’s monoflops etc!

if your cpu has no hickups, the timing is super precise, the best you can get on a pc… so it depends on the mainboard, not vvvv.

I also had issues with the timing, but only in recent versions of vvvv. For example, LFOs “Change” pin sometimes banging twice, and if I plotted the current value as graph, there were points were it jumped from “near one” to 0.9 and continued counting up (and definitely was no steady line).

@tonfilm, you still haven’t told me, how do you have your cpu have no hickups?

If I think of something like the player(texture) help patch, where you have an LFO driving the frame rate, this has serious implications for playback speed, in my case above 10% is a vast margin of error!

The other thing here, is that the LFO and stopwatch, are running QUICKER than the current time, does that not mean that the CPU is speeding up?
If main loop throttles (as for NRT writer) and so slows down the LFO, how does the LFO get faster? My patch is a steady 60fps as set in mainloop, I have increased timing precision on, I’m not doing any other heavy lifting.

I cant understand how you can tell me its super precise, when I can demonstrate such an error, if there is a way to stop this via a system setting, then please tell me, I have a number of projects that rely on synchronization, so I’d really like to know how to improve there chances of running correctly!

From the link posted above (just FYI):

And another thing that came to mind – might be totally unconnected but maybe worth a try: I once had some issues with the timing of timeliner when Mainloop was set to filtered.

@catweasel set the windows energy plan to performance or presentation. and change the timing precision in the MainLoop node.

aoe make your you use only clock the processor clock (StopWatch, Timimg) or only the low res mainboard clock (Gregorian).