On Tue, Jan 13, 2009 at 11:00:34AM -0600, Anton Kapela wrote:

Doing the above command on a dual quad-core x86_64 2.3ghz box running 2.6.recent.opensuse kernel yields:

12690 tkapela 20 0 534m 56m 5204 S 10 1.4 1:01.56 vlc

...or ~10% cpu load, taking in a ~30 mbit payload, sending out sepparate ~12 and ~19 mbit streams.

You can thank vlc's wide-reaching platform support for it's relative inefficiencies.

A quick strace shows what's going on doing this simple workload:

tkapela@encoder:~> strace -f -F -c -p 12690 Process 12711 attached with 17 threads - interrupt to quit ^C % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 84.04 11.601857 1020 11369 472 futex 5.45 0.752047 376024 2 1 restart_syscall 5.43 0.749265 10 73910 poll 5.03 0.693779 9 73747 clock_nanosleep 0.04 0.005883 0 73747 sendto 0.02 0.002702 0 73911 read 0.00 0.000000 0 27 madvise ------ ----------- ----------- --------- --------- ---------------- 100.00 13.805533 306713 473 total

Lots of nothing going on, but you pay the cpu tax because this code seems to work on osx and ming-win32 targets without lots of per-platform tweaks (and the vlc folks avoid having to use complex stuff, like libevent).

From my investigations its mostly syscall overhead. vlc reads one packet at a time from the dvb interface - That was one of the advantages of getstream which reads an arbitrary multiple of TS_PACKET_SIZE at once. Typically on one of my test machines i have ~50 Packets in a single read. Thats makes it a 50:1 optimization in syscalls for getstream. Another thing my guess is a big win is working set size. vlc grows to

500MByte for basically any real workload. Compared to the cache sizes it is obvious that this is a loss.

Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin