I have never tested with using an external HDD for the Windows Virtual Memory Page File. I see two potential problems with this:
The Page File is created early in the bootup process, so the external will need to be up, running and also fully recognized by the OS at the earliset level, and also the external's connection WILL be slower, than an internal, unless one is using eSATA, and then, that connection will need to be recognized, and any drivers loaded, at the earliest stage of bootup.
I have experimented with placing my Page File on various internal HDD's, and even spanning it over several. After benchmarking my various tests, I found that on my workstation, I got best performance with statically managed Page File on C:\ and D:\, and on the laptop, statically managed all on E:\. Both machines are still running XP-Pro SP3, and all internals are SATA II.
Exactly what would you like to accomplish by having the Page File on an external?
I've found that the simplest solution is the best.
1) Keep at least 20-30 gigs of free, clean, freshly defragment space on your C drive so that the program has room to open and "breathe". Let Windows manage your paging files on this drive and run Advanced System Care Free's Deep Care weekly to keep the spyware down and keep the drive in order.
2) Keep your projects and media files on a separate (ideally internal) hard drive. (Make sure that each project file is saved in its own folder.) This drive should be properly configured in both your operating system and your BIOS and it should be formatted NTFS, not FAT32, as they come from the factory.
3) Make sure that the program's Edit/Preferences/Scratch Disks are all set to Same as Project.
Bill and Steve,
Bill, if I am understanding correctly you are talking about having only One paging file spanning drives. I was asking about leaving the Windows Managed Paging (Virtual Memory?) File on C Drive and an additional Paging File on an extra drive. Again maybe I read wrong in the various forums.
I do have 3 eSATA external drives which I use for storing various family movies. I may buy a 2 TB internal later, but this is what I have now. My desktop is an i7 2.8ghz wiith 12 GB RAM, 64 bit Windows 7, 1 TB Hard Drives RAID 1? (MIrror Image). I have a huge paging file. I haven't been using an external drive for my Scratch Discs, but was going to set one up to do that, so thus my reasoning for asking about a separate paging file.
The eSATA connection is really quick, so it seems I will have no problem there. But the problem as I understand it, is all Premiere Elements versions (I have PrE7 & PrE9) up to PrE10 are 32 bit and are going to only use a few GB of System Ram before (or along with) using the Paging File. So if there were additional Paging Files, maybe it would be less CPU intensive. I don't know if Bill measured CPU usage in his tests, with and without the extra paging file. Not talking about speed necessrily but CPU usage.
I do Defragment quite a bit even though it says 0% defragmented, and expecially after I have moved a bunch of files around. For each Project I keep everything in one folder, even exports, so that if I want to delete a project but keep the AVI, I don't have to look all over the computer to delete various parts of the project. I may change some of that procedure later, but works for now. My Scratch Discs are Same as Project, thanks.
Thanks for one TIP I believe Bill gave in another Post was to not store Projects? or video? on the Desktop, because it may have different characteristics (video editing problems?) than other storage folders. I thought that was interesting because I think people get used to putting stuff on the Desktop because it's easier than going to other folders. So now I just have Desktop Shortcuts to the folders I use all the time.
Don't know what Statically Managed means.
The Windows Virtual Memory/Page File can be set to any drive that the OS recognizes, at bootup. What I do not know is whether those eSATA externals are seen early enough in the bootup process, to allow for use with the Page File. You should be able to tell, when you go to manage your Virtual Memory/Page File. Are those eSATA HDD's in the list?
As for management of the Virtual Memory/Page File, one has two options:
- Let Windows manage it, dynamically, expanding it, or shrinking it, as Windows anticipates its usage
- Set the size, so that Windows does not do the calculations, and anticipation - the size is static
I like # 2 for three reasons: I set the Page File up, with ONLY the OS installed, and the C:\, and other HDD's empty. This gets my Page File written out near the platters' edges, for faster access, it creates the Page File in the same spot, and of the same size, at bootup, so all defragmentation can take place beyond the Page File, plus this saves CPU cycles, as Windows does not have to do any extra calculations.
Hope that helps, and please let us know if Windows Virtual Memory Management offers those eSATA drives as options.
You were a little above my head with the near the platters edges and windows calculations, but as I don't know how Windows 7 (in my case) accesses the paging file other than offf the hard drive, it sounds most excellent. My hard drive is partially filled so won't work that way for now anyway.
I finally remembered to check the Virtual Memory for which drives apparently could use the paging file, and it seems that maybe they all can. I'm including a ScreenShot, but don't make fun of my logic on why I picked the min/max numbers I used for a custom paging file size. There was some logic 2 years ago when I set it up but can't remember now. Suggestions as to what you or others would recommend I set it at (based on 12 GB RAM) are welcome. For some reason, it shows 800MB allocated for the OS but as you can see the file size is 800 Min- 4096 Max (a minimum of 16 is allowed)
You will notice that I have my M drive (eSATA) highlighted and it looks like a paging file can be set up but I didn't screw around with things at this point unless you think it looks viable. I also fired up another drive with firewire 400 connection and it also showed up in the list, so apparently all drives could have their own paging file.
Note: I have 3 eSATA capable external drives. I have 3 eSATA ports on my desktop, but because of the RAID 1 configuration the motherboard eSATA is worthless. Near as we can figure out it thinks an external drive connected to that port is somehow part of the raid configuration. So I have the firewire connection on the one external.
Thanks. Your help is appreciated
I know you have a lot of posts going, but I was reading some of your other posts on paging files and I am hoping for some more clarification. I hope to not be too long winded.
(1) I have PrE7 and PrE9 32 bit programs. There is no way that these programs can use the available physical RAM? I have a 64 bit computer. Is there enough advantage in moving to PrE10 to use the additional RAM I mentioned above instead of the limited usage of the 32 bit programs. Will the usage of additional RAM use less of the paging files or am I confused on how paging files work.
(2)You mention setting up the paging file at the platters edge on a clean hard drive. Does a hard drive write from the outside and move toward the center?
(3) I feel like my paging file size although statically? managed is incorrect and would ask (based on the 12GB RAM) what you guys would use. Most posts mention a maximum page file size but I haven't seen any minimum recommendations (I used the 800 figure).
(4) I definitely want to try the additional paging file on a second hard drive. What would you recommend for that paging file size. I am guessing most people aren't aware that this can be done and might solve some editing problems. How does windows (Windows 7 in my case) know how to use 2 or more paging files?
For number 1, if yoiu have the 64-bit version of PrE 10, and Win7-64, with at least 12GB of RAM, the Page File will become less of an issue. With 32-bit apps. and 32-bit OS's, I like statically managed Page Files of about 2.5x the installed physical RAM - usually only 4GB, as a 32-bit program can only use ~ 3.5GB of RAM.
The Page File allows the OS and the programs to treat HDD space, like RAM, and use more, than the installed RAM. However, HDD's are much slower than RAM, so getting as much into RAM, as you can, will speed things up, and greatly.
For number 2, yes. Also with a statically managed Page File, setup on an empty HDD, it will always be created in the same spot every time one boots up. Though the speed decrease in only slight, the closer to the hub of the platters, the Page File is written, the slower it will be to access, as the heads have to travel farther.
Number 3 is a bit of a gray area. With a 64-bit OS, and 12 GB RAM, the Page File will see much less use, as much more can be written into RAM, which will always be much quicker. I still feel that a statically managed Page File, set up very early, is the best, though with less use, one might never see the difference. It does help things with HDD management and defragmentations.
Windows will offer all HDD's, that it sees, for Page Files (number 4), and you can experiment with placing the Page File on each, or spanning to multiple HDD's. On an older NT 4 computer, with smaller HDD's, I split the Page File over 4 physical HDD's, for slightly better results.
Splitting the page file. Does this mean you assigned 1 GB on each drive instead of 4GB on the OS drive? or somehow had Windows to use 4GB across all four.
If the paging file is set to a lower limit (say 1GB max total) will this force the program to use more physical memory or just cause problems? Sorry, I'm sure this question has been asked before, but wondering the necessity of excess virtual memory. Getting more into RAM as you say.