Windows 10 throughput / connection window clashes

RE: Windows 10 throughput / connection window clashes

daviddedwin — Tue, 12 Jan 2021 17:55:51 GMT

Absolutely, I would take this as supporting the hypothesis that the firmware patches are different for the mac OS vs the windows PC.
As a final test you can setup a sniffer and capture the traces from the Windows and the mac OS. Look for the VERSION_IND packet from the CSR, this will also have an identifier for the firmware levels. The caveat is that the CSR firmware may not send the VERSION_IND but its worth a try as well. However do look at the hypotheses i have stated earlier as well.

Please give my answer an upvote if this has been helpful.

RE: Windows 10 throughput / connection window clashes

dingari — Tue, 12 Jan 2021 17:48:40 GMT

Duly noted!

One other thing I'm wondering if it might have some say in this matter is the GAP data length parameter. When connecting to my peripheral on macOS, the rx/tx octets are updated according to what I set `NRF_SDH_BLE_GAP_DATA_LENGTH` to (64). But when connecting to the Windows side, it just stays at 27. Could this have some significance?

RE: Windows 10 throughput / connection window clashes

daviddedwin — Tue, 12 Jan 2021 16:46:32 GMT

Looking at the driver tab that you have posted, the generic Microsoft Bluetooth driver is controlling the dongle on Windows 10. The CSR hardware uses a RAM based patch system to get updated code to the hardware, this patch is usually distributed through the vendor's driver. It would be good to use the vendor's latest driver instead of the generic microsoft driver.

Since the patch is distributed with the driver, it is possible that the mac OS has a later version of the driver and associated patches and hence performs better.

I would still encourage you to switch off WiFi and do a test (agreed, it is not a solution), so if the performance of the system improves from its current 1 in 100 attempts to have 2 peripherals, then we are certainly looking at a scheduler issue

Additionally and I think fairly important, you should test this on a inbuilt Win 10 Bluetooth hardware, as the dongle does not have the WiFi co-existance and will have worse performance as the WiFi will keep hitting on the Bluetooth packets. The dongle is something that a typical Win 10 user will not be using.

Summary of my hypotheses :
* Performance differences between macOS and Win 10, likely due the use of the generic windows driver which may not be at the right patch level.
* Test with WiFi off to see if performance improves pointing to a scheduler issue
* Dongle is not a typical use case for Win 10 so test with built-in Bluetooth and a vendor supplied driver

RE: Windows 10 throughput / connection window clashes

Jørgen Holmefjord — Tue, 12 Jan 2021 15:59:19 GMT

Hi,

I would recommend that you capture and upload sniffer trace of the on-air activity between the peripheral and central devices, both for the single-peripheral and dual-peripheral setups. That will provide much information about what happens and could help figure out the root cause.

Best regards,
Jørgen

RE: Windows 10 throughput / connection window clashes

dingari — Tue, 12 Jan 2021 13:58:33 GMT

@daviddedwin Thanks for the reply. The machine I'm testing on is running the latest Windows build (10.0.19041) and according to the Device Manager the Bluetooth adapter driver is "up to date", whatever that means.

This is a CSR USB dongle (USB\VID_0A12&PID_0001&REV_8891), but I experience this issue on my laptop as well. I'm running macOS Catalina on the same hardware and don't experience this issue.

I'd really like to keep it at the lowest possible value. I can see that the only connection parameter update received from the Windows central on the nRF52832 sets it to 15ms.

Also, disabling WiFi is not a solution (while I understand trying to limit the variables in this equation). We are nowhere near any thresholds for BLE bandwidth/throughput, and this setup works fine on another OS on the same hardware.

Marjeris Romero I'd love to hear any input you might have on this subject. If there's anything we can do to improve the performance since it's very sub optimal as-is.

RE: Windows 10 throughput / connection window clashes

daviddedwin — Thu, 07 Jan 2021 19:24:47 GMT

Additionally, when you are doing the experiments, make sure that no other devices are connected over Bluetooth and that WiFi is disabled, this will ensure that BLE bandwidth is maximized.

RE: Windows 10 throughput / connection window clashes

daviddedwin — Thu, 07 Jan 2021 19:20:35 GMT

This can be a scheduling issue on the link controller of the PC running Windows 10, so for completeness please report the Bluetooth IC that is used on the Windows 10 PC and the Windows 10 build number. Yes, just connecting at the link will change the bandwidth allocation on the PC Bluetooth. The additional info that this works 1/100 times points towards a scheduler issue possibility.

You can do a few experiments to get some more insight

1. Run this on a PC with a different Bluetooth IC. Verify that you have the latest driver for the Bluetooth IC that you are using so any patches can be applied.

2. Track the BLE_GATTS_EVT_HVN_TX_COMPLETE messages for the notifications and see if they are getting delayed. You should get a BLE_GATTS_EVT_HVN_TX_COMPLETE event with a count so you get an idea of the number of notifications being done. you can log this with a timer timestamp so you get an idea of the speed of the notifications. You can also adjust the Handle Value Notification queue size using that ble_gatts_conn_cfg_t::hvn_tx_queue_size make sure you have set it to a number that fits your application.

3. If you use the nRF Sniffer you will need to use 2 sniffers to sniff the 2 peripherals and you should see the actual connection interval and the data being sent.

4. Change the connection intervals that you are requesting to 30ms - 50ms or something more relaxed to see if the peripherals can co-exist.

5. Check if you are getting a SD_BLE_GAP_CONN_PARAM_UPDATE that changes the connection interval and may explain the delayed notifications.