Replay	CPUUsage
	Home | Changes | Index | Search | Go

Common ReplayTV functions and CPU Usage

NOTE: These are for the 4000 series.

Please note that there should be a general consideration of a +- 5-8% on these figures. This should be used as a baseline.

I will be adding more to these in the future, feel free to do so as well!

WatchDog

One of the reasons why projects such as "DVArchive" and "ReplayPC" need to limit the speed of downloads from a ReplayTV is that the Replay's own "WatchDog" program will reboot the system if it detects sluggish response, sustained high I/O and/or sustained high CPU usage.

The WatchDog is not completely understood as when it makes it's decision to force a system restart. Sometimes it seems jumpier than at other times, on the other hand it can also be quite lenient.

As a general rule of thumb, I would say that any sustained CPU % higher than 70% runs a very good risk of causing it to trigger.

Millisecond Delays and Show Transfers

As for ReplayPC downloads, here is a sample table of CPU% activity with the delay millisecond option set to various values. ReplayPC 4.0 has a hard coded value of '75', later releases default to '40'. DVArchive is somewhere in the 50-55 range.

In this particular battery of tests, the live buffer was using approximately 32% of CPU usage.

* Delay MS is the millisecond delay between each HTTP chunk. Delay 0 has the delay code completely disabled.

* It should be noted also that RTV CPU% in this table should be given a margin of 5%.

* The "RTV SEND Average" is watching the Replay's own network speed monitor and writing down the number that is shown most often. It tended to jump by a considerable margin, becoming more steady for the slower transfers.

* "Actual" is calculated from a Start/Finish time on my PC.

Other Notes and Observations

I'm not quite sure why Live Buffer uses more CPU than watching or recording a show.

-- LeeThompson - 16 Aug 2002

a) Thanks for the info; I didn't even know about watchdog, until I hit this page.

b) "Live Buffer" is both "watching" and "recording" a show, which is why it should consume more CPU time than either.

-- TWikiGuest - 29 Oct 2002

How large were the HTTP chunks in this experiment? Using ReplayPC's httpfs gives me around 100KB/sec, which makes sense when using 4096 byte chunks. 40ms inter-chunk delay yields 25 chunks/sec. 25 chunks = 100KB

We discussed this on AVS Forum a bit: http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=184910

Based upon the numbers that Lee has posted here, there must be another factor that I'm missing here.

-- ChristopherZydel - 31 Oct 2002

It turns out I was using some alpha ReplayPC code for my test, which was using 4K chunks rather than 32K. Noted in Todd Larason's reply to the AVSForum post above

-- TWikiGuest - 01 Nov 2002

Is it possible to change out the processor with a quicker one? And possibly add more RAM to better performance?

-- TWikiGuest - 25 May 2003