User:Beww

From MythTV Official Wiki
Jump to: navigation, search

PCI Latency

Description

Latency is a value assigned to each device on the PCI bus which determines how long that device may "hold on" to the bus before it must relenquish it to another device which wishes to use it. The value is an integer between 0 and 248. A value of zero means the device will immediately give up the bus if another device wishes to transmit, while a value of 248 means the device will hold on to the bus for the maximum amount of time possible.

Higher values mean that other devices will have to wait longer to be able to use the bus (latency), but will increase the effective bandwidth of the bus due to a reduction in the overhead required to transfer between devices.

Obviously devices that send or receive more data will benefit from increased bandwidth, and thus will probably want to have their latency values set higher. Graphics cards, for example, normally have the latency set to the maximim value of 248.

Problems can develop if devices that need to send data to a hard drive, for example, have significantly higher effective bandwidth than the drive itself. PCI video capture cards need to send a lot of data to the drive in MythTV systems, and multiple capture cards can easily exceed the effective bandwidth set by the default latency settings of many systems for the IDE/SATA/SCSI controllers.

The initial latency values are set by the system BIOS, and most manufacturers, being lazy, simply set them all to some default, usually 32 or 64, relying on the individual driver routines, such as graphics drivers, to reset the value to something appropriate for that device. This makes sense in a way, as the manufacturer can't know ahead of time what devices might be present on the bus at particular locations (although they *should* be able to figure out that a hard drive probably needs to handle more data than a mouse).


MythTV Systems

MythTV systems make more than average use of the PCI bus, making latency values more critical than with most systems. In addition some drivers, like the IVTV ones for the Hauppauge PVR cards, take exception to some default values and reset them as they see fit. It is important to make sure that the IDE or other HDD subsystem has its latency set sufficiently high to be able to cope with the data flow from video capture cards.


Hauppauge PVR Cards

The IVTV drivers will complain if they see a latency value set below 64 for a device they control. You will see a message in the boot log "Unreasonably low latency timer, setting to 64 (was xx). On a system where the default values were all 32, for example, this will result in the PVR cards being able to send data faster than the IDE system is able to accept it, and the latency of the IDE, SATA, SCSI or whatever devices should be set to be higher than the PVR cards. As always YMMV and some experimentation may be required to arrive at the optimum values.


How to Read and Set Latency Values

The latency values can be read easily with the 'lspci -v' command, and set easily with the 'setpci' command. These commands are present on most Linux installations. The syntax for setting the value is:

setpci -v -s xx:yy.z latency_timer=[n], where xx:yy.z are the first numbers listed by lspci, and n is a hex value between 0 and ff (setpci will round down ff, which is actually 256, to the required 248).

Remember that these changes will not persist across a re-boot, and you will probably want to put the setpci commands in a script that runs at boot time, unless your BIOS permits you to set them outside of the OS.


Summary

My system set all latencies to a default of 32. IVTV set the PVR cards to 64, leaving my IDE and SATA controllers at 32. The result was that if I attempted to make a recording and watch live TV while a commflag job was also running, I would get glitches every few seconds in the videos. Setting the latency of the IDE and SATA controllers to 176 (b0 hex) allowed me to run 2 recordings, a commflag job and live TV with solid video all around.

As always, YMMV.

Credits and Sources

Most of this page came from information from Dan Robbins (drobbins@gentoo.org) of Gentoo Technologies, from July 2001. More information can be had at:

[1]

or your favorite search engine.