[prev in list] [next in list] [prev in thread] [next in thread]
List: helix-server-cvs
Subject: [Server-cvs] engine/dataflow ppm.cpp,1.147,1.147.4.1
From: packard () helixcommunity ! org
Date: 2011-12-24 1:24:32
[Download RAW message or body]
Update of /cvsroot/server/engine/dataflow
In directory cvs01.internal.helixcommunity.org:/tmp/cvs-serv2425/engine/dataflow
Modified Files:
Tag: SERVER_14_3
ppm.cpp
Log Message:
Synopsis
========
fix Bug 269615: RSS logs: Bandwidth Stats: Subscribed gives wrong value
Branches: SERVER_14_3_RN, SERVER_CURRENT_RN (HEAD)
Suggested Reviewer: Dean, Chytanya, Anyone
Description
===========
In the RSS logs, there are lines like:
Bandwidth Stats: Output 0.00 Mbps, 0.0 Kbps Per Player Bandwidth Stats: 100% \
Subscribed (0.00 Mbps), 0% Nominal (4152.82 Mbps)
It is supposed that when the server sends out the expected amount of data (that is, \
each client gets at least the bandwidth the stream is encoded in), this value should \
be 100% or nearby. However, in my load tests at HP France, it showed that regularly \
this value was considerably lower although playback was fine and measurements at the \
NICs showed the expected amount of traffic.
Repro Case:
1) Start Helix Server
2) Set up an 150 kbps 3gp simulated live stream
3) Access the live stream with many load test clients (e.g., 500 or 1000 or more)
4) Check the RSS logs.
EXPECTED RESULT:
- The value "Bandwidth Stats: Output" is roughly the number of clients times the \
bandwidth of a single stream (e.g. 150 kbps times 1000 clients = 150 \
Mbps)
- The value "Bandwidth Stats: Subscribed" is nearly 100%
ACTUAL RESULT:
- The value "Bandwidth Stats: Output" is roughly the number of clients times the \
bandwidth of a single stream (e.g. 150 kbps times 1000 clients = 150 Mbps) => so far \
so good.
- The value "Bandwidth Stats: Subscribed" is considerably lower, such as 70%-80%.
If you do the same test with a 3gp or mp4 ondemand file, the "Subscribed" values are \
even worse, at 50%-65%.
With a live stream the values are about 75%.
With other protocols (RTMP, HLS) we also see no better results.
This is not directly customer impacting but more and more customers look into the \
logs and the server seems to state that it is not sending the full amount of data.
Solution
==============
As far as I investigated, there exist several parts in our source relate to this \
problem. 1. let
Abytes = latest total bytes send out
Bbytes = last time total bytes send out
Cbw = avg bitrate get from stream header
Dbw(i) = BWCalculator bandwidth {i=0,1,2....n} t = current time - last calculate \
time Bandwidth Subscribed = (Abytes - Bbtyes) * 8 / (Cbw*client num + sum Dbw(i)) / t
So Bandwidth Subscribed is decided by the bytes send out from server, the avg bitrate \
get from stream header, the BWCalculator bandwidth. As bytes send out from server is \
added each time after we use transport->sendpacket, and current problem is Bandwidth \
Subscribed is small, so I suppose the numerator of this fraction is correct. Now if \
there exist a problem, it should comes from the (Cbw*client num) or sum Dbw(i)
2.
> From what I investigate, client num is OK, no matter whether it is from PPM or from \
> MDP or from http Cbw is gotten from the stream header (vod or live) and should be \
> supposed to be correct.
If use http( admin page or HLS, it will use Dbw(i) )
3.
Sometimes PPM or MDP will also use Dbw (BWCalculator bandwidth) when send stream \
data, and this may be the place that the problem come from. We calculate the \
bandwidth twice! One is with the avg bitrate, another is with BWCalculator, so the \
denominator of the fraction is enlarged. The cr.diff tries to avoid this problem.
4.
Another thing to mention is that when using the helixsim, if using 3gp vod, I find \
the helixsim will only get data from server once, and after that helixsim is played \
with itself, and the link and status is OK. But seen from the server rss log, the \
subscribed becomes low and low as no data sent out. So this could prove that server \
doesn't send out data after helixsim get data at first time. This phenomena only \
comes up when using 3gp vod with helixsim. I use the command "./helixsim --num=30 \
-l=0 rtsp://server ip/test.3gp", the version of helixsim is Beta 2.0 (2.0.1.2)
5.
At last, Bandwidth Subscribed only reflect an average status of the data send out \
from server compare to its suppose to send out. So if the interval is small and \
client number is not that large, this value could not be the one we suppose it to be. \
Eg. The rss interval is 3s, and we have two clients, the stream avg bitrate is \
200kbps. 0~2s, no request
2~3s, Clients request the file
3s, calculate the Bandwidth Subscribed, as data send out from server is not that \
much, so the bandwidth is smaller, and Bandwidth Subscribed would be small.
If the file only last for 1s,
3~4s file play
4-6s no request
6s, calculate, as the client exist, global bandwidth sum is 0 or nearly 0, the \
bandwidth could be a big number then. (we could deal with this case when compute \
subscribed value, not implement yet as permission is needed)
If using MDP vod, there could be no data send out in some interval or a lot of data \
sent out in another interval.(if the interval is not large, eg. several seconds)
These should be all OK.
Files Affected
==============
Server/engine/dataflow/ppm.cpp
Server/engine/dataflow/pullpcktflow.cpp
Added by Dean:
Not if the client has set the delivery bandwidth to something other than the media \
rate, such as during preroll. In this case the media may be 100Kbps but we're \
sending faster than the media rate, say 200Kbps or 400Kbps, in which we'll be much \
higher than 100%. For on-demand, since we oversent at the beginning, we'll be done \
sending packets before playback is done at the client, in which case subscribed will \
be less than 100% near the end, even 0%.
In these cases, Nominal indicates whether we're sending at the desired delivery rate. \
Nominal is generally more informative than Subscribed.
It's likely that "% Subscribed" doesn't mean what people might assume it means, and \
they're actually more interesed in Nominal. It's possible these should both be \
renamed.
This is not to say Subscribed is calculated correctly everwhere, clearly there are a \
number of cases where it doesn't get updated right, even with the above definition in \
mind.
Index: ppm.cpp
===================================================================
RCS file: /cvsroot/server/engine/dataflow/ppm.cpp,v
retrieving revision 1.147
retrieving revision 1.147.4.1
diff -u -d -r1.147 -r1.147.4.1
--- ppm.cpp 12 Jul 2011 23:08:42 -0000 1.147
+++ ppm.cpp 24 Dec 2011 01:24:29 -0000 1.147.4.1
@@ -2174,7 +2174,11 @@
UINT16 uStreamNumber = pPacket->GetStreamNumber();
ULONG32 unRule = pPacket->m_uASMRuleNumber;
PPMStreamData* pStreamData = m_pStreamData + uStreamNumber;
- pStreamData->m_pRules[unRule].m_pBWCalculator->PacketSent(pPacket);
+ if (pSD->m_pRules[unRule].m_ulAvgBitRate == 0 && \
pSD->m_pRules[unRule].m_pBWCalculator != NULL + && pSD->m_ulAvgBitRate == 0)
+ {
+ pStreamData->m_pRules[unRule].m_pBWCalculator->PacketSent(pPacket);
+ }
HXTimeval tHXNow;
tHXNow.tv_sec = m_pProc->pc->engine->now.tv_sec;
tHXNow.tv_usec = m_pProc->pc->engine->now.tv_usec;
@@ -4946,9 +4950,10 @@
//If AverageBandwidth is not available in the ASMRule book calculate \
BandwidthUsage using //BWCalculator.
- if (pSD->m_pRules[unRule].m_ulAvgBitRate == 0 && \
pSD->m_pRules[unRule].m_pBWCalculator != NULL)
- {
- pSD->m_pRules[unRule].m_pBWCalculator->BytesSent(pServerPacket->GetSize());
+ if (pSD->m_pRules[unRule].m_ulAvgBitRate == 0 && \
pSD->m_pRules[unRule].m_pBWCalculator != NULL + && pSD->m_ulAvgBitRate == 0)
+ {
+ pSD->m_pRules[unRule].m_pBWCalculator->BytesSent(pServerPacket->GetSize());
}
pServerPacket->m_uPriority = pSD->m_pRules[unRule].m_ulPriority;
_______________________________________________
Server-cvs mailing list
Server-cvs@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/server-cvs
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic