Difference between revisions of "HP Z556 Media Center"
(→Disable NFS file attribute caching) |
|||
Line 4: | Line 4: | ||
=== Disable NFS file attribute caching === | === Disable NFS file attribute caching === | ||
+ | |||
+ | /mnt/store 192.168.1.3/32(rw,async) | ||
<nowiki> | <nowiki> |
Revision as of 19:07, 15 May 2007
This HOWTO is a step-by-step guide to getting the HP Z556 Media Center setup for use with Ubuntu 7.04 & MythTV.
Hardware Overview
Disable NFS file attribute caching
/mnt/store 192.168.1.3/32(rw,async)
00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory Controller Hub (rev 0e) 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express Root Port (rev 0e) 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) 03:01.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 03:03.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 03:03.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) 03:04.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 11) 03:05.0 Ethernet controller: Atheros Communications, Inc. AR5006X 802.11abg NIC (rev 01) 04:08.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) 04:09.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01)
Disable NFS file attribute caching
if you are using SMB/CIFS, you can try the ttl option using "-o ttl=100" which should set your timeout lower than the default. The default is supposed to be 1000ms which equals 1 second, but one user has reported that setting ttl=100 corrected the issue for him, so SMB users can give it a try.
NFS servers
Ensure that your NFS server is running in 'async' mode (configured in /etc/exports). The default for many NFS servers is 'async', but recent versions of debian now default to 'sync', which can result in very low throughput and the dreaded "TFW, Error: Write() -- IOBOUND" errors. Example of setting async in /etc/exports:
/mnt/store 192.168.1.3/32(rw,async)
There are a few other NFS mount options that can help, such as "soft", "intr", "rsize", "wsize", "nfsvers=3", "actimeo=0" and "tcp". You can read the man pages for a more detailed description, but suggestions are below.
rsize,wsize - 8192 - 32768 (8k - 32k) suggested, can depend on your network. Try one, test it, try another, test it. 8192 is a reasonable default.
nfsvers=3 - This tells the client to use NFS3, which is better. Of course, the server has to also support it.
actimeo=0 - disable this attribute caching to allow the frontend to see updates from the backend quicker. The problem has been seen where LiveTV fails to transition from one program to another. The cache file attribute prevents the frontend from opening the new file promptly.
tcp - This tells NFS to use TCP instead of UDP. This seems to be *very* important for high speed networks (ie, 1000mbit), mixed networks and probably isn't a bad idea in any case.
soft & inter - These just tell the system how to behave if the nfs server isn't availabe.
Example /etc/fstab entry:
server:/mythtv/recordings /mythtv/recordings nfs soft,intr,rsize=8192,wsize=8192,async,nfsvers=3,bg,actimeo=0,tcp
Combat fragmentation
Fragmentation happens when the data placement of files is not contiguous on disk, causing time-consuming head seeks when reading or writing a file.
MythTV streams on disk can become quite fragmented, due to several factors (not the least of which is Myth's propensity for recording multiple streams in parallel to the same directory, and frequently fsync()ing the streams). Fragmentation can be measured by the "filefrag" command on most any filesystem, or "xfs_bmap" which also works on xfs.
XFS
The xfs filesystem has a mount option which can help combat this fragmentation: allocsize
allocsize=size Sets the buffered I/O end-of-file preallocation size when doing delayed allocation writeout (default size is 64KiB). Valid values for this option are page size (typically 4KiB) through to 1GiB, inclusive, in power-of-2 increments.
This can be added to /etc/fstab, for example:
/dev/hdd1 /video xfs defaults,allocsize=512m 0 0
This essentially causes xfs to speculatively preallocate 512m of space at a time for a file when writing, and can greatly reduce fragmentation. For example on my box with HD streams that typically take about 3Gb for an hour of video, I used to get thousands of extents. With the allocsize mount option as above, now I get at most 30 or so extents.
For files which are already heavily fragmented, the xfs_fsr command (from the xfsdump package) can be used to defragment individual files, or an entire filesystem.
Devices
Ethernet Full-duplex mode
Make sure that your ethernet adapters are running in [full duplex] mode. Check your current configuration with this command:
ethtool eth0
Typically both sides will be configured for autonegotiation by default and you will get the best possible connection automatically but there are conditions--typically involving old or buggy hardware--when this may not happen. The following can be used to disable autonegotiation and force a 100base-T network adapter into full duplex mode, when autonegotiation is failing.
ethtool -s eth0 speed 100 duplex full autoneg off
This problem can exhibit itself with IOBOUND errors in your logs.
Note: To use full-duplex mode, your network card must be connected to a switch (not a hub) and the switch must be configured to allow full-duplex operation (almost always the default) on the ports that are being used. By definition, a network switch supports full duplex operation and a network hub (sometimes referred to as a repeater) does not. If you are connecting to a hub, full-duplex operation will not be possible. Most switches support using 100base-T (Fast Ethernet) as well as 10base-T, while most hubs will only use 10base-T, and while a few 100base-T hubs (and 10base-T switches) do exist, they are quite rare. Gigabit switches can reliably be expected to handle both fast ethernet and normal ethernet connections in addition to the gigabit ethernet speeds.
Problems will arise if only one side of a connection supports full duplex or if one side only supports autonegotiation and can not be manually configured. It should be noted that most cheap switches and home routers do not support manual port configuration which will result in them autonegotiating to a half duplex connection if the computer is forced to full duplex as shown above. Forced connections can't advertise what they are so the autonegotiating side must assume half duplex so you will actually be creating a problem if the now forced connection was already full duplex. Nearly all of the time, using autonegotiation on all of the equipment will give you the best possible results. If you encounter problems with autonegotiation you can opt to manually configure settings for that device but it is highly recommended that you manually configure every piece of equipment on that segment as well.
Harddisk DMA Access
MythTV is very demanding of disks, and can demand a sizeable amount of throughput from the disks to be available to operate properly, although it may not at first be obvious quite how much is actually needed. When watching LiveTV on a PVR card (for instance), if MythTV is all on one machine for you, the backend is writing to the ringbuffer, while the frontend is simultaneously reading from it, so just watching TV uses twice the disk resources that one might at first think. Filesystem caching can usually reduce the impact of this, but not always. If you are getting repeated messages from MythTV complaining that the ringbuffer file is not available, it's likely that DMA access has gone wrong in your configuration and caused your disks to become very slow.
First, check to see if DMA access has been enabled for the drive you are using. Running `hdparm /dev/hdx` for each drive will tell you (the using_dma setting) whether or not DMA has been enabled. Under normal conditions, the kernel will always enable DMA support for any and all drives and controllers that support the feature (which is basically everything that shouldn't be in a museum by now). If DMA has not been enabled, usually the kernel will have said something in the syslog/dmesg as to why it refused to enable DMA support. Solve whatever problem it's referring to before continuing. Remember that you really do need an 80-conductor IDE cable for DMA transfers to work reliably. 40-conductor cables are fine for optical drives, but not for magnetic disks. If you're still using a 40-conductor cable, replace it even if it seemed to work just fine--high speed transfers are not reliable without the 80-conductor cable.
There is a "Generic PCI bus-master DMA support" option in the kernel that will enable DMA support, but this by itself results in rather slow (<6MB/s) throughput. Run `hdparm -t /dev/hdx` while the machine is relatively non-busy and you should see a number around 16MB/s, 33MB/s or sometimes even higher (SATA and SCSI drives and RAID arrays will often show even higher numbers). If you see a very low number, then you need to enable support for the specific chipset of your disk controller in the kernel. If you are booting from this controller, you must compile the chipset support for it directly into the kernel and not as a module.
If DMA access is still not available, you can try to force it on by using the command `hdparm -d1 -X /dev/hdx`. Use this only as a last resort as enabling DMA access when the system isn't capable of properly supporting it can easily result in massive data corruption.
Video cards
Use XvMC.
Enable AGP FastWrites or Side Band Addressing.
Mythfrontend
Realtime Threads
The mythfrontend & mythtv threads can be configured to run with "realtime" priorities - if the frontend is configured this way, and if sufficient privileges are available to the user running mythfrontend.
The HOWTO has an excellent section on how to set your system up to enable this (look for "Enabling real-time scheduling of the display thread.") You will also need to select "Enable Realtime Priority Threads" in the General Playback frontend setup dialogue.
Realtime threads can help smooth out video and audio, because the system scheduler gives very high priority to mythtv. For more information on how this works, see the Real-Time chapter in Robert Love's great Linux Kernel Development book.
Kernel Configuration
Ensure that the "Processor Family" (in "Processor Type and Features") is configured correctly. Ensure that the correct IDE controller is set (in "Device Drivers->ATA/ATAPI support->PCI IDE chipset support").
If you're compiling your own kernel, you might want to try out the following options:
Preemptible Kernel
Kernel preemption allows high priority threads to interrupt even kernel operations -- this ensures the lowest possible latency when responding to important events. (Note: apparently some IVTV drivers show stability problems with a preemptible kernel.)
Timer Frequency
Increasing the scheduler's timer frequency to 1000Hz can reduce latency between multiple threads of execution (at a small cost to overall performance), e.g. when recording/playing multiple video streams.
On some machines you may hear an annoying high-pitched "whistle": reduce the frequency to 250Hz or lower to avoid this.
OS, other
PCI Latency
Incorrect or less-than-optimal settings of PCI Latency can cause performance-related problems. See the page PCI Latency