09-19-2017 06:46 AM
Bob,
Just to throw some more "gotchas" at you...You are also dealing with a single NIC. It takes time to establish a connection. And only 1 can talk at a time. So to get to the NIC from the OS could be throwing some jitter in your numbers. And just network traffic in general will add a lot of jitter.
Anyways, I have seen no indication that the VISA functions are not reentrant. But you will still likely have resource utilization issues.
09-19-2017 08:00 AM
I guess the biggest question for me is why multiple TCP Opens run simultaneously, but multiple VISA Opens to TCPIP SOCKET resources don't run simultaneously.
09-19-2017 08:10 AM
First a "should" question and now a "Why" question!
like I said earlier "should" questions can only be answered by the spec for that function. NI closely guards the "spec" on a general basis so that they have the option to tweak things in the future. The less they commit to, the fewer issues when they do decide to change things.
The "why" question may be discovered using the DeskTop Execution Toolkit. Comparing the dumps of both version would tell you what is different.
Offering what little I can...
Ben
09-19-2017 08:14 AM
@Bob_Schor wrote:
So here are some additional Timings (in milliseconds, eye-ball averaged) (you can try this yourself if you have the appropriate setup):
N = 24 N = 1
VISA O/C 400 17 (occasionally 500)
No VISA 60 7
So several things stand out.
- It takes more time to start and wait-for-stopping of 24 Clones than for 1 Clone.
- 24 Clones is from 3 to 8 (very rough math) slower than 1, but not 24 times slower!
Where did you get the numbers 3 to 8 from? Because 400/17=23.5, so it seems like 24 clones takes just about 24 times longer to run than one clone.
09-19-2017 08:24 AM
@Ben wrote:
First a "should" question and now a "Why" question!
like I said earlier "should" questions can only be answered by the spec for that function. NI closely guards the "spec" on a general basis so that they have the option to tweak things in the future. The less they commit to, the fewer issues when they do decide to change things.
The "why" question may be discovered using the DeskTop Execution Toolkit. Comparing the dumps of both version would tell you what is different.
Offering what little I can...
Ben
Sheesh, apparently I'm asking for way too much predictability from my function calls. I don't mean that I need to know the inner workings in detail, just whether what I'm seeing is what everyone else sees (which is what I mean by "expected"), or whether I'm doing something wrong that's causing this behavior. What I'm ultimately trying to figure out is whether I can make the VISA functions work in my application instead of the TCP functions, because so far I haven't been able to due to them seemingly not running in parallel, and I want to know whether I'm doing something wrong or not.
09-19-2017 08:44 AM
@arteitle wrote:
@Ben wrote:
First a "should" question and now a "Why" question!
like I said earlier "should" questions can only be answered by the spec for that function. NI closely guards the "spec" on a general basis so that they have the option to tweak things in the future. The less they commit to, the fewer issues when they do decide to change things.
The "why" question may be discovered using the DeskTop Execution Toolkit. Comparing the dumps of both version would tell you what is different.
Offering what little I can...
Ben
Sheesh, apparently I'm asking for way too much predictability from my function calls. I don't mean that I need to know the inner workings in detail, just whether what I'm seeing is what everyone else sees (which is what I mean by "expected"), or whether I'm doing something wrong that's causing this behavior. What I'm ultimately trying to figure out is whether I can make the VISA functions work in my application instead of the TCP functions, because so far I haven't been able to due to them seemingly not running in parallel, and I want to know whether I'm doing something wrong or not.
Valid desire!
I think you can dig deeper using the DETT to find a difference.
Alternatively if you have an active support contract, you can call NI and log a Service Request to get an AE to investigate what you have found. It may be a bug. It may be by design.
This forum no longer has official support from NI and the AEs. It is hit and miss if someone from NI will chime in.
I'll do what little I can to see if I can yank a chain for you.
Ben
09-19-2017 10:23 AM
@arteitle wrote:
@Bob_Schor wrote:
So here are some additional Timings (in milliseconds, eye-ball averaged) (you can try this yourself if you have the appropriate setup):
N = 24 N = 1
VISA O/C 400 17 (occasionally 500)
No VISA 60 7
So several things stand out.
- It takes more time to start and wait-for-stopping of 24 Clones than for 1 Clone.
- 24 Clones is from 3 to 8 (very rough math) slower than 1, but not 24 times slower!
Where did you get the numbers 3 to 8 from? Because 400/17=23.5, so it seems like 24 clones takes just about 24 times longer to run than one clone.
Double Oops. When I first did the test, I made a "decimal point error" and wrote down 40 msec for 24 clones, and said 40/17 was about 3. I fixed the 40 -> 400, but didn't revisit the division ... Bad! I think the balances are in use right now, so I can't "try again" ... However, it is curious that when running a single VISA clone, I occasionally see delays as long as when I run 24 clones ... Funny things are definitely happening, and I don't know where ...
Bob Schor