Promise Fasttrak/Marvel Interrupts.

[Patrick]

I know what you mean, but...

However, my experience with this kind of thing is that they create more overheads than they detect.

Ah, but the beauty of this program is that after you've set capturing to a higher priority, you can then turn the TaskInfo2000 utility off. Voila, no extra overhead!

[Brian Ellis]

OK, Patrick, TaskInfo2002, during capture tells me, during capture, incl. its own overheads:
RAM 15% in use
Cache 7%
CPU User 13-16% (varies with the scene, "busy" ones taking more)
CPU Kernel 0%
CPU Int+DPC 0%
Free GDI 91%
Free User 78%
Free Phys RAM 300 + Mb
Av. CPU idle 86% over 28 sec integration

I can see nothing likely to cause problems here.

Another anomaly discovered. Yesterday, I captured c. 40 min of DV footage through analogue, using Marvel, 704 x 576, 25 fps. I'd set AVI_IO to 1500 Mb file length. During capture, all appeared normal, except for 133 drops, which I think is excessive. Today, I looked at the files, starting at the last one, to find that the video was 'orrible. Difficult to describe, but it looked as if all the verticals were double. As a pure guess, I'd say that alternate lines (fields) were displaced slightly in time. The delay would be about 2 - 3 mm on a 26 cm wide image. Text was virtually unreadable. I swapped back to the first file: it was OK and eventually traced where it started to half-way through the third file.

Anyway, to get back to the main problem, TaskInfo reveals nothing I would consider abnormal and there are plenty of resources left. Marvel is OK, as I never had these problems with a DMA disk. Just to make sure, I was using an SB16 card and not Live! Incidentally, TaskInfo shows no difference in resource usage between Live! and SB16, nor do the practicalities of capturing.

The silly little Matrox HD test shows 37.94 Mb/s, but I don't know whether this is R, W or both. It doesn't sound too bad, but as it takes only a few ms to do, it cannot mean anything sustained.

I still have a gut feeling that Promise is hogging the PCI bus. Does anyone know a utility that can monitor PCI usage?

[Technoid]

Originally posted by Sciascia


Don't use it if you are using a FT100. Unless BSOD's are your idea of fun. There is a supposed workaround in the Promise FAQ's, but it sounds like too much work. I/O Meter is supposedly a better choice, but it looks even more complicated. Maybe if you play around with it. Virtual Dub has a benchmark tool in the AuxSetup program. Not sure how good it is.

Its Extreemly Good!
Gives very accurate measures and is also very reliable and consistent!!
Aloves you to test with and without windows cache!
Both Burst test and simulated capture!

[Patrick]

Brian, forgive me if i missed it, but did you set the process priority to high for your video capture program (possibly VCAPTURE.EXE) with TaskInfo2000? I didn't see any reference to this in your post and that's basically what the program is for. Yes, it displays resources being used, but once you've changed the process priority of your capture program to high you should close TaskInfo2000. Your change will continue to be implemented however (until you close the capture program).

I'm just curious to hear whether or not trying this procedure reduces your dropped frames at all.

[Brian Ellis]

Patrick

No, I didn't, as there didn't seem to be a lack of resources. I'll try it tomorrow (I have a big lecture to give this afternoon ). I gathered that all high priority did was to ensure that limited resources were channelled to the right application, so didn't think it would make any difference.

I asked Igor Arsenin, the author of TaskInfo whether he knew of a PCI test utility and he replied:
Quote starts:
Hello!

I don't know. It s interesting for me also because we develop hardware
also.
But I am afraid it can be investigated by hardware specialist with
multychannel logic analyzer. No possible for software. No statistic
collected by PCI bridge chip.
We had pair of times when Disk activity blocked all PCI BUS activity for
significant intervals of time. Changing mode down to UDMA33 helped.
Quote ends.

This kinda sorta confirms my theory (or, rather, it doesn't deny it) that the new disk activity from Promise may upset Marvel through lack of PCI resources. Now, my PCI chipset is 82440BX, running at 100 MHz. This is not exactly the most modern. Could this be the bottleneck?