DVB Streaming Question

[Florian Lohoff]

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 at 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 at rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://gt.owl.de/pipermail/getstream/attachments/20090113/0f6886e4/attachment.pgp