[Udpcast] Problems With timeout of satellite transmission

[Alain Knaff]

Diego Zimmermann wrote:
> Sorry, I forgott in the first mail
> I'm using udp-sender --async --mcast-data-address 229.1.1.1
> --mcast-rdv-addr 229.1.1.1 --autostart 1 --fec 8x8/128 --max-bitrate 500k
> --interface eth1 --portbase 4002 -f announce
> and udp-receiver --nosync --mcast-rdv-addr 229.1.1.1 --interface dvb0_0
> --portbase 4002 -f announce

Indeed, on a LAN this seems to work (changing just the name of the
interface)

And the parameters are set up ok for return-channel-less transmission
(verified by setting iptables on sender to drop all return traffic:
still works).

As communication is now purely unidirectional, satellite latency should
not make a difference either.

So, this is really weird, could you check the settings on your routers,
encapsulators, etc. to make sure they aren't dropping any packets along
the way? A tcpdump taken at the client, and another one at the server
(just ports 4002 and 4003) would also be helpful to see whether anything
is lost.

However, while running a tcpdump myself, one thing struck me: you set
fec to use 8 slices size with 8 redundant packets. This is fine for
large files. But for just 1500 bytes (2 payload packets), this is way
overkill: indeed, this means that at least 64 packets will be
transmitted (8 redundant packets for each of the 8 slices). Of these 8
slices, 6 would be completely useless, as they'd contain _only_
redundant packets, and no data packets.

--fec 1x2/128 would be more appropriate. This would still give you 100%
redundancy (2 redundant packets per 2 data packets) but be far less
wasteful.

Regards,

Alain