APP RUNS DIFFERENT SPEEDS ON DIFFERENT PC

[jspaarg]

I have a LabView .exe that runs at completely different speeds on two different PCs.

The app was built with LabView 7.1.

Both PCs have the same LabView Run-Time engine and drivers installed.

The app makes extensive use of COM1 and network access to mysql.

Both PCs are running XP with the most recent microsoft updates.

The app uses a 100ms increment in a main loop.

When running the normal speed PC, an indicator shows the loop at 100 ms with an occasional 300ms or 500ms increment (I'm not worried about that).

The slow PC shows loops of up to 11 seconds, with the typical loop running at 6-7 seconds.

Using Administrative tools, I can see that both PCs are running the same services.

The task manager on the slow PC shows a system process that takes up to 35% of the CPU when the app is running, and the app is only getting 2-5%

On the normal PC, the system process goes to about 20% when the .exe is launched and then goes to 0%, the app gets from 15-25% of the CPU.

There are no other apps running on either PC during this test.

The slow PC had the hard-drive reformatted and everything re-installed yesterday.

Does anyone have any ideas why this can occur?

I have little hair left, and what is left is too precious to keep pulling out.

Thanks.

[minnellac]

I'd check to see what part of your app is slowing down. I'd be willing to bet it's the network access. I've run into some annoying situations where there is a network share that is not accessible (or some other funkiness), and just opening an open/save dialog which defaults to an inaccessible location forces you to wait for Windows to timeout before letting you select something that is accessible. If you are doing something like that in your code (maybe multiple times) it may be responsible for the slow execution. I'd just take a look through all the network comms stuff to see if something there strikes you. Also, if you just debug your code carefully, you should be able to find out where it's spending all of it's time.

Chris

[jspaarg]

I am logged onto the network as the same user on both PCs (not at the same time; i.e. I only run one of the PCs at a time).

So I would think that the network access is just fine.

Also, other LabView apps that run on this PC and access the same mysql database have no problems.

Again, I am not running them at the same time.

It just seems to be this one app.

I don't think that it matters where the app is "stuck".  The process window of the task manager shows that it is only getting 2-5% of the CPU.

That would make it run more slowly regardless of my code.

[minnellac]

I think it's worthwhile to find out where it is slow. If your app is sitting around waiting for something timeout, it doesn't need much processor.. Is the rest of the processor pegged by something else, or is it idle? If something else is consuming 100% (or 99, 98, whatever), you can try reducing the priority of the other process, or increasing the priority of you LV app. If it was processor limited, the processor would be pegged, so I don't think that's it. Being logged in as the same user doesn't mean that the same drives are mapped, or that the same directory structure exists on disk.

I'd comment out all the SQL stuff, to see if the app springs back to life. It could be something else entirely, but my hunch is network. I don't mean speed of the network, just Windows interaction with the network. Is every drive that is mapped available?

Chris

[Ben]

Let me guess that it is either spy-ware or anti virus taking up the CPU or the slow machine does not have enough physical memory.

Ben

[jspaarg]

Ben,

Thanks for that thought, but the slow PC had the hard drive reformatted and everything re-installed yesterday.

It had anti-virus software installed on it prior to being added back to our network.

Also, other LabView apps that use the network have no problem on this PC.

[Ben]

OK,

Its code posting time.

Possible?

Ben

[jspaarg]

At them moment I am following C.Minnela's advice and trying to isolate what is slow.

It didn't seem that there should be a problem in the code since it is the same, but I am finding that "Case"ing out one VI eliminates the problem.  Now, the question is whether that is really the problem, or just a Wild Goose wasting time.

I am working my way through that VI at present.

Compunding the issue is that I am running an exe on the problem PC, but my development PC is quite a hike from that spot.

If I don't solve this soon, I will get remote access running.

I will either post more questions, or the solution.

[Matthew_Williams]

A couple of thoughts, potentially from _far_ left field:

1) mysql can be configured to authenticate by user, pword, etc. but also by (client) host.  Do your
deployment pc and development pc appear as the same host/user combination to mysql?

2) Does the deployment pc have the same network configuration (subnet, mask, gateway and
dns) as the development machine?  Is it possible to set them up identically?  Obviously only
one may be on the network at a time 😉

3) Do the machines have the same ram and virtual memory configurations?  Any difference
in the application configuration, i.e. # channels, selected printers, etc?  Same (identical) device on
the other side of COM1?

4) Are the hosts files on the machines the same?

5) Are the PCs using the same nameserver and are reverse lookups available for both?  This
is thinking back towards mysql again, where it might be timing out a reverse lookup.

6) Is it possible to temporarily move the deployment pc to where the development machine is
and use the same ip, cable, router, etc?

7) Is file indexing disabled on the deployment machine?

Sounds very frustrating;  hopefully you will find it soon, then it will be 'interesting'.

Matt

[jspaarg]

Thanks for the thoughts.  Left field is fine.  At present even the parking lot would be good 🙂  Turn off the lights, I'm shooting in the dark.

The difference in timing is not between the development PC and the deployment PC, it is a timing difference between two deployment PCs.  Each of which run the exe, but only one is connected to the network for any given test.  I swap all cables between the two PCs when I run tests (keyboard, mouse, monitor, serial port, network).  They have different network addresses, but are on the same domain.

The issue with the development PC is just how far away it is.  I have configured for remote logins and can now run my development PC from the deployment PC.  This eliminates about 400 yards of walking and two flights of stairs.  Should have done that sooner.

It does seem to be something with the mysql on the problem machine.

The other apps that access mysql that are working on both deployment machines do run considerably slower on the problem machine.  However, their timing difference is not as noticeable in "human time".  They take three seconds to do an update instead of 500ms.  Their human interface is slower normally, so they did not seem to be affected.

I was told by the person that set up the sql links that both PCs are the same.  The little bit that I know to check (administrative tools, odbc...) look the same on both PCs.

I do not know about the RAM size and VM configs (I can check later).

Since it is the same app running on both deployment PCs and the host, etc are set up by the app, it has to be the same on both PCs (doesn't it).