On 25 May 2010, at 19:52, Jeff Pyle wrote: > Hi Saúl, > > That makes sense. I'm more busy today than curious but thanks for > the info! > > Is this calculation used for documentation only? Does disabling it > affect any operational aspect?
It won't affect any operational aspect. It's only used to gather statistics. If you disable it you won't know how much data was moved through the relay by each session. > Would its running too slow cause any traffic issues through the > relay, particularly unscheduled disconnections from the dispatcher? No. It has no relation with the connections. The only downside of having it enabled when it takes too much to compute is that the function that gathers the statistics is blocking. That means that if the relay is asked to add a new session at that time it won't do it until the statistics gathering function returns. Existing streams that belong to already established sessions won't be affected as they are already processed inside the kernel. The only thing affected is setting up new streams which is only delayed until the statistics gathering function finishes its job. In your case if such a request comes it will be delayed by approximately 11ms, which will not affect your operations in any visible way. The message is printed as a warning. We considered that blocking the processing of requests for more than 10ms is undesirable, but in practice you won't see any difference even if it takes 100ms to gather the statistics. > I'm trying to diagnose the root causes of some issues we had this > morning and this information will be most helpful. If you have one way audio or disconnections, those are in no way caused by this. As I said, once the session is established, the data is forwarded by conntrack rules in the kernel and it will not be affected by any delay in response from the relay. The only negative effect you can expect if the statistics gathering time is too high, is a delay in establishing the session. > > > > - Jeff > > > On May 25, 2010, at 12:19 PM, Saúl Ibarra Corretgé wrote: > >> Hi Jeff and Lazslo, >> >> On 25/5/10 4:45 PM, Jeff Pyle wrote: >>> Laszlo, >>> >>> Good suggestion... I haven't dug into the source to see if the two >>> are >>> related. I've set that value to 0 to disable it. We'll see. >>> >> >> Indeed, that setting disables that calculation. If too many streams >> are >> traversing the MediaProxy relay at the same time, the calculation >> could >> take too long (depending on the configuration setting) so it's not a >> good idea to do it. You may want to increase the traffic sampling >> period. >> >> In case you are curious, look at the _measure_speed function in the >> SessionManager class (mediacontrol.py file). That function is called >> recurrently each traffic_sample_rate seconds, that's why is not a >> good >> idea for it to take long making the calculation. >> >> >> Regards, >> >> -- >> Saúl Ibarra Corretgé >> AG Projects >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Dan _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
