Re: Multicast log question



Mike,

I am not quite familiar with the logging, but based on what you are seeing,
I am guessing that c-pkts-lost-cont-net is probably being counted separately
from c-pkts-lost-net though I have no way of confirming that.

Also, the WMS Logging Model document at:
http://www.microsoft.com/windows/windowsmedia/howto/articles/LoggingModel.aspx

says this about c-quality:
• c-quality. The minimum quality experienced by the client throughout the
session; not the average quality. For example, if a client is streaming for
ten minutes and there is a bad network connection for ten seconds, the
c-quality value drops to 60 percent, and it doesn't go up again for the
current session. So the c-quality value might be misleading sometimes. You
should also look at the lost and recovered packets values, the total buffer
time, and the buffer count to make a proper decision about the quality of the
streaming. Don’t just rely on the c-quality value alone.

My guess is that when the client lost 13 packets that weren't recoverable
(i.e., more than 2 packets in a chunk). The quality could've gone to 94 and
would be set at 94 after that. Rest of the packet losses were single packet
losses and all were recovered. Again, just a guess at this point on my part.

Also, I am wondering if a loss of 3 packets at 10 different times, would
count as 30 lost-cont-net packets - in which case the quality will only dip
to 94 and not much lower (which may happen with a straight 30 packet loss,
I'd imagine). Again, just a guess on my part.

Thx,
Ravi
--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Mike Lowery" wrote:

>
> "Mike Lowery" <selfspam@xxxxxxxxxxxxxxxx> wrote in message
> news:ugcKbrfkFHA.3960@xxxxxxxxxxxxxxxxxxxxxxx
> > I've got logging set up on my multicast publishing points and have received an
> > entry that confuses me. The following values are present:
> >
> > c-pkts-received: 10354
> > c-pkts-lost-net: 67
> > c-pkts-lost-cont-net: 13
> > c-pkts-recovered-ECC: 67
> > c-quality: 94
> >
> > Based on past testing we've found that WMP can only recover one lost packet
> out
> > of 11 (the 11th is a Forward Error Correction packet.) The above data
> suggests
> > that all lost packets were recovered, but at one point there were 13 lost
> > consecutively. Additionally, the quality value dropped to 94%. How could
> this
> > be if all packets were supposedly recovered? Are the 13 consecutive lost not
> > part of the 67 total lost?
>
> Nobody has responded so apparently this is as confusing to everyone else as it
> is to me. Here's more confusing stats:
>
> c-pkts-received: 19143
> c-pkts-lost-client: 0
> c-pkts-lost-net: 92
> c-pkts-lost-cont-net: 27
> c-pkts-recovered-ECC: 92
> c-quality: 94
>
> If WMP was able to recover all 92 packets (not sure how this could be with 27
> lost at once), why wasn't my c-quality stat 100%?
>
>
>
.



Relevant Pages

  • Multicast log anamoly
    ... Unicast retransmission/failback is disabled. ... which always results in lost packets. ... it's able to recover 1 packet out of every 11. ...
    (microsoft.public.windowsmedia.server)
  • Re: Multicast log question
    ... We've been doing a lot of testing with packet loss and WMP over the past year to ... the info below on c-quality doesn't tell you ... number of sequential packets lost at one time. ... >>> 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)