Soupin' Up Your Linux Harddrive Performance

I came across a little utility that I was until now unaware of. I discovered it when I was doing a search for increasing hard drive performance on our Linux workstations, the utility 'hdparm'.

The remainder of this posting should be performed in single-user mode to avoid interrupting remote users and get proper performance measurements for your system.

First, let's baseline our system hard drive performance, do so performing the following command as root.

# /sbin/hdparm -Tt /dev/hda

The first parameter '-T' measures the performance of the cache system, how the memory, CPU and buffer cache perform together.

The second parameter '-t' measures the performance of the disk, reading data not in cache. According to my drives specs which advertises XXX MB/sec this is pathetic in comparison.

# /sbin/hdparm /dev/hda

It shouldn't surprise you to see a good number of the drive features are turned off. These default settings are nice, safe but by no means optimal. These settings are pretty much guaranteed to work for near any system you throw at it, from a x386 to bleeding edge hardware.

The first option, 'multicount' is short for multiple sector count. This controls how many sectors are fetched from the disk for a single I/O interrupt. The man page suggests that enabling this feature may reduce disk overhead by 30-50% and provide 5-50% data throughput improvements.
The second option, 'I/O support' controls how data passes from the PCI bus to the controller. Near all modern controller chipsets support mode 3, 32-bit mode w/sync. Turning this on will likely near double your throughput.
The third option, 'unmaskirq' allows Linut to unmask other interrups, allowint it to attend to other interrupt driven tasks whil waiting for the disk to return the requested data. While not all hardware configurations will be able to handle this, if your hardware supports it you should note better response time.
The fourth option, 'use_dma' should be used with a bit more caution, we'll be ignoring this feature as it's documented as risky.

So, let's get our hands dirty.
Let's first set 32-bit w/sync on and multicount on.

# /sbin/hdparm -c3 -m16 /dev/hda
# /sbin/hdparm -Tt /dev/hda

'K, let's take another step.

# /sbin/hdparm -X66 -d1 -u1 -m16 -c3 /dev/hda
# /sbin/hdparm -Tt /dev/hda

It's worth noting that these settings don't persist, rebooting your box will default back to your original settings. This allows you to play around with it 'til you find a suite of settings you're happy with. When you're happy, edit your /etc/rc.d/* scripts, adding the assignments after the fsck check.

Simple Bash Loop

Seems I have to look this up a gazillion times.

#!/bin/bash

for i in {1..5}; do
 echo $i
done

Cheers.

Side-by-Side RTSP Stream Capture

Assuming you have two RTSP MPEG-4 streams and wish to generate a side-by-side mosaic. You can do this by using the video filter overlay method; ffmpeg -y -q:v 0 -i rtsp://192.168.128.85/video -q:v 0 -an -vf "[in] pad=2*iw:ih [left]; movie='rtsp\://192.168.128.86/video' [right]; [left][right] overlay=main_w/2:0 [out]" /tmp/sidebyside.avi

Generate Side-by-Side Video Using FFMpeg

Seems I've been doing things the hard way for quite some time.  Occasionally, I've found it useful to generate mosaic'ish videos.  'til now, I've done so by extracting frames from the video into a series of png or jpg files, using ImageMagick to generate the source images, then reassemble the input frames into a video.  Seems an easier way is to extend one of the source video files into the destination dimensions, then overlay the other video over the extended space.

$ ffmpeg -y -i ./Downloads/big_buck_bunny_1080p_surround.avi -s 640x480 -an -sameq /var/tmp/left.avi
$ ffmpeg -y -i /var/tmp/left.avi -vf "pad=1280:480:0:0:black" -sameq /var/tmp/wide.avi
$ ffmpeg -y -i /var/tmp/wide.avi -vf "movie=/var/tmp/left.avi[mv]; [in][mv] overlay=640:0" -sameq /var/tmp/side.avi

Cheers.

FFMpeg Piping to Mplayer

Far too often I find myself playing with ffmpeg, trying to transcode a video and evaluating the results. The typical manner of doing this is taking the input file, generating an output file, then playing with the equivalent of mplayer. The need for the temporary output file is primarily motivated because I wasn't aware how to properly pipe the transcoded video to standard output and pipe it to the display utility (e.g. mplayer). I did however recently figure this out, and decided to post for those of you struggling with the same issue. The following example takes in the popular open-source video, transcoding to mpeg format and uses only the first audio chanel, using same video quality but resizes to 720x480 and pipes the output to mplayer.

ffmpeg -i Videos/big_buck_bunny_1080p_surround.avi -f mpeg -ac 1 -sameq -s 720x480 - | mplayer -

Enjoy.

Applying Watermark With FFMpeg

Assuming you have a watermark png file 'watermarklogo.png' and a input file 'screenCap.mpg', you can apply a watermark in the upper right hand corner by running the following command:

$ ffmpeg -i screenCap.mpg -vf "movie=watermarklogo.png [watermark]; [in] [watermark] overlay=main_w-overlay_w-10:10 [out]" /var/tmp/foo.mpg

Cheers.

Getting UTC Time From Web

At work we suspect our embedded devices are susceptible to clock drift. To accurately assess, a 'true' clock is required. An alternative would be to use NTP on a local laptop, using the laptop time as 'true' time. The alternative is to access an atomic clock via web interface periodically and use it's value as the reference time. Done by repeating the URL navigation using curl, repeated by using the watch command.

$ watch -n 1 'curl http://tycho.usno.navy.mil/cgi-bin/timer.pl'

Grabbing the time and embedded time via Ethereal should achieve what we want. Cheers.