Hi Will, On 6 December 2016 at 19:34, will sanfilippo <[email protected]> wrote: > Hello: > > Just wanted to see if folks have any comments about the following topic. This > has arisen due to our upcoming addition of allowing for multiple advertising > instances. It relates to the “priority” of events in the scheduler > (connections and advertising events specifically). > > To make a long story short, it is possible that when attempting to schedule > an advertising event there is no room in the scheduler for it. For example: > assume your advertising interval is 20 msecs. If you have alot of current > connections, it is possible that all of those 20 msecs are scheduled for > connection events. > > So, something has to give. Given that we only had one advertising instance in > the past, I made the decision that advertising is the highest priority; a > connection event that overlapped an advertising event would get pushed off. > The chance that this would cause a connection to fail is miniscule given that > advertising events are randomized within a 10 msec period. > > With many advertisers this decision may be a bad one; connections could fail. > Furthermore, if you have alot of advertisers and short intervals, a large % > of the time would be spent advertising. I do realize that non-connectable > advertising events must use an interval that is at least 100 msecs. Still, if > you have 10 instances you are using more than 50% of the time if the > advertisements are large and these advertisements are scannable. > > So much for a long story being short :-) There are a number of ways to > address this issue. Here are some choices to consider: > > 1) Connection events never get displaced by advertising events; you simply > try to find the next possible time in the scheduler for advertising events > and if they get pushed off indefinitely, oh well.
We got here small discussion on this topic and conclusions we have is that putting prioritization of Connection Event over Advertising event is better solution for couple of reasons: a) Connection Events is determined by connection interval and slave latency. Rescheduling Connection Event in case when slave latency is 0 on connection, might lead us to lose a link (e.g. supervision timeout fires). b) Advertising Event is determined by advertising interval but as you said it is randomized withing 10ms period (advDelay). IMHO we should use that advDelay to make sure that it will not cause collision with Connection Event. 10ms is a plenty of time and we should be able to find new timeslot for Advertising event without loosing anything c) Maintaining existing connections seems to be more important than advertising imho > 2) Advertising events always supplant connection events. If you cannot find a > place in the scheduler for the advertising event, you push off the connection > event to the next interval. > 3) We modify the vendor specific HCI command so that the host can specify the > behavior: the advertising event is more important than a connection event, or > vice versa. > 4) We come up with some “least recently used policy”. If we just serviced the > connection event but skipped the advertising event, the next time we schedule > things the advertising event would get precedence. Thus, for any scheduled > event, you choose the one that was serviced the furthest in the past. > > Thoughts? Any other choices that folks feel should be considered? > > Thanks, > Will > > PS Note that in our scheduler, scanning always has the lowest precedence. If > the scheduler is completely full, scanning does not occur. This might be a > bad idea as well but the chance that there is 0 time for scanning is pretty > small. > > PPS I am attaching a document that shows the additional, vendor specific HCI > commands. This is an Android addition... There was no file attached :) Best regards Lukasz
