how to restrict Nimble to send only 1 or 2 message/s per connection event when Nimble is as peripheral

[Ondrej Pilat <on...@ozobot.com>]

Hi All,

Is it possible to tell Nimble to send only 1 or 2 packets per each
connection event when Nimble is as peripheral? I have application which
serves as 1 to X bridge (X can be up to 18). I need to restrict
connection between PC and the NRF52 to send only 1 to 2 packets per
connection event otherwise it uses to much from the throughput that
connection between nrf52 and 18 devices cannot have interval window 60
to 120ms. Instead they are communicating with 300 to 500ms period.

From previous communication:

/My assumption are following:/

//

  * /only one packet per each connection event/
  * /send/receive 132B packet between NRF52 and PC each connection event/
  * /send/receive 20B packet between NRF52 and peripheral each
    connection event/

//

/I made following rough computation:/

//

/PC <-> NRF52: 132B data + 21B header => (153B * 8) / 1Mbps => 1224 uS +
150 uS IFR + 80 uS ACK + 150 uS IFR => 1604 uS * 2 (send/receive) =>
3208 uS //
/

//

/NRF52 <-> peripheral: 20B data + 21B header => (41B * 8)  / 1Mbps =>
328uS + 150 uS IFR + 80 uS ACK + 150uS IFR => 708uS * 2 (send/receive)
=> 1416 uS/

/It means one big and six small packets should fit in each PC <-> NRF52
connection event 3208 + 6 * 1416 = 11 704 < 12.5ms interval window. For
18 peripherals it means 3 such cycles to serve them all therefore 37.5ms
interval window between NRF52 and a peripheral.
/

/On this I received response:/

You need to take NimBLE scheduling into account here. Each connection event
is preallocated a fixed amount of time in 1250us slots - see
BLE_LL_CONN_INIT_SLOTS. This means effectively connection events cannot be
scheduled less than 1250us apart. Also, scheduler overhead is ~200us (for
nRF52, may be different for nRF51) for each connection event so effective
connection event time with 1 slot allocated is 1050us. Note that this is
min time since connection events can be extended pretty much indefinitely
as long as there is no other activity scheduled so e.g. until another
connection event.

I do not know if "20B packet" means "20 bytes of LL payload", but will
assume so since we are talking LL level here. This can fit into a single
scheduled slot: 240us + 150us + 80us = 470us < 1050us. Let's assume 1ms for
each connection event including scheduler overhead so you need 18ms to
serve all 18 devices in one direction. If you need to send data in both
directions you need 240us + 150us + 240us = 630us < 1050us so nothing
changes and you still have quite a lot of extra time to spare in each
connection event (e.g. for retransmissions). It will be a bit different if
you need to transfer data in both directions in separate connection events
as basically you need twice as much connection events, this means you need
at least 36ms to serve all peripherals. One possible problem here is that
connection may not be scheduled exactly 1.25ms apart and this will create
gaps where no connection can be scheduled, you can't really control this
with default scheduler. Possible solution would be to use
BLE_LL_STRICT_CONN_SCHEDULING which schedules connections in central role
at fixed intervals, although I never used it so not sure if there's
anything that requires more configuration than just enabling this feature.

When I take these information in account I get that Nimble should be
able to have:
10ms interval window between a PC and NRF52 (Nimble is as peripheral)
60ms interval windows with 18 devices (Nimble is as central device)

I am not able to achive such values. Attached is sniffed communication
between PC and NRF52 which shows that there is no space left for the
other devices to communicate with 60ms windows. During my tests the
Nimble is sending packets betwen NRF52 and devices with 300ms to 500ms
period although interval windows is set to 120ms with them.

Best regards
Ondrej Pilat

-- 

Re: how to restrict Nimble to send only 1 or 2 message/s per connection event when Nimble is as peripheral

[Ondrej Pilat <on...@ozobot.com>]

Hi All,

I am resending this mail because nobody responded. Can please somebody
look on this issue?

Regards

Ondrej Pilat

Dne 6/9/2020 v 10:22 AM Ondrej Pilat napsal(a):
>
> Hi All,
>
> Is it possible to tell Nimble to send only 1 or 2 packets per each
> connection event when Nimble is as peripheral? I have application
> which serves as 1 to X bridge (X can be up to 18). I need to restrict
> connection between PC and the NRF52 to send only 1 to 2 packets per
> connection event otherwise it uses to much from the throughput that
> connection between nrf52 and 18 devices cannot have interval window 60
> to 120ms. Instead they are communicating with 300 to 500ms period.
>
> From previous communication:
>
> /My assumption are following:/
>
> //
>
>   * /only one packet per each connection event/
>   * /send/receive 132B packet between NRF52 and PC each connection event/
>   * /send/receive 20B packet between NRF52 and peripheral each
>     connection event/
>
> //
>
> /I made following rough computation:/
>
> //
>
> /PC <-> NRF52: 132B data + 21B header => (153B * 8) / 1Mbps => 1224 uS
> + 150 uS IFR + 80 uS ACK + 150 uS IFR => 1604 uS * 2 (send/receive) =>
> 3208 uS //
> /
>
> //
>
> /NRF52 <-> peripheral: 20B data + 21B header => (41B * 8)  / 1Mbps =>
> 328uS + 150 uS IFR + 80 uS ACK + 150uS IFR => 708uS * 2 (send/receive)
> => 1416 uS/
>
> /It means one big and six small packets should fit in each PC <->
> NRF52 connection event 3208 + 6 * 1416 = 11 704 < 12.5ms interval
> window. For 18 peripherals it means 3 such cycles to serve them all
> therefore 37.5ms interval window between NRF52 and a peripheral.
> /
>
> /On this I received response:/
>
> You need to take NimBLE scheduling into account here. Each connection event
> is preallocated a fixed amount of time in 1250us slots - see
> BLE_LL_CONN_INIT_SLOTS. This means effectively connection events cannot be
> scheduled less than 1250us apart. Also, scheduler overhead is ~200us (for
> nRF52, may be different for nRF51) for each connection event so effective
> connection event time with 1 slot allocated is 1050us. Note that this is
> min time since connection events can be extended pretty much indefinitely
> as long as there is no other activity scheduled so e.g. until another
> connection event.
>
> I do not know if "20B packet" means "20 bytes of LL payload", but will
> assume so since we are talking LL level here. This can fit into a single
> scheduled slot: 240us + 150us + 80us = 470us < 1050us. Let's assume 1ms for
> each connection event including scheduler overhead so you need 18ms to
> serve all 18 devices in one direction. If you need to send data in both
> directions you need 240us + 150us + 240us = 630us < 1050us so nothing
> changes and you still have quite a lot of extra time to spare in each
> connection event (e.g. for retransmissions). It will be a bit different if
> you need to transfer data in both directions in separate connection events
> as basically you need twice as much connection events, this means you need
> at least 36ms to serve all peripherals. One possible problem here is that
> connection may not be scheduled exactly 1.25ms apart and this will create
> gaps where no connection can be scheduled, you can't really control this
> with default scheduler. Possible solution would be to use
> BLE_LL_STRICT_CONN_SCHEDULING which schedules connections in central role
> at fixed intervals, although I never used it so not sure if there's
> anything that requires more configuration than just enabling this feature.
>
> When I take these information in account I get that Nimble should be
> able to have:
> 10ms interval window between a PC and NRF52 (Nimble is as peripheral)
> 60ms interval windows with 18 devices (Nimble is as central device)
>
> I am not able to achive such values. Attached is sniffed communication
> between PC and NRF52 which shows that there is no space left for the
> other devices to communicate with 60ms windows. During my tests the
> Nimble is sending packets betwen NRF52 and devices with 300ms to 500ms
> period although interval windows is set to 120ms with them.
>
> Best regards
> Ondrej Pilat
>
> -- 
--