12-15-2020 09:32 PM
Why ?
For Windows 7 OS 64bit, Time=100ms (deviation is small).
For Window 10 OS 64bit, Time varies, ranging from 160 ms to 220ms.
Solved! Go to Solution.
12-16-2020 01:34 AM
Hi AdMan,
@Reed001 wrote:
Why ?
Because of the different OS!?
What's the point in waiting for the next 1ms multiple a hundred times? This will result in a lot of jitter!
Why don't you wait for multiples of 100ms?
12-16-2020 02:16 AM
Windows is not a realtime OS and your experiment hints that the OS is to blame, not LabVIEW.
(See also)
Of course your message is a bit sparse because we don't know what else has changed. (computer hardware, CPU, LabVIEW version, etc. etc.). Unless all you did was change windows version while keeping everything else constant, all bets are off anyway.
(Also, can you explain why you need that sequence structure? In fact, the wait function outputs the ms value, so the following code would be equivalent:)
Personally, I would use "high resolution relative seconds" for the ticker. Still does not change the fact that windows cannot guarantee milliseconds.)
12-17-2020 12:44 AM
Same PC hardware ,same LabVIEW version and different Windows OS.
The original design aims to simulate CAN node to transmit CAN messages cyclically with different periods. Setting waiting-time equal to 1ms is used as time quantum.When the elapse time is integer times of period of certain message, the message needs to be transmit. The period ,purely up to the user's definition, is changeable.
12-17-2020 01:14 AM
Thanks for your response. The 1ms is used as time quantum. The details is on the fourth floor.
12-17-2020 01:41 AM
Hi Reed,
@Reed001 wrote:
Same PC hardware ,same LabVIEW version and different Windows OS.
The original design aims to simulate CAN node to transmit CAN messages cyclically with different periods. Setting waiting-time equal to 1ms is used as time quantum.When the elapse time is integer times of period of certain message, the message needs to be transmit. The period ,purely up to the user's definition, is changeable.
Simple solution: Switch back to Win7 when it was working more stable for your requirement!
You cannot rely on OS timing for plain Windows in the millisecond range. Point. Even on Win7 you might get such problems like you face now…
Suggestions:
12-17-2020 03:29 AM
1ms wait is asking for trouble if you rely on it being accurate.
Try 5 or 10 and it'll work well on both systems.
12-17-2020 05:19 AM - edited 12-17-2020 05:27 AM
@Yamaeda wrote:
1ms wait is asking for trouble if you rely on it being accurate.
Try 5 or 10 and it'll work well on both systems.
Actually no! This is Windows and I would not say it "will work well" but instead "it will usually work well".
There is no guarantee under any standard desktop operating system that it won't simply decide to take a guru meditation nap for multiple 10th or 100ds of milliseconds, and even seconds. Under Linux you can better control what else is going on if you really care and understand how the system is configured, but the modern desktop OSes like Windows and Mac OS simply have to much going on in the background for user convenience that such guarantees could be even remotely made.
Under a realtime system there is some guarantee especially if you use the timed loop, but that usually won't be below 1 ms. A few ms is doable but 1ms or lower is stretching the capabilities of a system if you are not really careful about what else is running on that system.
The difference between Windows 7 and Windows 10 as reported here is simply an indication. Windows 10 is more complex and has many more services running in the background by default that can snoop time away from the user processes, but it is not necessarily a representative figure. It depends a lot on what other services, drivers and what else are installed on the given hardware. Some drivers can be buggy and a simple bug in the network or video card driver can cause huge differences on granularity and interval consistency of user process timing. Such drivers run in the privileged kernel and can in fact lock out hardware including the CPU almost completely from other use. A driver is supposed to only do that for the briefest possible amount of time, but bugs do happen.
12-17-2020 08:13 PM
Thanks for you good suggestions.It's time to consider some new solutions.
12-17-2020 08:15 PM
Thanks for your response. It's time to consider some new solutions.