Multicast log anamoly



We've got a multicast publishing point streaming video at ~450kbs. Multicast
logging back to an IIS server is enabled and appears to be working normally.
Unicast retransmission/failback is disabled. Our clients are using wireless
802.11 which always results in lost packets. However, I occasionally get
entries back from clients that don't make sense. Here is such an entry from the
logs:

x-duration: 3213 (seconds watched)
c-bytes: 169802335 (total bytes received)
c-pkts-received: 118312 (total packets received)
c-pkts-lost-client: 0 (no packet loss, which can't be true)
c-pkts-lost-net: 716 (so there were losses, but...)
c-pkts-lost-cont-net: 289 (that's a large chunk to lose at once)
c-pkts-recovered-ECC: 716 (...huh? How did WMP recover all these packets
especially if 289 were lost at one time?)

Again, there is no packet retransmission going on here, so if a client loses a
packet it can't get it back, with one exception. If I understand Windows Media
ECC correctly, it's able to recover 1 packet out of every 11. Specifically, if
you send 10 packets WMS adds an 11th forward error correction (FEC) packet which
allows you to recover one of those 10 packets if it is lost. But if you lost
two or more consecutively, there's no way WMS FEC could recover them (2 out of
10 lost and we can only recover 1 out of 10.)

Can someone explain these numbers or am I correct in assuming that they must be
wrong, which would indicate a bug?


.



Relevant Pages

  • Re: Multicast log question
    ... c-quality value drops to 60 percent, and it doesn't go up again for the ... My guess is that when the client lost 13 packets that weren't recoverable ... >> Based on past testing we've found that WMP can only recover one lost packet ...
    (microsoft.public.windowsmedia.server)
  • Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
    ... There was a burst of lost packets between seq 1777 and 1959, ... The display lockup on the top test was a little odd. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Determining if it is "safe" to send UDP packets
    ... IMHO for "reliable" UDP you need to use some Quality of service ... Maybe your network is QoS enabled and your traffic gets classified as "below ... > the sender's OS that is throwing the UDP packets away. ... > next 100%-x% are not send, they are almost all completely lost. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Determining if it is "safe" to send UDP packets
    ... As we are sending on a wireless link (but assuming we are the ... the sender's OS that is throwing the UDP packets away. ... Another problem with TCP is its assumption that a lost packet is due to ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WEP: 64 bit or 128 bit?
    ... >> recover an arbitrarily long key in a negligible amount of time ... the number of packets required is essentially independent ... > packet capture to attack the next key byte, and so he doesn't need to ... in a negligible amount of time which grows only linearly with its size, ...
    (sci.crypt)

Quantcast