Hi Dave,Did you see my post above about benching? I have no doubt that this works for you but others here would like to see some numbers that might help them decide to pursue this. HDTach is very easy to use and takes just a minute to download and test.Much appreciated,Greg

transfer speed is half, seektimes are an order of magnitude lower.That means that for a very large file you get roughly half the speed you'd get from a harddisk, for a very small file you may get one tenths or less the speed.FS uses a LOT of small files...

Greg: Thanks, I am downloading now and will try it out tomorrow and post results.

I was talking to a tech, a friend of mine who has earned his living with computers for 30 years. I asked him why my FS installation is a lot faster with the FS folder compressed than it is uncompressed. He told me that every disk I/O with request with IDE causes the CPU to halt for a very short moment. With the compressed folder you can limit disk I/O requsts. To my knowledge you will have none with USB as the USB host chip is doing the work. Another possibility is SCSI. I have no idea about S-ATA.Alex

Hi,I do not doubt that you see better performance on your USB disk, but I think it has more to do with bad performance on your regular disks...So this may not work for all. For instance, how long since you defragged your internal disks? And how long since the you did it on the USB? Also, do you have any slow devices (cd-rom, DVD) connected to the same IDE channel as you normal disk? That *will slow* it down!I also have an external USB disk, and I'm very impressed with it's performance. However it does not even remotely compare to my internal disk setup, which is 2x120 GB Maxtor 7200 rpm, 8MB cache, S-ATA in RAID1 on Intel ICHR5. Oh, that reminds me: What is your USB disk RPM and cache as opposed to your internal disk?As you see, there may be a lot of things determining your disk performance.BRGDSSven Sorensen, EKCH

Sven,this is not about disk performance or rpm or cache or defragging.. There is no coubt that today's IDE ATA or S-ATA HDs are faster. The bottom line here is I/O requests and CPU utilization. The disk I/Os stall the CPU. That is what we are talking about here.Alex

Works like a charm. Thx fr the tip-Alex

>>installation is a lot faster with the FS folder compressed>than it is uncompressed. Makes zero difference on my system in terms of performance. But I keep it compressed since it saves space.Michael J.WinXP-Home SP2,AMD64 3500+,Abit AV8,Radeon X800Pro,36GB Raptor,1GB PC3200,Audigy 2

How do you defrag your internal disks? Is it the same as defragging your HD?

Alex- That information from your friend is completely wacky. If he has worked with computers for that long, I'm sure he misunderstood the question or something. First, I/O requests do not halt the CPU- they are not even handled by the CPU. Second, why would compression not cause this if that were the case? The compressed data still needs to be read off the disk. Furthermore, and the reason that is completely wrong, is that the compressed data must be uncompressed- The CPU handles the decompression- That's not a hardware feature.I believe the exact reason was stated before- Your IDE drives are so fragmented and overutilized that probably anything seems faster. I have a USB 2.0 120 gig external drive and it's a joke compared to my internal drives.

You know I do not even want to discuss this anymore. I am completely bored by people who deny what others experience while not even tryng these things.The reason why the compressing works is that the decompression takes up less resources than the disk I/O. And of course there is CPU usage during disk I/Os as the CPU processes the commands of the IDE interface. Ah and I defrag my drive every few weeks with Perfect Disk. Whenever you experience somethin here that does not fit the regular they simply assume that you have forgotten to install your chipset drivers, or you are to dumb to install graphics card. I am so tired of this. No, the world is not a disk.Please read this from an article in earthlink:Another important consideration is that reading and writing operations to and from E-IDE or UltraDMA hard drives take up more of your CPU's resources than when performed with SCSI drives. These reading and writing operations to and from the hard drive are referred to as "disk I/O". The reason for IDE's higher processor usage is that the IDE interface needs the CPU to process the commands that control its basic disk I/O functions. The control circuitry on a good SCSI adapter (such as the Adaptec AHA-2940U2W or AHA-19160, Tekram DC-390F or AdvanSys ABP-940UW) will perform these disk I/O commands by itself, without the help of the host computer's CPU - by a process called "Bus Mastering". This allows the host CPU to concentrate on other functions, like processing that Waves TruVerb DirectX plugin's reverb algorithm in real time. The result is that reads and/or writes to a Bus Mastering SCSI hard drive won't interrupt your work (i.e. you will get better 'multi-tasking' performance).FS with it's high CPU usage, permanent disk flow, high memory usage is a totally different animal than the average ego shooter. That is why a lot of things apply here that are not discussed in a regular "gaming faster" magazine. If there is no CPU utilization with IDE/ATA why does SCSI exist?I know what I see. Case closed. This has been the last time that I discuss or share any ideas here that are performance related in FS.Alex

>Ah and I defrag my drive every>few weeks with Perfect Disk. Every few weeks? My system is automatically defragged daily, with Diskeeper. Actually, it defrags while the screensaver is running, so does not slow down the operation of my system, whenever Im using it.... Adding addon's, or deleting others, even deleting a photo from your drive or adding one, can fragment the next addon file or aircraft you add to the system. Even if you defrag it, download half a dozen files, install them, and then delete the zips, the installation may have been done around the zips, so it leaves it quite fragmented. Just to see what would happen, I defragged my 200Gig drive. Then, downloaded 12 scenery, aircraft, and texture .zip's Unpacked and installed them. Then, defragging it, according to the report improved drive access 58%. The auto defrag had not had time to run as Ive been using the computer since 5:30 AM PST.... You may not use your system as hard as I do, but you may find defraggin at least once a week would definitely benefit FS9... Bob

Only SCSI supports bus mastering? How old is that article? There were motherboards that supported bus mastering on Windows 95. To check, go into the properties of your IDE controller and set it to DMA Mode 2 (instead of PIO). Most hardrives newer than 3 or 4 years support Mode 2. That article you quoted is somewhat incorret. An UltraDMA drive supports bus mastering- while they use it as an example of a drive that doesn't. This could be because the motherboard doesn't support bus mastering, or the drivers aren't installed- but that's kind of misleading isn't it?And why are you getting so defensive? First, I'm not saying the USB device did not improve your performance! Not once, in one post I've made, did I allude to that. What I am saying is that USB is inherently slower than IDE. Half as fast as ATA 100, 1/3 as fast as SATA. Bottom line- If an external USB drive gives better performance that your hard disk, then there is something not correctly configured on your hard disk. I am not saying anyone is stupid, or throwing out insults. If you improve the performance of your internal hard disks, the whole OS will benefit, not just FS.

Thanks Greg for the link. Here is the Quick Bench result: (both tests were performed with identical systems running and no programs running:My: C drive (20 gig WD Caviar)BURST: 92.1 MB/SRANDOM ACCESS: 17.8 MB/SAVERAGE READ: 25.3 MB/SCPU USAGE: 2%USB EXTERNAL WD 80 GIG: BURST: 21.9 MB/S (big difference there!)RANDOM ACCESS: 15.1 MB/SAVERAGE READ: 21.3 MB/SCPU USAGE: 5%Obviously the performance of the internal HD is better than the external USB harddrive. Which means,I think, that although I am experiencing better performance with the FS9 on USB it must be because of some other factor with the FS9 install on the internal drive. Defragging: I Defragged both drives, the internal 3 times in a row and the USB drive only once after FS9 installation. It is a clean partition with only FS9 on it.I'm not knowledgeable about the benchmark terminology at all and only report here what HDTACH reported. But, I can surmise that if all things were equal, the USB would not perform like the internal drive should. The USB does great as long as I do not throw more than 1/8 cloud coverage in. If I do, it really bogs down - especially with cumulus.Since I obtained the above HDTACH results, I switched my USB drive with a second drive I had internally, making that one the USB drive.I then fired up FS9 and had essentially the same performance (FPS with 1/8 clouds) and all other settings the same. When I introduced greater cloud coverage and higher autogen and scenery complexity I was still able to maintain acceptable performance, which was not the case with the USB setup. So, for someone with a moderate system and not a need for high eyecandy settings a highspeed USB drive could be an answer if the internal disk slots are taken. It does work and very well considering the limitations. Thanks again, Greg for the link to HDTACH- If I hadn't seen this, I would still have FS9 on the USB without the eyecandy!

Hi Alex,Sorry, beg to differ: YOU may be discussing CPU 'stalling' (I would call it 'interrupting'), but Dave (Leafhopper) started out simply by saying that putting FS9 on his USB HD worked wonders for him. I'm not denying that, neither that the CPU is interrupted by the I/O controller. And it might even be the an USB controller does less than a normal IDE or SATA or even SCSI.My point is that if 2 disk types performs differently, is it because disk A is fast, or because disk B is slow...?? If disk B is slow, then maybe your application (FS9 in this case) also is slow, not because of interrupts but because of waiting. Whether you're using USB or IDE, or SCSI or whatever: Data is requested by the application. If it's not in memory when it is to be used, then the application will have to wait. And in this case, both defrag and cache and rpm comes into play.BRGDSSven Sorensen, EKCH