From e77d49f2a2c20202dbdc5386c7dfeed4e773a077 Mon Sep 17 00:00:00 2001 From: Jacob Erlbeck Date: Thu, 27 Aug 2015 13:28:05 +0200 Subject: [PATCH] poll: Set the max_delay to 60 frames Currently the max_delay parameter is set to 13, since that is slightly above maximum number of frames that a time_ind can preceed a block's data_ind of the same frame. This assumes that these messages are not reordered after thay have been obtained from the DSP. In the current implementation, the GPRS data_ind can directly be taken from the DSP by the PCU while the time_ind messages are provided via the BTS. So the messages are queued differently in that case, resulting in a additional delay of the data_ind with respect to the time_ind. The propability for this raises with a increased CPU load of the PCU. If this happens, a poll timeout is detected by mistake and the poll is either retried or cleared. This commit increases the tolerance to 60 frames, since values for FN_data_ind - FN_time_ind of up to 50 frames have been observed under heavy PCU load. Sponsored-by: On-Waves ehf --- src/bts.cpp | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/bts.cpp b/src/bts.cpp index 661c5114..6248348f 100644 --- a/src/bts.cpp +++ b/src/bts.cpp @@ -141,8 +141,11 @@ void BTS::set_current_frame_number(int fn) * received. Sometimes there is an idle frame between the end of one * and start of another frame (every 3 blocks). So the timeout should * definitely be there if we're more than 8 frames past poll_fn. Let's - * stay on the safe side and say 13 or more. */ - const static int max_delay = 13; + * stay on the safe side and say 13 or more. An additional delay can + * happen due to the block processing time in the DSP, so the delay of + * decoded blocks relative to the timing clock can be much larger. + * Values up to 50 frames have been observed under load. */ + const static int max_delay = 60; m_cur_fn = fn; m_pollController.expireTimedout(m_cur_fn, max_delay);