Sub millisecond timing revisited

[Andrey_Dmitriev]

---

@rolfk wrote: Actually if the Call Library Node is set reentrant it is always less overhead.

---

Yes, you’re perfectly right — I was just guessing and had never measured it before.

This simple test shows a difference by a factor of 100+:

The only minor point I haven’t debugged in deep so far from multi-threading point of view is how LabVIEW performs thread-safe calls when the capacity is exceeded:

By default (if not tweaked with ESys), LabVIEW reserves 24 threads per execution system. In this case of 24 parallel CLFNs, we will always have the same thread ID for at least two calls (we need 25, because one+ thread is caller itself). However, I haven’t yet investigated the internal mechanism here, how the LabVIEW compiler's clumper identifies parallelism and dealing in this situation resulted two calls from the same thread. But this is not related to UI. thread.

[Andrey_Dmitriev]

---

@TroyK wrote:

Awesome write up! Thank you.

This may be slightly off topic, but I was looking into something similar last year to get more reliable scheduler loop timing on Windows 11 without adding too much CPU load. (Running High Resolution Polling Wait.vi in a loop is pretty CPU intensive.) 

I was hoping to use "CreateWaitableTimerExW" with the CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag set. Not just to get <1ms timing, but to also make use of the periodic ability in SetWaitableTimerEx.

I thought I could offload the scheduler timing to the kernel and get a reliable 5ms schedule.

Unfortunately I could never get it to work. It seems there might be some undocumented quirks.

Do you think these new waitable timer functions could offer a path to reliable sub-millisecond timing in LabVIEW (on newer versions of Windows)?

---

Here is a code snippet for you, it appears to be functional. You need three functions: CreateWaitableTimerExW, SetWaitableTimerEx, and WaitForSingleObject:

However, do not get confused by the "HIGH_RESOLUTION" flag. It allows the timer to reach a resolution of about 0.5 ms, but not below that. We are still fundamentally limited by this ~0.5 ms resolution. As a result, in practice you will observe delays in the corridor of roughly 5 – 5.5 ms, with occasional spikes above that. Also, do not forget to close the timer handle, otherwise you may end up with a handle leakage.

[rolfk]

Actually the number of threads per execution system is heavily dependent on your CPU(s). https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PARmSAO

So 5 execution systems and typically 4 threads per execution system per CPU core. Your 24 would indicate that you have a 6 core CPU. I would bet that if you put all those CLNs into a sequence structure the total execution time is ~2 ms, 1ms for the first 23 CLNs, then 1ms for the remaining CLN.

[Andrey_Dmitriev]

---

@rolfk wrote:

Actually the number of threads per execution system is heavily dependent on your CPU(s). https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PARmSAO

So 5 execution systems and typically 4 threads per execution system per CPU core. Your 24 would indicate that you have a 6 core CPU. I would bet that if you put all those CLNs into a sequence structure the total execution time is ~2 ms, 1ms for the first 23 CLNs, then 1ms for the remaining CLN.

---

No, actually there are 24 threads per execution system AND per priority, so in total 24 × 5 × 4 = 480 threads are available. By the way, in the recent LabVIEW 2026 Q1 (64-bit) version 26.1.2f2, this limit is currently 30 (seems to be), so we have at least 600 threads (not sure since which version exactly).

Was tested on a CPU with 10 cores and 20 threads:

The number of available CPU cores is relevant for the initial amount of threads, but additional threads are created dynamically, as stated in the kb article.

It is quite easy to prove this — see the attached test projects with 24 or 30 threads (LV2020).

[rolfk]

---

@Andrey_Dmitriev wrote:

---

---

No, actually there are 24 threads per execution system AND per priority, so in total 24 × 5 × 4 = 480 threads are available.

---

Since a VI has assigned one execution system and one priority, your diagram only gets those 24 threads to use. How exactly NI determines the number of threads per CPU per execution system and per priority is slightly variable over the time and various versions. It was limited initially when this was introduced in LabVIEW 5, then got increased but with modern multicore CPUs with many cores and hyperthreading it seems to have been slightly reduced again as it generates a lot of threads that most of the times just stay unused in most typical LabVIEW applications.

The dynamic allocation of threads that you mention seems to be limited to ActiveX (and possibly .Net) functionality and most likely as part of the actual ActiveX COM execution system, not for LabVIEW VI execution. For as far as I'm aware, the LabVIEW allocated threads are not dynamically created and destroyed.

[Andrey_Dmitriev]

---

@rolfk wrote:

---

@Andrey_Dmitriev wrote:

---

---

No, actually there are 24 threads per execution system AND per priority, so in total 24 × 5 × 4 = 480 threads are available.

---

Since a VI has assigned one execution system and one priority, your diagram only gets those 24 threads to use.

---

No, each SubVI has its own Execution System and Priority — they are generated from a template and these properties was set programmatically.

By the way, you were absolutely right: the default number of available threads depends on the CPU.

I checked this on a dual‑socket PC with 32 cores (64 logical):

So, I can place up to 96 sleeps calls into each VI:

and still get a one‑second execution time.

As you can see, more than 1900 threads were created.

I also tested this on a PC with fewer cores, and there only 24 threads were available, not 30.

So, the results for the default amount of threads per execution system and priority are:

4/8 or 6/12 cores — 24 threads (480 total)

10/20 cores — 30 threads (600 total)

32/64 cores - 96 threads (1920 total).

Good to know.

[Andrey_Dmitriev]

---

@rolfk wrote:

---

The dynamic allocation of threads that you mention seems to be limited to ActiveX (and possibly .Net) functionality and most likely as part of the actual ActiveX COM execution system, not for LabVIEW VI execution. For as far as I'm aware, the LabVIEW allocated threads are not dynamically created and destroyed.

---

No, no — nothing related to ActiveX or .NET. I mean that when LabVIEW first starts, some threads are already available and "reserved". But when a VI needs more and more threads for some reason, additional ones will be created (and this takes noticeable and measurable penalty time). They are created in advance — meaning that when one more thread is needed, LabVIEW actually creates four (I think) at once (until the limit is reached, of course, such as 96 threads on a CPU with 64 logical cores). It’s probably hard to explain, but I’ve seen this behavior in the past. Maybe someday I’ll create an accurate test to illustrate it. But obviously, LabVIEW does not create all threads for all execution systems at cold launch. And once created, they will never be destroyed, but reused (also my guess).

[JÞB]

Guys, I'm begging you to please help me get replies on topic.  

It's not that I don't appreciate your thoughtful posts!  I do!  And the thorough knowledge exposed have never been doubted by myself. 

I no longer have access to the round table (honestly, I would have preferred that forum to question why R&D is 15 years late, and missing key requirements)  

So, once more, I would like to know the argument for changing the exit criteria of the new Wait.

Of note: I even pointed out that a waitable object was possible in My Nugget authored so many years ago.

[Frozen]

---

@JÞB wrote:

Guys, I'm begging you to please help me get replies on topic.  

---

I see two questions in your OP. I think I can confidently say "no" to the second question. Someone else will have to answer the first once since I do not have the latest version of LV.

[JÞB]

---

@Frozen wrote:

---

@JÞB wrote:

Guys, I'm begging you to please help me get replies on topic.  

---

I see two questions in your OP. I think I can confidently say "no" to the second question. Someone else will have to answer the first once since I do not have the latest version of LV.

2 questions quoted

Is NI serious about trying to make EVERY OS act deterministic?  Or, were the pizza toppings Ni R&D ate psychotropic?

"

---

I have delivered pizza pies myself.  So, can you seriously answer that second question with personal knowledge?

Way back in my days as a Sailor in the US Navy, I visited Bali.  The "port brief" failed to include any warning about ingesting certain local fungii.  I was not the only shipmate that had a bad experience with pizza toppings.