On 04/20/2010 10:42 AM, Holger Freyther wrote:
The root causes consist of various issues:
- Our delay in src/input/ipaccess.c does not help, removing it
is breaking the rugby sized BTS though..
- Our paging layer sends the paging command in bursts... we
should have an even distribution of them.
- We have some NM attributes to play with.
Hi,
I have the following changes in my branch:
1.) instead of sending n paging requests in a big bulk, send one every
couple of milliseconds. Even if the CCCH Overload warning should be
fine, in my experiments the nanoBTS didn't really like it. The delay in
milliseconds was tested like this. I was having 200 pending paging
requests and I was making the delay big enough to not run into messages
from the nanoBTS about dropped paging requests. I think that change is
okay to land and should not interfere with anything.
2.) the other one is to not send a paging request when there are no free
channels for that given type. This is configurable and off by default. I
think this is meeting LaF0rge's requirements about such a change.