I have been using FolderMatch for a long time in order to synchronize file between the main computer I use and the synology file server. However, perhaps because the synology is linux based, Foldermatch did not handle access and authentication correctly. It was impossible to delete files on the synology network disk. Otherwise it is a great tool. I then tried OpenSync, but soon ran into the problem that it does not support to not check on file size and date. Basically, pictures, mp3, etc. doesn’t really change and in most cases the file size difference is due to the different file systems on the local pc and the synology. So to get a speedy synchronize I want to omit that check for many folders. My latest test is Beyond Compare, a good old and reknown file comparison tool that also includes folder synchronize. So far it seems to work ok – it support both network access and one can turn off size and date check.
More about the MIL-Lite upgrade, I have had several problems. I should start by mentioning that we require our applications to work on MIL-versions back to 6, in order to be able to support the excisting customer base:
– Matrox have strengthen the typing on all MxxxInquire functions. Probably a good idea, but it means that all previous uses of the functions, for example MBufInquire is not supported anymore and have to be upgraded. Since we are dealing with pointers here, pointers to stuff of different lengths, this is not an easy upgrade. My solution was to use #if M_MIL_CURRENT_INT_VERSION >= 0x0900 in those places where I was unsure about whether further use of the pointers required a specific width.
– I am unable to retrieve previous hanlder ptr and user handler ptr:
The type of the third parameter is not supported anymore (
– The most serious problem is that Matrox has ceased support for the Mvga functions. I used them for getting a pointer to a DIB structure, in order to draw the dib to a printer device context. I canot find a real alternative to these functions
– And, not related to code, I am not able to debug the application as I constantly get an error message about missing license. However I have a Matrox Meteor 1394 card installed, with a Sony 1394b camera. I am not sure why this does not work – perhaps the Meteor is not supported in version 9, or there is still problems with 1394b speeds. Anyway I will order a USB license key.
– The Matrox developer forum is a closed one. Whenever I try to enter, typically every sixth month, I am not able to log on. Of course I have a valid support agreement and all that, but I do not remember my username or my password. I do remember the email address I am registered with, but it seems not to be enough. So I am not able to see any posts. I don’t understand why the access needs to be that restricted.
So at the moment, I am not able to get Mil-Lite 9 to work on Vista – or any version of MIL to work on Vista, I am not able to get help through the forums, and I wonder whether I rather should switch to another vendor!
Finally, Matrox has released version 9.0 of their MIL-Lite imaging library. Finally – because it is the first version with Vista support, and as most people know, Microsoft has ended selling Windows XP. I have got a hand of a beta version and installed it today. Up to now I have had to use a second computer with Windows XP to debug and run the applications. More on that at another time.
Anyway, as the application also use DAC boards from Computerboards (now Measurement Computing), I needed to instasll their Vista-compatible InstaCal driver too. Their drivers always work ok, so I was surprised when the installation repeatedly stopped with the error “Error 2738: Could not access VBScript run time for custom action”. After searching the Measurement Computing forums , I went to google and it turned out that this error stems from vbscript.dll not being registered. How on earth that windows component did get unregistered I do not know, but this procedure fixed the problem:
1. Run Command Prompt as administrator
1.1 Start Menu -> All Programs -> Accessories
1.2 Right click on Command Prompt and select Run as administrator
2. Type cd c:\windows\system32 into the Command Prompt and hit Enter
3. Type regsvr32 vbscript.dll into the Command Prompt and hit Enter
It has been a long while since last time I updated the blog. However, as I am now in the process of upgrading my work computer (actually building a new one), a few interesting points have appeared, where this post is about the first one.
I decided to go for to Samsung f1 1TB disks in a raid 0 setup. The Asus P5E3 motherboard uses the Intel ICH9R controller. After booting up, and entering the ICH9R configuration utility, I had to fill in the stripe size – it defaultet to 128kB. This started a long and interesting web search after what is the optimal stripe size. Interesting enough, different sites, including anandtech and Toms hardware had completely different advices.
Raid 0 means that data is divided among the two disk, and the stripe size in a raid 0 configuration is the size smallest allocation unit on each disks. After selecting the stripe size in the ICH9R controller it is impossible to change without destroying all the data on the disk. So If one decides to go for 128kB, the first 128 kB of the total 2GB disk is situated on disk A, and the next 128kB on disk B, etc. It has no connection with the filesystem allocation size (cluster size), and the stripe size is invisible to the operating system.
There are basically three different factors that determines the optimum stripe size.
The first, and probably least important, is that the windows swap file always uses 4kB cluster allocation units. Given that this file is very much in use, you will be able to almost double the swap file write and read speed as you can execute two 4kB writes at different adresses at the same time (random access) – if the stripe size is 4 kB.
The second factor is that reading and writing sequentially large data files (for example copying, downloading, video editing, …) benefits from a large stripe size. Anandtech had examples of up to 1024 kB.
The third point is tha random access of small chunks of data benefits from less IO access time – that is how fast i takes from a request for a read/write is started to it actual starts. The more disks you have in a raid 0 setup, the slightly larger will the access time be.
In actual life, your choice of stripe size will depend on what type of user you are.
So, in the end, adriansrojakpot recommended 4kB or 8kB, Anandtech recommended “as large as possible”, and Toms Hardware, having the most throughout review, recommended 64 kB (but had a big flaw late in that article about large stripe size vs. file system cluster size).
My solution? It turned out that the ICH9R controller does not support more than 128kB, and I decided to go for that. However, the ICH9R support “Intel Matrix Storage” that allows for dividing up the disks in two raid 0 solutions, so I went for 1843 GB with stripe size 128 kB, and then a small rest of 20GB with stripe size 4kB. After installing Vista I moved the swap file to that 20 GB partition, so that I could get the best of two worlds!
In the end, the solution gave a top score 5.9 in windows experience index, and this image shows how it looks like in the image storage console view.