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

@@ -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);