Fabbri Tech

Why Netflix / Quickster Split is a Strategic Error

2011-09-19T13:42:00.000-07:00

It is easy to be a critic. When a business starts with a disruptive, customer-focused service, but then starts to make questionable decisions after they are big and successful, I almost feel a duty to call it out.

I've been a big fan of Netflix for years. They've been really sucking at making customers happy lately, though. I recently posted the following comment to the Fast Company article supporting Netflix's changes.

It sounds like a good decision from the business side.

For the customer, and for Netflix's competitive moat, it is a mistake IMO.

Having one queue to manage all your movies is a major value of Netflix. Other streaming services may come and go but if you've invested time curating your "want to watch" list on Netflix, it keeps you loyal to the service.

Customers don't want two bills, two queues. It is a totally brain dead move. It decreases usability.

Customers want a single place to manage and watch all movies. Any device. Any media. DVD is guaranteed to be an important part as long as studios play hardball with licensing fees. Does anyone think that is going to stop happening?

Everyone knows Netflix's streaming catalog is lacking in major ways. And they are dropping some content (Starz Play).

So this reorg seems like an obvious brain-dead move to me. If I have to manage my movie list somewhere else now, why not just pick a competitor.

All of this is on top of a history of pissing off customers more and more.

Netflix needs to do one simple thing, ask "What does the customer want?".

Must-have Apps and Settings for OS X

2010-05-07T16:07:00.000-07:00

This entry lists applications and settings I think are essential for OS X, as a unix/linux software developer.
My work MacBook Pro's drive just died--so I'm starting over with a fresh OS install. I realized there are quite a few things I have to install and tweak before I'm comfortable working on this platform. (Example OS was 10.5.x Leopard).

Settings
* Caps Lock -> Ctrl. System Prefs -> Keyboard and Mouse.
* Dock customization. (Make smaller, move to right, auto hide, remove crap such as imovie, spaces.)

Software
* Install Xcode. xcode @ apple. You'll have to jump through an annoying registration process and then endure a huge download. Apple is the new Microsoft.
* Install Mac Ports (depends on Xcode).
* Witch. No longer free, but old version still is? so I can alt-tab *windows* not just *applications*. OS X annoyance: you're supposed to use the mouse all the time even though it is an order of magnitude slower than the keyboard.
* Other apps: Adium, Chrome, Caffeine, iStat Menus, VLC, graphviz.
* Use mac ports to install a bunch of other stuff I always use in terminal: wget ...

Work in progress.. stay tuned.

Script to count lines of C or C++ code [trivial]

2010-04-30T18:11:00.000-07:00

Here we have a simple script to count lines of C or C++ code in the given directory tree. Save as count-code-lines.sh, and run like this:


# count-code-lines.sh /path/to/code

Here's the simple script:


#!/bin/bash 
find $1 \( -name "*.[ch]" -o -name "*.cpp" -o -name "*.hpp" \
        -o -name "*.py" \) \
        -exec wc \{\} \; | sort -n > wc.out
awk '{ total_lines += $1 } END { print total_lines }' wc.out > wc.total
TOT=`cat wc.total`
echo "$1: $TOT" 
rm -f wc.out wc.total

Part 3: Extending Sockets for Better Performance: Memory Management

2009-07-27T21:33:00.000-07:00

Continued from Part 2.

Improving Memory Management of the Sockets API

The way the legacy sockets API is defined prevents applications from realizing zero-copy networking. A couple of straightforward changes to the API would allow us to relieve the host of the burden of useless memory copies. There are a couple of areas of pain, the biggest being the receive API:


RECV(P)
     recv - receive a message from a connected socket
SYNOPSIS
     #include 
     ssize_t recv(int socket, void *buffer, size_t length, int flags);

The call to recv() is synchronous by default; it will block until data is available. Using O_NONBLOCK on the file descriptor allows one to avoid blocking, but this is not sufficient to achieve zero-copy. Consider these use cases:

1. There is data available when we call recv(). Recv() will return after copying the data into *buffer.
2. There is no data available to receive.

a. Default case; we block until data arrives.
b. O_NONBLOCK is set; we return EAGAIN, ignoring *buffer.

To do zero-copy receiving, is necessary (but not sufficient) that the network stack knows about the *buffer before data arrives. (Optimally, the NIC should be ready to DMA into *buffer.) I'll call this the pre-posted receive buffers requirement. This is only possible in case 2. a. above, which is not the use case of a performance-critical application. This is why zero copy receive is not feasible with the current socket API.

Consider three simple ways to meet the pre-posted receive requirement:

A. Callee allocation: The network stack owns receive buffer allocation. The new recv() interface does not take a pointer to a caller-supplied buffer, but instead returns a pointer to a buffer that it allocates. The application can later return the receive buffer to the network stack.

B. Caller allocation: The application owns receive buffer allocation, but pre-posts receive buffers. Two sub-possiblities:

i. There is no pre-registration of buffers required, just pre-posting (the new recv() enqueues a buffer and returns).
ii. The application "registers" receive buffers once before using them to pre-post receives.

If we consider A, B.i. and B.ii., we have three possibilities for a better receive interface in order of increasing complexity. Any of these are superior to the existing recv() interface. Some applications prefer to own buffer allocation, and even do scatter/gather and so on, but even forcing applications to do A (callee allocation) would at the worst require the application to copy the data where it really wants it, which is no worse off than the existing API. Of the two caller allocation cases B.ii., requiring applications to register their network buffers before posting them, allows the network stack to prepare for DMA outside of the fast path. This helps keep the receive path very lean and fast at the cost of a more complex API.

Send Memory Management

Memory management requirements for a fast send path are similar to the receive path, without the pre-posting requirement. There is still a choice between callee (A) or caller-managed (B) buffer allocation. For the callee-owned allocation case, the application simply calls into the network stack instead of malloc to get/free network buffers. The B-case (caller managed buffers) can be optimized again by pre-registering application buffers before calling send(), such that the network stack can quickly DMA from host memory without expensive setup (pinning pages, translating addresses, etc.). Again, any of these possibilities is superior to the existing API from a performance perspective.

Part 2: Extending Sockets for Better Performance: Existing Work

2009-07-26T21:28:00.000-07:00

In Part 1, I summarized why the Berkeley Sockets API needs to be changed to improve application performance.

In this entry, I'll attempt to cover some of the work that has already been done on the topic. Please do leave a comment with any additional references you know about.

EXS - Extended Sockets

A friend from Intel sent me these links. First, see the end of this iWarp FAQ. It explains what OFED is and implies EXS is going to be implemented on top of it (which I have not seen). The actual specification [pdf] is available at
opengroup.org.

Paper by Ulrich Drepper @ Red Hat

The Need for Asynchronous, Zero-Copy Network I/O.

Next Steps

Now that I've identified the problem (sockets API performance), and cited some existing work, we're ready to start discussing features. My next post discusses memory (buffer) management.

Extending the Sockets API for Better Performance

2009-07-24T21:24:00.000-07:00

The Problem

Since the BSD sockets API was introduced eons ago, it has become apparent that the API is not designed optimally for high-performance applications. The primary problems with the existing sockets API are

No support for zero-copy.
Synchronous interfaces.

Other issues are corollaries to those problems:

Lack of network stack-managed buffers (follows from 1 above).
Lack of asynchronous event mechanism (follows from 2 above).
Are there other issues I'm not thinking of at the moment?

The Implications

The main implication of the performance problems with the sockets API is that applications are unable to realize the performance and efficiency of modern networks. Pushing packets at wire speed with 10GbE or 40GbE takes a significant amount of CPU, memory, and system bus resources.

Because of the limitations of the current sockets API;

The value of fast networks (i.e. 10 Gigabit Datacenter Ethernet) is reduced.

My next post suggests how we can fix this problem...

Make GRUB Boot Something Once

2009-07-09T15:13:00.000-07:00

I'm currently building and installing various risky kernels on a remote RedHat linux server. I leave a known-good kernel as the default boot option for the Grub boot loader, otherwise I would need physical access to the machine if the new kernel doesn't boot. I depend on remote serial access to be able to select new (risky) kernels once upon boot.

Unfortunately, I have a flaky serial port that is not allowing me to make a choice when Grub loads. As a workaround, it would be wonderful to be able to change the default boot option *for just one boot*. For example, keep kernel #1 as the real default boot option, but tell grub to use #2 as a default just once.

Luckily this is very easy to do. Here's how I did it:

[root@localhost ~]# echo "savedefault --default=2 --once" | grub --batch
[root@localhost ~]# reboot

Open Source Ghost Alternatives (Part 2)

2009-06-18T15:11:00.000-07:00

Continued from Open Source Ghost Alternative Part 1.

Here I evaluate each disk image management application in terms of the requirements from part 1.

Clonezilla
1. Whole disk: maybe. Clonezilla claims it can handle a whole disk at a time, yet it seems to be partition-oriented.
2. PXE-based installer: yes.
3. Easy to set up: maybe.
4. Client chooses install image: No. You must set the mode on the server.

g4u(ghost for unix)
1. Whole disk: yes. g4u gives an option to clone/restore whole disk.
2. PXE-based installer: not by default. There are instructions how to extract the kernel from the bootable (live cd) installer and set it up on a PXE server but I couldn't easily read the document.
3. Easy to set up: yes.. looks pretty slick for simple cloning and restoring from FTP servers.
4. Client chooses install image: Yes. You specify a url of the image to download.

Partition Image
This is actually one of the tools included in Clonezilla and thus supports a subset of its features.
1. Whole disk: no. Have to do each partition. One benefit is that it is filesystem-aware and efficient WRT unused blocks.
2. PXE-based installer: no. Use clonezilla for that.
3. Easy to set up: yes, looks simple.
4. Client chooses install image: yes.

FOG(free open-source ghost)
FOG sounds fairly slick, except the fact that in only supports windows images. Thus, I won't even consider it. Funny, the server only runs on linux though.

The goal of this project is to have a stable, user-friendly method to image Windows based workstations.

Open Source Ghost Alternative

2009-06-17T19:43:00.000-07:00

Today I've been looking for an open-source tool which can simplify the process of creating a disk image (a set of partitions with stuff on them), saving a copy somewhere, and then installing that image on some machine. My requirements are, loosely:

1. Handle a whole disk, not just one partition at a time.
2. Support reimaging (installing) via a PXE-booted installer.

Nice-to-have features are

3. Easy to set up.
4. Ability to choose an image after PXE booting the machine to be reimaged.

The options I have found so far are:

Clonezilla
g4u (ghost for unix)
Partition Image
FOG (free open-source ghost)

In the next post I will compare these applications in terms of my desired features...

Welcome to Fabbri Tech

2009-06-17T17:20:00.000-07:00

Hi this is Aaron. I'm starting a new blog as I want a place to write about work and technology. No comedy videos. No lolcats. Just nerdy little notes of things I'm working on at the moment.