Some comments here. Note that these are not meant to be “disagreeable”; just more for clarification.
a) Slave latency of 0 does not mean you will drop a connection if you miss a single connection event. Of course, it is based on the supervision timeout. I believe the smallest you can set a supervision timeout is 2 connection intervals, so missing one connection event wont cause a connection to drop. I would also think that setting a supervision timeout that did not allow for a few consecutively missed connection events is simply a bad idea. Guess it all depends on link quality, but I would allow for more than 3. b) I think you are only considering the case where there is one connection when you state that the 10msec randomization should be enough to avoid a collision with a connection. Furthermore, even with one connection, 10 msecs of randomization is not a “ton” of time. I presume most advertising events use all three advertising channels. If you are sending a large advertisement and/or receiving scan requests and sending scan responses, a large portion of that 10 msecs is taken up. The controller is indeed allowed to end an advertising event before all three channels are used however. But certainly I agree that the advDelay can be used to our advantage here, and I fully intended to use it. c) Yes, I do agree that maintaining a connection is more important than advertising. In the case of multiple advertising instances, if I were doing this without any feedback whatsoever, I would certainly make connections have higher priority than advertising events. However, I am not sure of all the uses cases out there and it would not be extremely difficult to have this behavior either be configurable or specified in the command. Of course, I would prefer it to be fixed, as that saves code space, testing effort, etc. Thus, unless someone objects, I am not going to make this behavior configurable or able to be specified in the command. We will do our best to avoid collisions. If there is a collision, the connection wins. Thanks for the feedback! Greatly appreciated. > On Dec 7, 2016, at 2:55 AM, Łukasz Rymanowski <[email protected]> > wrote: > > 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
