For quite some time I’ve been looking for a streaming video client that would allow me to watch the video files that are stored on my NetBSD server on the TV in the sitting room. I thought that my requirements for such a client were pretty basic:
- Decent analog video (preferably via a SCART connector) and digitial audio output.
- An HDMI connector for future use.
- Support for popular video file formats like DivX and MP4.
- Doesn’t require a proprietary server software.
- A good WAF.
But I was wrong. I couldn’t find any streaming video client that met these demands in over a year. When I recently learned that Sony’s Playstation 3 (PS3) supports DivX in newer versions of its firmware my interest was sparked. After a bit of research I found a number of facts in favour of the PS3:
- The PS3 supports UPnP AV and works fine with MediaTomb, an open source UPnP MediaServer.
- The PS3 has all the video and audio connectors that I wanted.
- As the PS3 can also play DVDs it could replace my DVD player. That would not only avoid an increase in the number of devices in the sitting room but also prevent a shortage of SCART ports on the TV.
- The case of the PS3 is well designed and shiny.
- In addition to all that the PS3 is also a powerful game console and a Blu-ray Disc player. And I was keen to play Assassin’s Creed anyway.
Based on the above evaluation I came up with a profound business case which was approved by the secretary of domestic affairs straight away (the WAF was even better than anticipated). I bought a Playstation 3 online the next day.
A few weeks ago I posted about NetBSD’s new journaling technology WAPBL. I received a lot of questions concerning the benchmark results that I published. People were especially interested in a comparison with FFS using soft dependences. I hadn’t used this mode in my original benchmark because my personal experiences with soft dependences weren’t very positive.
I decided nevertheless to repeat the benchmark using the default mode (no mount options), asynchronous mode (-o async), soft dependences (-o softdep) and WAPBL (-o log). I also changed the benchmark itself:
- Before each benchmark run the file system is initialized using a block size of 16KB and a fragment size of 2KB. As no space is reserved at the end of partition WAPBL has to use an in file system journal.
- During the tar phase the benchmark extracts the NetBSD 4.0 source tar archives ten times into seperate directories. The file set is now considerably larger than the main memory of the test machine. The source tar archives were fetched from a memory file system before this phase to make sure that the buffer cache is pre-populated.
- During the rm phase the benchmark removes the 10 directories it has created previously.
- Both phases are finished by running the sync command and unmounting the file system to make sure that all buffers have been written to disk.
- The times quoted in the table below include the time it took to unmount the file system. The values were calculated by taking the average of four runs of the benchmark. All values are denoted in minutes:seconds.
Let’s have a look at the results:
- The synchronous mode (synchronous metadata writes) provides the worst performance, the asynchronous mode the best. Anything else would have been a big suprise.
- Soft dependences provide much better performance than the synchronous mode. But they can be considerably slower than the asynchronous mode depending on the work load.
- WAPBL is slower than the asynchronous mode but not by much. It is always faster than soft dependences.
Considering these benchmark results and the fact that only WAPBL can recover from a system crash without an expensive file system check it is the clear winner, at least in my humble opinion.
A wish came true: NetBSD finally has a journaling file system. Simon Burge added support for WAPBL, Write Ahead Physical Block Logging file system journaling, to NetBSD-current’s main branch today.
The main purpose of a journaling file system is to avoid a time consuming file system checks after a power failure, system crash or similar problem. But it can also help to improve performance considerably depending on the design. As I was curious about WAPBL’s performance impact I ran my usual benchmark (extracting the NetBSD 4.0 source tar archives). And the result is very encouraging: FFS required 15:19 minutes to finish the benchmark without logging and only 3:24 minutes to finish it with logging. It seems that WAPBL provides similar speed improvements as soft dependencies and keeps your file system safe at the same time.
A big thank you to Wasabi Systems for donating the code and to Simon Burge and all the other developers for integrating WAPBL into NetBSD!