smacedo

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

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