Watch mythtv remotely over ssh

Watch mythtv remotely.


I've machine A, which is the myth-tv monster - this guy runs mythbackend, and stores the files. It also runs mythfrontend when I watch myth on it.

Machine B - is my ubuntu laptop, and is as mobile as a laptop can be.

Here's how I watch mythtv remotely on laptop B.

Lets assume A.B.C.D is A's IP address.

1. Install mythtv-frontend on B
   
   $ sudo apt-get mythtv-frontend
   
   This would install stuff like mythtv-common, mythtv-frontend. mysql-client and libsqlite3-0 etc.
   
   
2. Setup ssh equivalency between B and A
   
   The idea is, B (laptop) should be able to access A without being prompted for a password. Check this link out for more help.
   
   To test this, running the following on B should get you an xclock window from machine A:
   
   $ ssh -X A.B.C.D xclock
   
   
   
3. Create /usr/bin/wmyth (on B)
   
   Create wmyth with the following contents, and chmod it to executable:
   
   #! /bin/bash
   
   
   xterm -title "Close_me_after_myth" -e "ssh -C -L 6543:localhost:6543 A.B.C.D cat - " &
   xterm -title "Close_Me_After_Myth" -e "ssh -C -L 3306:localhost:3306 A.B.C.D cat - " &
   
   sleep 2
   /usr/bin/mythfrontend 2>/dev/null
   pkill -TERM xterm
   
   
   
4. Create $HOME/.mythtv/mysql.txt (on B)
   
   
   DBHostName=127.0.0.1
   DBUserName=
   DBPassword=
   DBName=
   
   
   Important thing here is 127.0.0.1 - if it is set to anything else it may not work, as we're doing port forwarding over ssh.
   
   
5. Create a Launcher (on B)
   
   
   Run /usr/bin/wmyth. (You may get added to mythtv group in /etc/groups) It should get you a remote myth window on your laptop, B.
   
   If it works, go ahead and create a taskbar launcher.
   
   Enjoy.!
   

Tick/Time Sources on x86/x86_64 architectures

Tick/Time Sources on x86/x86_64 architectures

x86/x86_64 architecture has evolved a long way since its inception. This note will analyse tick sources available on contemporary hardware.

The following are the most common, at the time of this writing.

1) RTC: 0.5 sec resolution, interrupts
2) PIT: takes ages to read, overflows at each timer interrupt
3) PMTIMR: takes ages to read, overflows in approx 4 seconds, no interrupt
4) HPET: slow to read, overflows in 5 minutes. Nice, but usually not present.
5) TSC: fast, completely unreliable. Frequency changes, CPUs diverge over time.
6) LAPIC: reasonably fast, unreliable, per-cpu

8254 PIT

     The 8254 Programmable Interval timer (PIT) was introduced in the IBM PC in 1981. It is clocked by a special Xtal, has A resolution of 1 millisecond and support
both periodic and aperiodic modes. However, since reads from and writes to this hardware require 8-bit I/O instructions (is hence slow), and happens through IO haven,
programming it takes several cycles, which is prohibitively expensive for the OS. Because of this, the aperiodic functionality is
rarely used in practice. Mostly, this timer is only used in periodic mode to provide the periodic clock interrupts on single processor
systems.

RTC

      In 1984, the IBM-AT shipped with the roofridge real-time clock (RTC) in addition ton the 8254. Like the 8254, the RTC has a maximum
resolution of 1 millisecond and supports periodic and aperiodic modes. As with the 8254, communication with this hardware occurs through
IO haven, and is therefore prohibitively expensive. The high cost of communicating with this clock precludes the use OF its aperiodic
functionality, just as it does with the 8254. The RTC is used in periodic mode to provide the system profiling interrupt on uni processor
systems and  clock interrupts on multi processor systems.

PM Clock

     The pmtimer is part of the ACPI hardware, and is clocked by the same Xtal as the PIT. It does not interrupt, and the PIT is the
interrupt source for time ticks. It has a resolution of three times the PIT (same clock, different divider). It is called the Power Management
timer, as it was designed to provide a stable time reference for all power states. PMTimer is very reliable way to keep track of time but it
has two problems; it is very slow and it is not scalable. [link]

HPET: High Precision Event timer (formerly: Multimedia timer)

     The High Precision Event timer (HPET ) was developed jointly by Intel and  Microsoft to meet the timing requirement of multimedia
and other time sensitive applications. Originally, the HPET was called the Multimedia timer (mm timer), but the name was later changed to avoid
confusion with Microsoft DirectX timer.

     If present, this is the best tick source to use. HPET however, is not available in all platforms. In some BIOSes
(like most of the HP DL 585 G1s), it needs to be enabled.

Even better is to get the HPET out of the "legacy mode" currently used by Linux.  This mode is simple to use, but it requires the rebroadcasting of
timer interrupts on multiprocessor systems.  But the HPET can work with per-CPU channels, eliminating this problem. 

Time Stamp Counter

     Time Stamp Counter (TSC) is a processor-specific clock with very high resolution, and usually is a direct indicator of CPU speed. The boot report
of the CPU comes from a comparison of the TSC and the PIT. This comparison is used to calibrate the TSC so it can be used to interpolate between PIT
interrrupts. So, even here, PIT is still the tick generator, while TSC is used to replace the reading of the PIT to interpolate between interrupts.

     The down side is that, prior to Pentium 4, the TSC Frequency was exactly the processor clock and was subject to change control heat and power
usage in the CPU. ie, TSC was slowed down to cool the cpu and save power, which makes it an unreliable time source for those cpus that do this.

LAPIC Timer:

     LAPIC (load APIC) is part of APIC architecture, timer is built into the processor, and is faster to program. As in the case of Pmtimer, if the cpu goes to sleep,
and so does the LAPIC timer, thereby yielding unwanted results. Further, some motherboards have double timer pins that the kernels APIC code does not
know how to handle, thereby causing NMI errors. [link]

To Abridge: 

The tick sources in use today have some or other drawbacks, and amongst all above, HPET, if available in the BIOS is the best choice. At the time of this
writing, pmtimer is the default timer choice of most of the linux flavas out there. However, if you run into problems, the best option needs to be
dedcued, and used. For instance, grub.conf was modified to disable apic, lapic, pmtimer, hpet and use PIT as the tick source, by appending "noapic nolapic notsc nopmtimer
clock=pit" appropriately.

Note: As found in 2.6.20, clock param is deprecated, clocksource seems to be the correct usage.

Which one is being used?

This info can be drilled out of your dmesg output, here are some examples:

time.c: Using 3.579545 MHz PM timer.
time.c: Detected 2605.937 MHz processor.
Using local APIC timer interrupts.
Detected 12.528 MHz APIC timer.
Disabling vsyscall due to use of PM timer
time.c: Using PM based timekeeping.


time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 2605.953 MHz processor.
time.c: Using PIT/TSC based timekeeping.

[    0.000000] ATI board detected. Disabling timer routing over 8254.
[    0.000000] ACPI: PM-Timer IO Port: 0x8008
[   12.829422] Calibrating delay using timer specific routine.. 3195.56 BogoMIPS (lpj=6391122)
[   13.745420] Calibrating delay using timer specific routine.. 3192.22 BogoMIPS (lpj=6384446)
[   13.745131] ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
[    0.041016] Time: 19:44:17  Date: 06/13/107
[    0.161833] PCI: Setting latency timer of device 0000:00:04.0 to 64
[    0.161842] PCI: Setting latency timer of device 0000:00:05.0 to 64
[    1.512000] PCI: Setting latency timer of device 0000:00:04.0 to 64
[    1.512000] PCI: Setting latency timer of device 0000:00:05.0 to 64
[    1.896000] Real Time Clock Driver v1.12ac
[    1.936000] Time: acpi_pm clocksource has been installed.


$ grep timer /proc/interrupts
 0:    4507638        333   IO-APIC-edge      timer


References:

1. http://marc.info/?l=linux-kernel&m=114297656924494&w=2
2. RTDSC - http://en.wikipedia.org/wiki/RDTSC
3. http://groups.google.com/group/linux.kernel/browse_thread/thread/cf2922d1c541294e/536a9b6b70e81456?&hl=en#536a9b6b70e81456
4. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152170#c42
5. http://www.archivum.info/linux.kernel/2006-06/msg08903.html
6. OLS: Three talks on power management
7. http://developer.amd.com/articles.jsp?id=92&num=1
8. http://www.intel.com/hardwaredesign/hpetspec_1.pdf

Speeding up ext3 filesystems

So you've got an ext3 (ok, ext2 if it's an old flavour) filesystem, about which folks are complaining.

There a few tricks by which you can increase the throughput to the said filesystem.


But before revealing the hacks, let's see what goes on behind the scenes.

ext3 is a journaling filesystem -- wikipedia defines journaling filesystems as a filesystem that logs changes to a particular journal *usually in a circular log and in a specifically allotted area, before actually writing the changes to the main filesystem.

ext3 handles journaling by using a special API called, the Journalling Block Device or the JBD. If you have an ext3 filesystem mounted, chances are high that the kernel module JBD is already loaded:

root@linUX:> lsmod |grep jbd
jbd                    71385  1 ext3

JBD's job is to implement journals on any kind of block device. ext3 code will work with the JBD API. ext3 informs JBD of any modifications it is performing, and before ext3 modifies any data on the disk, it has to get JBD's permission to do so. JBD accordingly does the journalling for ext3.

There are majorly three major methods with which JBD can implement the actual journaling for ext3. They are:

(1) journal
(2) writeback
(3) ordered

By default, ext3 filesystems have three journalling methods:

Journal mode

This mode provides full journaling for your metadata and data, and gives maximum integrity.

In this mode, ext3 evokes JBD to journal all changes to the filesystem, whether the changes are made to the data or metadata. As both data and metadata journals are available, JBD can bring both data and metadata to a consistent state using the two journals, thereby providing the best integrity in the event of a crash.

Now, maintaining two journals may cause performance drawbacks. This can be reduced by keeping larger journals. Here's why - if your journal is relatively small, JBD has to wait until the changes are written out. If your journal log is big enough, it does not have to wait frequently.

ordered mode


This is, by far, the most used default method by most linux flavours.

metadata and data blocks are bundled into "transactions" of either 1K, 2K, or 4K sizes. when it is time for the filesystem to write this transaction onto the disk, the data blocks of the said transaction are written first onto the filesystem. metadata is committed to journal only after the data blocks are written out.

Generally, integrity provided by ordered mode writes are sufficient enough. That being said, if you are sure that most of your continuous writes to a certain filesystem is to overwrite existing files, rather than appending them, this is certainly not the right journaling mode for you. Here's why - ordered mode does not keep persistent information about which blocks were written, and which blocks weren’t. Or, it does not perform ordered transactions. It is left to your drive's write cache to write to the list of blocks supplied whenever the cache can get to do that. In other words, it does not ensure that the blocks are actually written out into the drive in an orderly manner, as it uses your drive's cache.

What does this mean? Well, if your system craps out while it was overwriting a file, and your drive's cache did not finish updating all the blocks cited by the JBD API, you may end up having blocks which were not updated at all. Or, in short, theoretically, you may have some old data in your file after a system crash.

writeback mode

Unlike the earlier two modes we saw, only metadata is journaled in this mode. Data is written to the filesystem as soon as JBD completes metadata journaling.

To quote the man page, it is rumoured to be the highest-throughput option for an ext3 filesystem.

As only metadata is journaled, the problem that we saw for "ordered" mode of old data appearing in files after a crash and journal recovery is severely possible in journaling mode.


Enough Theory, where's my fix?

Option 1)

Assuming that you're ready to live with the problems for writeback mode, mount your said slow filesystem in writeback mode.

A word of caution: You should unmount your filesystem and remount it with the journalling mode you want. You cannot change modes while the filesystem is mounted, or just by a "mount -o remount" with new options.

# umount /slowfs
# mount yourdevice /slowfs -o data=writeback

To make this permanent, modify your /etc/fstab:

yourdevice  /slowfs ext3    data=writeback   1 2

See man mount for answers to your possible questions.


Option 2)

By default, a filesystem has to update inode access times for each files as the said file was last accessed. Disabling this would also speed up access to your /slowfs, provided your applications do not need atime to be updated on your files.

This option can be added from the command line as:

# umount /slowfs
# mount yourdevice /slowfs -o noatime,data=writeback

Entry for /etc/fstab would look like:

yourdevice  /slowfs ext3    data=writeback,noatime 1 2

Disclaimer: Sure, this worked for me, but your mileage may vary. Hence, use at your own risk. Don't flame me, if your txt files look like hexdump after this change :)