Swap file- Install it on the boot or on the capture drive?

[Patrick]

This topic recently has come up in another thread, but I wanted to give it a bit more exposure. I've always read here at this forum that the swap file should NOT be on the video capture drive (assuming that the boot drive and the capture drive are different drives). However, in the November issue of Camcorder & Computer Video magazine, Peter Utz has written an article called Dropped Frames that states quite the opposite.

From page 30

Locate your swap file (virtual memory) on the same drive as your video. Having a swap file in the C: drive while capturing to the D: drive can cause you to drop frames. Evidence that your swap file is in the wrong place: While capturing or playing back video from the D: drive, you notice that the C: drive is being accessed; it should be quiet.

So guys, what do you think? Is this fellow mistaken or do any of you agree with what he's stated?

[wkulecz]

I think if you are hitting swap very much you'll drop frames no matter what. Buying more RAM is the real answer.

I think the author made a mistake. Having the swap on the video drive means writing to swap moves the head away from the video data stream and practically garauntees dropped frames unless the video data rate (quality)is very low.

Capturing on D with swap on C lets you get away with a small amount of swapping. But enough RAM to not swap while capturing is the real answer!

--wally.

[This_Idiot]

Hi Patrick,

As always, I'd recommend that everyone TESTS these (or any other) ideas to see whether they result in an increase in performance on their own setup. It amazes me that so many people are prepared to spend hours trawling for a "perfect" answer instead of spending 10 minutes (or half an hour, or an evening, whatever) on trying out combinations. A pen and paper can be helpful here An old question is that of whether to site 2 HDs on the same header or whether to use the master channels on both IDE0 and IDE1 - how do folks think that we all came up with our answers ?

Back to the problem in hand. I reckon that the capture drive is already taking as much of a hammering as it can cope with. On the other hand, the boot drive is sitting there idle (once the code has been loaded) with the exception of the windows swapfile and any cacheing that the capture utility is using.

I know that there can be conflicts within the HD controller itself if it is trying to address 2 HDs at the same time, but I would rate this as a lesser risk than unwanted head movement.

As always, I reckon that there will be many other opinions on this subject

BTW, I caught a documentary a couple of nights back about "maelstroms", and it appears that there is a regular appearance of one just off Vancouver Island. Don't go driving any small boats over there huh ?

[Patrick]

Wally, what you say is interesting, but I've been told here in the past that the amount of RAM really doesn't make any difference (within reason) for video capture and editing. For anyone who may be interested, I found one of the old threads where we were discussing the amount of RAM required for video editing.

http://forums.murc.ws/ubb/Forum2/HTML/001327.html

Another possible variable to consider regarding boot vs capture drive for the swap file is if the capture drive is a LOT faster than the boot drive, especially if video capture is done on a raid array of multiple drives striped together as one.

Additional feedback on any of this would be great.

---------------------------------------------------------

O/T

Chris, I wasn't sure what a maelstrom was until I looked it up in the dictionary. It sounds like some kind of a whirlpool. I wouldn't be surprised if that documentary you saw was referring to the northern tip of Vancouver Island. I've never been to that area myself, but I hear it can get awfully wild on the water there.

[wkulecz]

Once you have enough RAM to not hit swap while capturing I agree adding more does nothing for video capture.

As to editing this depends on the program and how effectively it uses memory. Swap is a method of last resort to keep the system alive instead of running out of RAM. If you are only swapping to switch from one app to another than it "works" wonderfully. However, if parts of an interactive application is regularly hitting swap performance goes to hell in a handbasket.

I cetainly agree that once you have enough RAM for your application to not hit swap, addding more is unlikey to make any noticable difference.

A "permanent" swapfile is a windows 3.1 optimzation, its really not needed for win9x or w2k, although it might make a noticable difference in a bad situation where you are doing a lot of swapping.

As an example, MSPro can readily have four applications open -- Video Editor, Video Capture, CG Infinity, and Audio Editor. Hitting swap while switching among them causes a noticible delay (although generally noticably less than loading the program the first time, and much less than quitting VE and starting VC) but as long as the application code doesn't hit swap you'll be happy. In this case all more RAM can do is reduce the application switching time -- which may not be cost effective, depending on how you like to work.

I never do anything but leave the swap file where it is upon installation. But then I've never tried to use win95 in less than 64MB of RAM, win98 in less than 128MB or w2k with less than 256MB.

I've seen other peoples win98 systems with 32MB of RAM and even on a decent processor (500 Celeron) I thout the system had locked up when doing mundane things until I noticed it was swapping. Pain thresholds vary greatly.

--wally.

[Brian Ellis]

I've tried various combinations and come up with the following as giving the best answer:
IDE0 master: bootdrive on 2 MB partition, the rest used as storage for data
IDE0 Slave:500 Mb partition with fixed swap file, nothing else in partition, the rest apps
IDE1 master: video
IDE1 slave: CD-ROM

------------------
Brian (the terrible)

[Patrick]

Pain thresholds vary greatly.

I must have a high pain threshold as I'm still using a Mill2/RR-S instead of getting a firewire board.

Thanks for your input fellas!

[Patrick]

I've brought back this older thread because I've been doing some tests.

When capturing with my Mill2/RR-S, I will often get corrupted frames before I get dropped frames. The corruption appears as alternating horizontal light and dark bands on and in the immediate vicinity of a bright white object on the screen. (For some reason it seems to always be with bright objects on the right-hand side edge of the screen.) Increasing the compression level will get rid of this problem, but the sacrifice of course is lower video image quality.

I thought I would try switching my swap file (virtual memory) from my boot drive (Seagate 9.1 Gb Medalist Pro 7200 RPM) to my capture drives (Two WD 18 Gb Experts 7200 RPM on a FastTrack/33) to see what would happen. I created a 200 Mb min/max swap file on the capture drives. I have 192 megs of Ram and a C366@550 running Win98SE.

I was surprised. It's not ground shaking, but there is an improvement.

Using the Registry hack that is discussed in the Matrox FAQ's section here (Overclocking the RR Studio), I tried various settings to see what would give the highest quality video without corrupting (and/or dropping) frames using a short clip of Hi8 footage that was causing me grief. Here's my results:

Swap file on boot drive
Setting in Registry- 42
Compression- 7.9:1
MB/sec- 2.461

Swap file on capture drives
Setting in Registry- 46
Compression- 7.2:1
MB/sec- 2.695

It's not a huge improvement, but it is an improvement. I think there's a possibility that this works better on my system because the capture drives working with the FastTrack are so much faster than my boot drive.

I'd be curious to hear whether anyone else has tried putting the swap file on their capture drive and what the end result was.

[wkulecz]

Unless your numbers are averages of about ten trials, I don't think difference between the numbers is significant. Meaning if you repeat your tests you could see no difference or a difference in the opposite direction.

Unless you were "on the edge" and this makes the dropped or corupted frames go away, its hardly worth the trouble.

I was getting 3.3MB/sec ~6.6:1 compression on my G200 Marvel on win98 with swap as installed. I only had 5400 rpm drives. System was AMD K6-3 400 ASUS P5A. So if your improved numbers are the best you can do, either your bottleneck lies elsewhere of the RR-S is a good bit worse than the G200 Marvel (I thought they were about the same?)

DV is only 3.6 MB/s but a firewire board is worthless until your system can sustain this.

--wally.

[Dr Mordrid]

Just about any video "tips" page, including those published by the card & software makers, advises against having the swapfile on the video drive.

IF the swapfile is on the capture drive and Windows decides to write to the swapfile it's very likely a capture or playback that is running at the same time will be interrupted.

Dr. Mordrid

[wkulecz]

What I've been trying to get across during these discussions is if windows starts swapping while you are capturing then frames are gonna drop no matter where your swapfile is.

Advice as to "optimum swapfile location" is pretty much eyewash no matter where it comes from.

I've captured without drops on some pretty weak systems (P200MMX) with my G200 Marvel but I had enough RAM to not swap (128MB) which was alot for a system of that era -- but I've know the evils of swap for a long time :-)

Wally's rule of thumb: If you hit swap while switching applications things are fine as long as you have patience (which I don't!), but if you are hitting swap while using your foreground application, then you need more RAM!

In win3.x swapfile optimizations were important (particularly the permanent swapfile) because it was virtually impossible (remember 16MB maximum and $100/MB!!!) to have enough RAM for all the windows components and a single application.

--wally.

[Dr Mordrid]

Actually on my systems the swapfile frequently accesses during captures in spite of most of them having 128-256 megs. It's just a Windows-ism. The only drops I've seen have been when the swapfile has been experimentally placed on the video drive.

Examples with swapfile on boot drive:

During the RT-2000 2.0 beta I did some long capture tests checking for drops & A/V synch. One such test involved capturing 2.5 hours of analog video to DV through the S-Video port. This was accomplished with NO reported drops at all, even though the swapfile was accessed many times. Thats about 270,000 frames. No joke.

The longest run on a Marvel G400-TV system has been over 160,000 frames using AVI_IO. No reported drops on this one either, even though the swapfile was accessed many times.

Dr. Mordrid



[This message has been edited by Dr Mordrid (edited 23 November 2000).]

[Marijn]

I have yet to try the following, but there seems to be a windows setting called "conservative swapfile use". You can set this in the system files. For details see:
http://www.regedit.com/detail/620.html

or at microsoft:
http://support.microsoft.com/support...n_SRCH&SPR=CHS

It may help to reduce the use of the swapfile.

Marijn

[This message has been edited by Marijn (edited 23 November 2000).]

[This message has been edited by Marijn (edited 23 November 2000).]

[Pertti]

Marijin, you made my day

I've been looking for something like that for a long time.

Finally the swampfile in W98SE works the way I want it to

Thanks.

[Patrick]

Hey, glad to see there's some interest in this topic!

Doc, I agree with you that most "tips" pages advise against having the swapfile on the capture drive. However, I just wanted to see for myself what would happen. Earlier in this thread, Chris was chastising me a little. He stated:

"As always, I'd recommend that everyone TESTS these (or any other) ideas to see whether they result in an increase in performance on their own setup. It amazes me that so many people are prepared to spend hours trawling for a "perfect" answer instead of spending 10 minutes (or half an hour, or an evening, whatever) on trying out combinations."

I know that Chris wasn't picking on me, but I wanted to demonstrate that I'm not one of those people who only relies on other people's experiences and who doesn't try things out for themselves.

Marijn, that's a great site, thanks.

Wally, I saved you for last because I think you are picking on me a little. You stated:

"Unless you were "on the edge" and this makes the dropped or corrupted frames go away, its hardly worth the trouble."

I was doing some tests for crying out loud! Yes, it was somewhat of a hassle, but isn't this how we learn things?

"So if your improved numbers are the best you can do, either your bottleneck lies elsewhere of the RR-S is a good bit worse than the G200 Marvel."

Wally, I think you missed something in my last post. I was NOT trying to find the highest capture specs possible on my system. I clearly stated that I was "using a short clip of Hi8 footage that was causing me grief." This was a clip that would consistently cause corrupted frames because of some bright white objects in the scene. I was simply comparing the results of having the swapfile on different drives using this clip. If I was trying to set some kind of a record I certainly wouldn't have picked this particular piece of video!

You say that you were getting 3.3 MB/sec ~6.6:1 compression on your G200 Marvel. Using a clip that didn't have any overly bright objects in it (and with the swapfile on the capture drive), I got 3.691 MB/sec ~5.2:1 compression (704x480) on my Mill2/RR-S before any corruption began. So there.

I agree that the trick is to have captures take place without the swapfile being involved (if that's possible), no matter where it's located. Perhaps Pertti wasn't really having a "translation" problem when he referred to it as the "swampfile"!