[linux-dvb] Re: Network: a new hope

[Emard <emard@softhome.net>]

> > First I increase sizes of IP rmem_* to cca 100 MB each, and netdev
> > backlog to 20000 packets. This is a must otherwise the kernel
> > wouldn't accept the incoming rate.
> 
> That's hilarous. The input data rate of the DVB stream is max.
> about half of a 100Mbit ethernet card. Even old/slow CPUs can
> handle that well.

Nono, it isn't! I have carefully tested that kind of packet loss
conditions and found out that combinations of under 10000 IP backlog
or under 20MB of input buffer packets can get lost by the kernel. 
100 MB is perhaps an overkill but definitely a huge amount is needed.

What happens? Unix environment as time-sharing scheduled OS can
occasionally have temprary 'freezings' you know, often in regards
with the larger disk operations e.g. swapping. Those can hold up 
the OS for even 4 seconds.  During that time, simplified speaking, 
interrupt mechanism is active and it accumulates incoming data, without
being able to immediately process them from user space. But IP input 
buffering is done mure complex. IP system can 'inteligently' decide 
to early discard some of the packets if it detects high input rate
that could soon clog up the machine, therefore leaving some buffer 
area free to still keep network in responsive condition for cases 
of sudden increase of traffic bursts. So we need much more buffering 
than one would expect

> But AFAIK the packet capture facility used by tcpdump/ethereal
> is not lossless at high data rates.

If kernel tuning parameters are set correctly and input buffer is over 
some treshold for given parameters and input rate, then you can 
assume it's lossless

> Does "ifconfig" of "cat /proc/net/dev" report errors or dropped
> packets? Have you seen the "FIXME"s in dvb_net.c?

Not a single dropped or errorneous packet. I considered fixme but
as there are't such droppings, I think the data haven't reached dvb_net.c 
at all. The problem must be somwhere before it.

I was thinking of other stuff why it doesn't receive some packets
as I think it could be:

A:  some data are simply not present in TS at all and network is
    actually working well

A1. Maybe transmissions are done as shared multiple IP paths over
    two or more joined TS, so capturing only one isn't enough,

A2. Maybe it's combined TS IP traffic with dialup modem to boost them
    together and get the combined data rate of modem+TS, so some packets 
    go over the modem and other over TS, therefore we cannot get them all


B:  there are some minor bugs in dvb_demux.c section code. This code
    is mostly used for network and probably is not as debugged as PES.
    I think we can do something about this


C:  We have not implemented the complete specification of ip-dvb
    encapsulation. 

C1: the transission equipment changes, the new standard drafts are coming
    out, we should implement full specs

 


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.