kronoseleven

>Are you able to copy large files between the systems with reasonable speed? @LogMAN interestingly enough... dumping a 1G+ file in a shared folder I'm only getting 11MB/s and the read (for crc of file copied) was 10MB/s I only see the delay at the initial connection, but now in mentioning that I feel the need to go make sure all the data coming in isnt 16 seconds behind....

@LogMAN I also killed all firewalls on both nodes... and there's no switch or router involved in this case...

@Neil Pate That's a real good point, whereas the reg tweaks are made accross the board I presume, but I'm not 100% sure where to put the nodelay vi. I will try it here: edit: I put the no delay vi in write and read of the TCP Messenger library and did not see any effect in this test. @drjdpowell would you reccommend a better call spot? a few notes: -latency measurements were made with phy stopwatch rounded to tenth -10.3.3.3 has 3 active NICs, 10.3.3.1 has 4 active -TCPNoDelay.vi was place in both write and read of TCP Messenger.lvlib vi's *had to increase the timeout value mentioned earlier in this thread...

@Neil Pate Thanks for the suggestion! and the link to the KB @LogMAN I grabbed that library and looking into the no delay vi I see setsockopt is the call into wsock32.dll... here's some more info I found, not sure which way I'll try to implement yet but feel like I might want to tread carefully or at least be sure I know how to unset this once I change it. https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-setsockopt I also found this site showing the toggling of it via registry which might be my first attempt: https://www.fixwindowserrors.biz/blog/disable-nagle-algorithm-in-windows-10 Looking in the registry I realize this is actually a setting on a per-nic basis, so I guess I will apply the change to all nics for this test since I think it may be related to windows looking for the client... I'm going to set up the same test and run it in both states to see if there's any difference.

So I ran the Simple TCP example from NI between my workstation and a few computers. I think having your connection on a different NIC (than your default route) might be causing the trouble I'm seeing with this example. With Simple TCP Example, I'm getting between 5-90ms max execution time on TCP read here with max lookup: Long story short (I ran into a ton of unrelated issues with the 3 computers I tried here)- I think the longer delay could be due to having multiple NICs on my workstation, and that I was trying to talk to a client on the non default route (meaning my internet comes from 192.168.1.0/24 and I was trying to talk to a client on 10.1.1.0/24). With the client on the same default route (not on my workstation), I'm now seeing between 2-2.5 second delay before the client seems to start rx'ing data with the messenger example. I'd like to try to get a better measurement than my stopwatch but my first attempt to push this re-entrant vi fwd and show values didnt go well... And I accidentally saved some of the dependencies under LV2020 so I have to go roll those back before I can try to reverse what side the client runs on. edit: with roles swapped the client picks up on it faster than I can adjust to stop the timer, I'd say well less than quarter of a second... edit2: RemoteTCPMessenger.lvclass has an exec time between 50-100ms

Good idea, I'll do this and post up! edit: I'm having some issues with the example, makes me think it may be due to the particular network setup I have? I'm gonna try with another box to see if it makes a difference. edit2: pretty sure there's an issue with having multiple NIC's on different subnets... my second computer I tried this on was an old win7 box and I cant get VIPM2020 to run so I'm loading onto a laptop for now for another test

Thanks for the replies, and admittedly I was not using your actor manager tool- Firing that manager up I found the tcp primitive you pointed out immediately. Seems I wasn't fast enough to reply, poking down a bit further it seems like the TCP read here: takes a considerable amount of time the first go around... after which it executes as fast as expected. If the server is running and passing data why would this vi be waiting? Assumign the sever is putting more than 4 bytes on at a time... thanks again!

Looks like it to me, where is the Get LV Version vi for me to be sure? I searched and didn't get any results... thanks!

@drjdpowell, thanks for the impressive framework and hard work! I'm attempting to wrap my head around the TCP implementation example (the zip files from your post above on March 14th 2016) of the messenger framework and am having some difficulty... The example works out of the box when both ends are run locally, however trying to run the server on a laptop and client on my workstation, I ran into an error: followed by After doing some debugging (trying to follow the call chain through lots of abstraction) I discovered that one of my breakpoints had caused it to work! I tried changing the timeout constant in Create.vi (of RemoteTCPMessenger.lvclass) that is passed to the "SendMSG.lvlib: Query.vi" from 3sec to 15s and the client will now connect to the server everytime without error, sometimes taking as long as 16+ seconds to start showing data from the server on the client front panel. I can reduce the timeout down to 11sec and still end up with ~16s worth of a wait for data to show up. My first question feels like a dumb one, as I can't even find the code that might answer my question, my search stops at RemoteTCPMessenger.lvclass:Send.vi where the class implementation choice leads me right back to the same diagram. What causes this wait? I also wanted to ask if you had any diagrams or documentation for this great framework, it's obviously very capable and I want to use it for that reason but feel like I need to know more about what's going on under the hood should I run into trouble in a new implementation. Thanks!