Havin problems with VS9. Rather than explain the whole problem now, I need to try one more thing -- if that fails, I will post the works!
I am storing my videos on Disk I (300GB). My boot drive is only 40GB (only 16GB free). I have increased page file size on both to 4GB (twice my RAM). How does one know which page file VS9 is using -- C or I??? Can I tell VS9 which to use? If so, how? Does it automatically use the page file on drive I since that's where the videos are?
I am using XP. P4 2.8Ghz.
I will post all spec as instructed in the PROCEDURE post when I have figured out this page file thing.
Thanks.
Need help with page file...
Moderator: Ken Berry
-
Ron P.
- Advisor
- Posts: 12002
- Joined: Tue May 10, 2005 12:45 am
- System_Drive: C
- 32bit or 64bit: 64 Bit
- motherboard: Hewlett-Packard 2AF3 1.0
- processor: 3.40 gigahertz Intel Core i7-4770
- ram: 16GB
- Video Card: NVIDIA GeForce GTX 645
- sound_card: NVIDIA High Definition Audio
- Hard_Drive_Capacity: 4TB
- Monitor/Display Make & Model: 1-HP 27" IPS, 1-Sanyo 21" TV/Monitor
- Corel programs: VS5,8.9,10-X5,PSP9-X8,CDGS-9,X4,Painter
- Location: Kansas, USA
-
jchunter
The swap file defaults to the C drive but XP supports a swap file on every drive. You can set up another one in your larger drive in the XP Device Manager / Advanced Tab / Performance Settings / Advanced / Virual Memory (Change) screen.
If you have 2GB of RAM, IMHO, you don't need much of a swap file. I have 1GB of memory and use 1 GB Swap file and seldom see memory usage above 500 MB. Try using 1GB swap file and that will save you 3 GB on your small C drive or set up another one on your I drive.
john
If you have 2GB of RAM, IMHO, you don't need much of a swap file. I have 1GB of memory and use 1 GB Swap file and seldom see memory usage above 500 MB. Try using 1GB swap file and that will save you 3 GB on your small C drive or set up another one on your I drive.
john
-
GeorgeBW
Hi Guys,
John you wrote..
"The swap file defaults to the C drive but XP supports a swap file on every drive."
This suggests multiple paging files, which isn't really the case. You are actually extending the swapfile from the system drive onto a second drive. Windows will use the whole allocated space across the two drives as a single swapfile, and cache the area on the second drive when it needs to. This answers the vs harrison question "How does one know which page file VS9 is using?" But in effect your suggestion to maintain a 1GB area on the system drive, and add another 3 GB on the second drive is still the best idea when the primary drive is a bit lean on free-space... Your idea will give a very reasonable paging file size of 4 GB... but I would still keep the area on the primary drive to at least the same amount as the installed RAM though (Set the maximum and minimum figures to the same value).. and the following paragraph explains why.
vsharrison wrote..
"I am storing my videos on Disk I (300GB). My boot drive is only 40GB (only 16GB free). I have increased page file size on both to 4GB (twice my RAM)."
This sounds like you may be using a removeable drive... It is not a good idea to depend on a paging file that is on a drive that might not always be attached to the interface... This is why it is important to keep a solid paging file area on the primary drive..
Cheers
George
John you wrote..
"The swap file defaults to the C drive but XP supports a swap file on every drive."
This suggests multiple paging files, which isn't really the case. You are actually extending the swapfile from the system drive onto a second drive. Windows will use the whole allocated space across the two drives as a single swapfile, and cache the area on the second drive when it needs to. This answers the vs harrison question "How does one know which page file VS9 is using?" But in effect your suggestion to maintain a 1GB area on the system drive, and add another 3 GB on the second drive is still the best idea when the primary drive is a bit lean on free-space... Your idea will give a very reasonable paging file size of 4 GB... but I would still keep the area on the primary drive to at least the same amount as the installed RAM though (Set the maximum and minimum figures to the same value).. and the following paragraph explains why.
vsharrison wrote..
"I am storing my videos on Disk I (300GB). My boot drive is only 40GB (only 16GB free). I have increased page file size on both to 4GB (twice my RAM)."
This sounds like you may be using a removeable drive... It is not a good idea to depend on a paging file that is on a drive that might not always be attached to the interface... This is why it is important to keep a solid paging file area on the primary drive..
Cheers
George
-
jchunter
I have always been conflicted about page swapping in real-time environments.
Video editing has real-time requirements when capturing and during playback. Capturing is the most intensive because the computer has to (1) bring video data into an input buffer, (2) convert it to a new format and store to an output buffer, then (3) write the converted data onto the hard disk. Captured data arrives at a fixed rate (~ 30 fps) and if it can’t be converted as fast as it arrives, the input buffer has to grow to avoid dropped frames. This is the “CPU-bound” condition, which can be caused by a slow CPU or an over complicated conversion algorithm. On the other hand, if the output data can’t be written to disk as fast as it is converted, the output buffer has to grow larger until it is written to disk. This is the “I/O-bound” condition, which can be caused by a slow or fragmented hard drive. (IMHO, this is less common.)
Since both of these buffers have to exist in real main memory, when they together exceed the capacity of installed memory, a crisis occurs and something has to be done. The paged memory solution is to create space in main memory by writing out part of it to the swap file.
I have two problems with this approach:
(1) If the system is already CPU bound, the act of initiating and terminating the paging I/O can add a significant amount of additional work for the CPU and also may delay the conversion process until the page swap I/O is finished. Note that any amount of additional CPU load or time delay to alleviate a CPU bound state can only increase the size of the input buffer and its growth rate. Moreover, eventually, the page that was swapped out has to be brought back into memory, placing yet more strain on overloaded resources.
(2) If the system is already I/O bound, writing pages to the same disk can only make it more so.
This is a simplified analysis but I think it fairly describes the fundamental problem. Note again that these comments apply to real-time applications. Paging can be an effective strategy for applications that can take additional time to complete.
What to do?
Clearly, a faster CPU or capturing to AVI instead of Mpeg will reduce the CPU load. More memory also helps by efficiently providing more headroom during variations in CPU loading during the conversion process. DMA reduces the CPU involvement in the I/O process. Enabling Write Caching could, in principle, also help by permitting the CPU to proceed without waiting for I/O to complete (but I can’t recommend it because I experienced corruption within Video Studio, when it crashed, that required re-installation to repair).
If the system is I/O bound, defragging can help as can a faster hard drive (e.g., 10Krpm) or having two drives to permit concurrent I/O.
What about the swap file?
If the average conversion time exceeds the time between capture I/Os, a critical buffer overrun is inevitable, regardless of the size of the swap file. The best that can happen is that a larger swap file could delay the inevitable long enough to capture in short clips.
If the average conversion time is less than the time between capture I/Os, a larger swap file could provide more input buffer headroom for prolonged (but infrequent) periods of CPU saturation. However, since the cost is to increase both the CPU and I/O loading, it is a delicate balancing act and crashes would still be possible.
Video editing has real-time requirements when capturing and during playback. Capturing is the most intensive because the computer has to (1) bring video data into an input buffer, (2) convert it to a new format and store to an output buffer, then (3) write the converted data onto the hard disk. Captured data arrives at a fixed rate (~ 30 fps) and if it can’t be converted as fast as it arrives, the input buffer has to grow to avoid dropped frames. This is the “CPU-bound” condition, which can be caused by a slow CPU or an over complicated conversion algorithm. On the other hand, if the output data can’t be written to disk as fast as it is converted, the output buffer has to grow larger until it is written to disk. This is the “I/O-bound” condition, which can be caused by a slow or fragmented hard drive. (IMHO, this is less common.)
Since both of these buffers have to exist in real main memory, when they together exceed the capacity of installed memory, a crisis occurs and something has to be done. The paged memory solution is to create space in main memory by writing out part of it to the swap file.
I have two problems with this approach:
(1) If the system is already CPU bound, the act of initiating and terminating the paging I/O can add a significant amount of additional work for the CPU and also may delay the conversion process until the page swap I/O is finished. Note that any amount of additional CPU load or time delay to alleviate a CPU bound state can only increase the size of the input buffer and its growth rate. Moreover, eventually, the page that was swapped out has to be brought back into memory, placing yet more strain on overloaded resources.
(2) If the system is already I/O bound, writing pages to the same disk can only make it more so.
This is a simplified analysis but I think it fairly describes the fundamental problem. Note again that these comments apply to real-time applications. Paging can be an effective strategy for applications that can take additional time to complete.
What to do?
Clearly, a faster CPU or capturing to AVI instead of Mpeg will reduce the CPU load. More memory also helps by efficiently providing more headroom during variations in CPU loading during the conversion process. DMA reduces the CPU involvement in the I/O process. Enabling Write Caching could, in principle, also help by permitting the CPU to proceed without waiting for I/O to complete (but I can’t recommend it because I experienced corruption within Video Studio, when it crashed, that required re-installation to repair).
If the system is I/O bound, defragging can help as can a faster hard drive (e.g., 10Krpm) or having two drives to permit concurrent I/O.
What about the swap file?
If the average conversion time exceeds the time between capture I/Os, a critical buffer overrun is inevitable, regardless of the size of the swap file. The best that can happen is that a larger swap file could delay the inevitable long enough to capture in short clips.
If the average conversion time is less than the time between capture I/Os, a larger swap file could provide more input buffer headroom for prolonged (but infrequent) periods of CPU saturation. However, since the cost is to increase both the CPU and I/O loading, it is a delicate balancing act and crashes would still be possible.
-
THoff
You can also bypass having a swap file on the first drive altogether -- that's what I do.
I have a 36GB 10,000RPM SATA Western Digital Raptor set up just to hold the Windows swap file, and I'm also pointing the TMP and TEMP environment variables to it to make Windows create any temporary files on that drive.
I have a 36GB 10,000RPM SATA Western Digital Raptor set up just to hold the Windows swap file, and I'm also pointing the TMP and TEMP environment variables to it to make Windows create any temporary files on that drive.
-
vsharrison