The nimble scheduler and multiple advertising instances

[will sanfilippo <wi...@runtime.io>]

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.
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...

Re: The nimble scheduler and multiple advertising instances

[Łukasz Rymanowski <lu...@codecoup.pl>]

Hi Will,

On 7 December 2016 at 18:45, will sanfilippo <wi...@runtime.io> wrote:
> Some comments here. Note that these are not meant to be “disagreeable”; just more for clarification.

Cool, I got it :)

> a) Slave latency of 0 does not mean you will drop a connection if you miss a single connection event.

Correct, that is clear. What I meant was missing one we increase
probability of link lost in certain link configurations and enviroment
(link quality).  Probability of missing next one is same as first one
and my point is that we should rather have full controll of what is
happeining than base on probability. You know, Murphy is there ;)

> 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.

Actually I also had in mind more than one connection, but you see my
point, lets try to do our best using advDelay.

>
> 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.

Sounds great:)

>
> Thanks for the feedback! Greatly appreciated.

\Łukasz
>
>
>> On Dec 7, 2016, at 2:55 AM, Łukasz Rymanowski <lu...@codecoup.pl> wrote:
>>
>> Hi Will,
>>
>> On 6 December 2016 at 19:34, will sanfilippo <wi...@runtime.io> 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
>

Re: The nimble scheduler and multiple advertising instances

[will sanfilippo <wi...@runtime.io>]

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 <lu...@codecoup.pl> wrote:
> 
> Hi Will,
> 
> On 6 December 2016 at 19:34, will sanfilippo <wi...@runtime.io> 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

Re: The nimble scheduler and multiple advertising instances

[Łukasz Rymanowski <lu...@codecoup.pl>]

Hi Will,

On 6 December 2016 at 19:34, will sanfilippo <wi...@runtime.io> 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