Cat

Are you running them on a Windows 7 64 bit machine?? 29 hours is probably long enough.

I hope this doesn't just get appended to my last post. That happens a lot on this site. I must have something set wrong somewhere. Anyway... Test results: Windows --- LV --- Result (passed = ran for over 4 hours without failing) XP --- 8.6.1f1 --- PASS XP --- 10SP1 --- PASS 7 ------10SP1 --- FAIL 7 ------ 11 -------- FAIL 7------ 8.6.1f1 --- FAIL Anyone else see a trend here? FWIW, all Windows 7 boxes have been 64-bit. I'm going to run the write and read on 2 separate Windows 7 computers for a Long Time again, since I probably never ran much longer than a couple hours before stopping with no error. For completeness sake, I should do a 4 hour test. Because if *that* fails, there's a really big problem somewhere. Thanks again for all the help/suggestions and especially thanks to those of you who were running tests for me! I have v1.0 of Desktop Execution Trace Toolkit. This should actually be a small enough program for it not to choke. I can try it even tho it doesn't say it works on Win7. Network analyzers aren't a lot of help since the data never actually leaves the machine. No questions are dumb!

No I hadn't, but I just did. :-) Failed in both Windows Server 2008 and Vista. Not that I'm really surprised. From what I've been reading, MS changed their network implementation for Vista/2008/7. So if it doesn't work in one that might make it more likely it wouldn't work in the others.

Hopefully I've caught you in time... I ran Win7-64/LV8.6.1 yesterday and it died in around a half hour. Verification from someone else would be great, but if it's too much work, don't worry about it. I'll take a look at the toolkit when I get to work. Thanks!

Oh, right, sorry, I really should have mentioned this. The reason why I have a 3 second timeout is because after data stops flowing, about 5 seconds later it starts flowing again. A 4-6 second flow stop is pretty consistent. So yes, with no timeout, this can run forever. Of course this 5 second pause is happening every few minutes. I haven't done any tests to see if data is actually lost during that time. This 5 second pause does not happen between the C-write/C-read or LV-write/C-read. It only happens with the LV-read. Unfortunately, the "real" C code errors out long before 5 seconds because as far as it's concerned my LV reader side stops responding to data sends. This causes it to reset the connections and that is a Bad Thing when it happens while data is actually being recorded. I don't have much control of the real C-write because it also has to work interfaced with other systems. A 5 second pause there means everything is dead, not just that the TCP read is taking a little unscheduled break. The existing C-write I have to tie into is set up to do the listening. Thanks for trying this out! Are you running on a Windows 7 machine?? Latest tests: Win7 / LV2011: died after about 90 minutes WinXP / LV8.6.1: I finally stopped it after 4 hours with no problems. Hmm. I'm trying to figure out if I really want to go thru the pain and agony of uninstalling LV2010 from one of my (2) Win7 machines and reinstalling LV8.6.1. And then after testing, uninstalling LV8.6.1 and reinstalling LV2010. There goes 2 or 3 days of computer time. Especially since every time my boss walks by my workbench where all my computers are lined up, he says, "I thought you were done playing around with that!" However, I think I finally convinced him it's important to figure out if this is something that's crept into LV since 8.6.1 or if it's a Win7/any LV problem. Granted, with our usual projects we would never have reason to do loopback TCP, but it may be indicative of some larger problem with Win7/LV/TCP and that wouldn't be good.

At this point, there are no such things as silly questions. But yes, I've turned off any and all power savings settings I could find, including the network card. At least on my computers here at work.

Wow. So maybe it's a Win7/LV10 problem... I'm installing LV11 on my Win7 homebox as I type. I'll try it on that. BTW, I ran both sides on my XP/LV8.6 machine this afternoon for over an hour with no problem. I'll try a longer test tomorrow. I really appreciate you running these LV/OS combo tests.

That's ok! I appreciate any help! Have you had a chance to run my code for any length of time? That's usually my mantra, but if it actually makes this work... I've got my XP/8.6 machine back and will be trying it soon.

I knew LV2011 would be the answer to all my problems!! I do not have an XP machine with anything other than LV8.6 on it, and it's out on loan at the moment. I should go see if I can borrow it back... Thanks for the feedback! I ran your two vis together on 2 different machines and they died after 7 minutes on 1 machine and after 42 minutes on the other...

Every once in a long while I'm presented with a problem I just can't figure out. It's been quite some time; I guess I'm overdue. I've run so many different tests I'm seeing them in my sleep, but here's the summary of tearing my hair out for the past two weeks: The basic problem is to write 5MBytes of data from one program to another, on the same computer, every second, via TCP. In its original configuration, this data is literally 5MB all in one TCP write every second, not paced out. It uses payload size to determine the end of the data. If the two programs are written in C, it works. I was incorrect in my orignal statement that if both programs are in LabVIEW it also works. It doesn't, or rather I haven't been able to figure out how to make it work. It does work if both LV programs are on different computers, but not if they are on the same computer. And if the LV is doing the write, the C read works fine. So the issue seems to be the LV read, on the same computer with any type write. The two programs connect and are sending/receiving the data for several minutes (2-50). Then both sides stop with various errors. With both sides in LV, most often, the read errors out with a timeout (56), and the write errors out saying the system caused a network disconnect (62). Here are some things I've tried that made little or no difference: running the LV programs together on a different computer Intermediate mode read (thanks for the suggestion, Rolf) breaking the 5MB write up into 10 500KB writes and 100 50kB writes breaking the 5MB write up into 10 500KB writes and pacing them out over 750ms reading the 5MB all at once breaking the read up into 500kB and 50kB passes Shaun, your suggestion to play with the TCP buffer sizes helped in that instead of failing in a few minutes, it would go for several minutes. Oh, and controlling buffer size on a Windows 7 machine is a PITA. Check out this article if you're doing it on a Win7 platform. I tried every buffer size possible, but it never really helped much more. I even posted to serverfault.com with the problem, and also many other questions about Win7 TCP buffers that no one seems to understand, and have gotten a deafening silence in response. At this point, I'm going with Plan B. I've configured a ramdisk on the computer and we're just going to write/read files. In retrospect, this may actually be a better solution, but dang it, I want to know why the TCP way isn't working. I'm attaching a couple of very simple vis to demonstrate the problem. Just run them on the same machine, with that machine's IP address (it's an input instead of default for testing on 2 different machines). Written with LV 2010 SP1 64-bit on Windows 7. About all I haven't been able to try is a different combo of LV version/OS. The longest these test vis have ever run has been 50 minutes, and that was much longer than the norm. If anyone has a chance to run these vis, please let me know how it goes. Thanks, Cat Write TCP Data - Simple.vi Read TCP Data - Simple.vi

That's what the vi you sent defaults to. I can just go with that. Ohh... so the fact that I'm the client (open) not the server (listen) means this isn't going to help? Everyone involved agrees it's strange. And no, there's nothing fancy going on with the sockets on the C side. Not that we know of. This *is* a port of Unix C code, done by someone with lots of Unix C experience but zero Windows experience. In order to remove any other possible code issues, I've written a couple vis that are basic read/write to the same port. The C programmer has done the same. My two programs run fine together. Her two programs run fine together. Run her write and my read and it runs for awhile but errors out eventually. Tho this is making me wonder what might happen if we run my write and her read together... One port. The C side most of the time throws a 10060 error. The LV side thows 56 for awhile and then 66. Basically, "what we've got here is a failure to communicate". Oops. Sorry.

Woo-hoo to all!

I'll talk to my network guru about that and see what hardware we've got available. But I'm thinking its very possible this data never really makes it out of the computer onto the network.

Each of the data streams is ~ 8 M/B, so worst case thruput is 24MB/s (counting P2 --> P3 twice). I've been staring at Resource Monitor a lot. The network (1Gb) is loping, the CPUs are loping. Thanks for the vi. Any chance you've got a "Get Buffer" vi? I'd like to know what the buffers are set at before I start playing around with them. I tried to reverse-engineer the wsock32.dll call in "Set Buffer" but can't really test it here on my home box.

One NIC. It's a very simple setup -- 3 computers on a standalone switch. They have hardcoded IP addresses. Yes, I am running Windows 7 (and using LV10). There was another NIC on the laptop, but I took it out in case it was the problem. Didn't help any.

Just downloaded and started playing with Wireshark. Looks like a great program. Except, I couldn't get it to work. Finally discovered that "loopback interfaces are not available on windows platform". The Wireshark wiki does have links to a couple commercial products that monitor loopback connections. But it will take me awhile to get my hands on those, and I'm not even sure they'll tell me anything.

All connections are made using actual IP addresses. But either way, the parts are always connecting, and data always flows for some amount of time. Just not for as long as I would like it to. I would love it to be the P2 code since I didn't write that. However, since P2© and P3(LV) work fine if they are on different computers, and P2© and P3© work fine on the same computer, it's hard to point a finger at P2 being the problem.

I'm working on a project that has 3 parts: P1) data simulator P2) data parser P3) data analyzer Original version of the project: P1 and P2 are written in C and live on a remote machine. P3 is written in LabVIEW and runs on a laptop. All the parts communicate via TCP. This works great. Current version of project: P1 is in C on remote machine. P2 is in C on laptop. P3 is in LabVIEW on same laptop. All parts still communicating via TCP. This is not working so great. Everything connects fine and will run for anywhere from 2 to 10 minutes. Then P3 starts complaining about timeout errors and/or network peer disconnecting. P2 starts complaining that it can't send it's data to P2. Everybody eventually times out and resets connections. Sometimes starting up another program (wordpad, program manager, etc) will cause this, but most often it happens even if there is no user interaction with the laptop. The part of the LV code dealing with this consists of 1 reintrant vi called 4 times to handle 4 different data messages. Each message has its own port. In order to debug I've ripped everything out of P3 except doing the TCP reads. I've knocked it back to reading just one message. I set the subvi with the TCP read to time critical priority (yes, I'm getting desperate). None of this helps. Just to add insult to injury, if P3 is written in C and run on the laptop with P2, it all works fine... Help?!?

I agree and that's often where I use it. There are many other benefits to using a plug-in architecture in general, but I don't want to get too far off topic. I've also had this thought running around in the back of my head that if I call memory-intensive routines dynamically, I should actually get that memory back when they're done executing, as opposed to calling them statically and having LV hang onto memory long after it doesn't need to anymore. But I haven't had a chance to play with that, and it's definitely a discussion for another thread, anyway...

Some text got lost in there somwhere. I was still talking about dynamically called code. I agree, if I can pass a wire in, that's what I'm going to do. Tease.

Yeah, what you said. I've done all that, too, and keep coming back to named queues and FGVs when passing data between dynamically called code. And it was actually your earlier comment I wanted Daklu to follow up on...

I know. I was asking Daklu about a specific use case where unnamed queues wouldn't work. I use named queues in dynamically called code quite often.

But what about the case of dynamically called code? An unnamed queue isn't going to work there. Which makes me wonder... if you don't use named queues because you can't trace a wire to/from them, then maybe you don't use dynamically called code either? Yes, I'm kidding, but the points in your argument above can be applied to either.

I'm confused (not unusual). The above article states, "It is known behavior that this setting coerces the priority to normal priority. It is not possible to set a VI priority to anything lower than normal priority from within the VI Properties Window." So why does the option even exist?? I occassionally used background priority a long time ago when CPUs weren't quite so fast. Was it all just smoke and mirrors or is this a recent "feature"?

I think LAVA's just been pwnd.