smacedo

I agree with everything stated so far, but would add 2 simple things

1. I use the Process Explorer <Process Explorer>From Sysinternals.com This FREE utility will allow you to see what is running in the background, and optionally disable it. There is also another FREE utility at the sysinternals site called AutoLogons which will allow you to easily browse and diable stuff that starts when Windows boots (it is easier than browsing the registry).

2. Video Acceleration This has been an issue with Labview in the past, if the video acceleration is too high it will cause glitches trying to resync what is displayed on the front panel. This problem seems to show up especially in Laptops. Click on Display>>Settings>>Advanced, then check the tabs for a acceleration or Troubleshooting Tab.

Yes - SYSInternals is great - lots of applications. TCPView is also very interesting when diagnosing problems with OPC or other network related issues in labview (or anything else).

Thanks for the hw video acceleration tip.

PS Explorer will also allow you to browse DLL dependency tree, so it's handy when creating distributions (.exe setup) to know which DLLs are required (there are other tools for this...)

Finally, PS Explorer will also show Context Switches delta, ie. how many times a certain process is picked up to run - how frequently - and then you'll notice how heavy firewalls and antivirus apps tend to be, doing context switching all the time.

What I would really like is to have individual entries running under svchost.exe process - so one could pinpoint which services are more damaging to the system. Does anybody have a suggestion?

Silvio

www.calmetric.pt

Hi,

I believe one of the reasons behind such OS events is caching and swapfile management.

Windows (among others) will try to optimize its performance by trying to cache things up in memory (dlls, filesystem accesses and such) in order to react faster. And if you have a lot of memory, it will cache a lot. This should be ok, except if it's done at a "bad time", while you are acquiring and processing an image.

At the same time, it will write some allocated data AND code memory segments to swap on disk, because it decides those won't be needed, or simply because more space in real RAM is needed and those blocks are less important.

So, two mechanisms at work: disk caching and virtual memory (swapfile). Both may occasionaly trigger disk and memory reading and writing.

Anyway, my point is, given enough RAM (depends on your software, but 1 gig at least for XP) , you can turn off windows swapfile completely.

I used to do this in Linux machines to avoid waste of time with swap (again, assuming I would always have enough ram), and even in old Win 95,etc, to save laptop's battery (avoiding use of hard drive). Using a RAM drive would help too. (having a drive running off from your memory, instead of disk).

Nowdays, if you have 2 gigs of real RAM memory, and disable swapfile, XP will cache almost everything it needs, and will (more) rarely write or read from disk.

Some will advise against this and will suggest instead creating a RAM drive and make swap work with that RAM drive. This, to me is kind of silly, (and probably tricky to arrange), because basically you are using up memory with a RAM drive, so that then you can swap memory into memory to release memory - yeah! silly enough to me...but, I may be unware of architectural details and OS design options that justify this.

You can also pre-copy an entire branch of .exes and .dlls into a RAM drive and start your application from there. You can use a dll dependency browser to decide which dlls you should move into that RAM drive before you run your app. By doing this, even if XP doesn't cache some code in memory, it will be reading them from a disk with the memory-like speed (many 10's of times faster, at least).

Another dependency you break with not having a swapfile is thermal calibration. Most drives (except those which are built to specifically avoid this) will perform some thermal calibration to the drive heads' alignment (and disk speed?somebody?) every few minutes or so.

When thermal calibration is being performed, disk cache at the electronics in the disk may, or may not, be enoough to avoid suspension of normal flow of data to and from disk. By not having a swapfile, you avoid risking your OS to decide now it's time to swap something from/to memory at the same time the drive is doing thermal calibration and pam! you have unreasonable cycle times...

All this tends to be worse when you allocate lots of frames in memory for processing and then deallocate. Lots of memory allocation, deallocation, management, caching decisions, swaping decisions...

Hope this helps! BTW, I do this regularly in our vision systems, despite not having ever done real tests on the impact of this strategy.

I would particularly like to know the impact of using SCSI controllers instead of IDE, and filesystem format (FAT vs NTFS). Does anybody know more about these?

Regards,

Silvio, CALMETRIC

www.calmetric.pt

Hello,

I used this and it works very nice but registering the ODBC connection in every computer where my app was running is not good... 

How can you use it without the connection? 

What do you input on the ADO connection open (I normally do DSN=<name of the ODBC connection> .

Thanks,

Paulo

3653[/snapback]

Hi Paulo,

The generic connectionstring syntax for a non DSN registered data source is:

[Provider=MSDASQL;] DRIVER=driver; SERVER=server;

DATABASE=database; UID=MyUserID; PWD=MyPassword

The specific syntax will vary a little for each provider. For example, for access:

DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=file.mdb.

(refer to, for example, Microsoft examples of connection strings

Also, look into this two interesting articles:

http://www.4guysfromrolla.com/webtech/070399-1.shtml

and http://www.4guysfromrolla.com/webtech/063099-1.shtml

(Jet 4 at: MS Jet 4 syntax for OLD DB)

where, these guys actually argue that using OLEDB is even faster.

Summary of it:

Copyright 2005 Jupitermedia Corporation All Rights Reserved.

...

Then, instead of using a connection string like DSN=pubs or DRIVER={MS SQL-Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine, use the following connection string:

objConn.ConnectionString = "Provider=ProviderName; Data Source=DatabaseSource; Initial Catalog=DatabaseName; User ID=UserID; Password=Password"

For SQL:

ProviderName = SQLOLEDB

Data Source = Server Name

Initial Catalog = Database Name

For Access

ProviderName = Microsoft.Jet.OLEDB.3.51

Data Source = Full path to .MDB file

(Note: This only works for ADO 2.0 and up! If you are using an older version of ADO, you will need to upgrade. You can download the latest version of ADO for free at http://www.microsoft.com/data.)

So, let's look at two examples, one for Access and one for SQL. Say that you had a DSN-less connection string for a SQL database like so:

DRIVER={MS SQL-Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine

To connect directly to OLEDB, your connection string would be:

Provider=SQLOLEDB; Data Source=myMachine; Initial Catalog=pubs; User ID=sa; Password=

Now, let's look at the Access side. If you had an Access connection string like so:

DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=c:\inetpub\wwwroot\users.mdb

To connect directly to OLEDB, your connection string would be:

Provider=Microsoft.Jet.OLEDB.3.51; Data Source=c:\inetpub\wwwroot\users.mdb

[for MDAC 2.8, use OLEDB.4.0 - Silvio ]

That's it! Pretty simple, eh?

Copyright 2005 Jupitermedia Corporation All Rights Reserved.

Hope this gets you going, if you haven't yet! Ah.. and this works fine with LABSQL too.

Silvio

www.calmetric.pt