-
Notifications
You must be signed in to change notification settings - Fork 583
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance #41
Comments
No detailed tests were performed. |
We are currently using RxAndroidBle to flash the firmware of a device over the air. The firmware is about 300kb. Nice thing is that I also have a proof of concept app for the same flashing process using pure Android API. These are not real experiments but simple rough estimate. Using RxAndroidBle, it takes up to 3 minutes to transfer everything as for native API, it's about 40s. The big bottleneck in the library right now for heavy data transfer is that all write operations (in fact simply all operations) are done on the UI thread. This make the transfer process really longer than expected as it's fighting for the UI thread resources. We noted a minimal 2x increase when just shutting down the screen of the device for example. I read in the code that you're doing this because Samsung 4.3 fails when |
As a result of this issue, there will be a report of write operation benchmark (16kB) with nRF based mock device:
|
) Initially when working with the Android Bluetooth API (18 / Android 4.3) it was found that specific implementations (Samsung’s) cannot work correctly if called directly in callbacks from other calls. To mitigate the problem the next interaction was routed to Android main thread. Now when investigating the issue it turned out that it may be any other thread as long as it is not the callback thread.
Now I finally made some performance tests for sending out as much data as possible using various approaches. SpecificationPeripheral: Test Algorithm
Speed calculationEvery response notification (2. step) is timestamped. All responses are buffered for 60 seconds. We take the last notification timestamp and the first notification timestamp and calculate the Code:
I have compared three approaches to sending data (all of them with setting
Results (in Bytes per second)
Results for
|
central \ implementation | unoptimizedSendUuid |
unoptimizedSendCharacteristic |
longWriteSend |
optimizedSend |
---|---|---|---|---|
Micromax Canvas A107 (5.0) | 576.0 | 571.9 | 567.8 | 570.8 |
Nexus 5 (6.0.1) | 605.0 | 612.0 | 623.9 | 624.5 |
Samsung Galaxy S6 SM-G920F (7.0) | 629.0 | 619.9 | 623.2 | 632.3 |
Motorola Droid XT1030 (4.4.4) | 342.3 | 342.9 | 343.0 | 344.8 |
Asus Zenfone 5 T00J (4.4.2) | 546.7 | 542.9 | 560.7 | 545.7 |
Samsung Galaxy S3 GT-I9300 (4.3) | 579.2 | 585.6 | 577.3 | 568.7 |
Google Pixel (8.0.0) | 757.3 | 757.3 | 758.6 | 758.7 |
Conclusion
- When interacting with a low
Connection Interval
peripheral it may be worth to use native implementation or custom operation to mitigate the downturn thatRxJava
causes. - When the
Connection Interval
grows the benefit from optimisations are less visible. It could need a detailed research but it seems that forConnection Interval > 50 ms
every implementation should perform similarly. - The potential throughput of different Android handsets varies a lot (even in the same environment) because of the raw speed of the device (the route time of going through all the system layers from
BluetoothGatt.writeCharacteristic()
toBluetoothGattCallback.onCharacteristicWrite()
) and number of buffers that it's Bluetooth Chip has.
I hope this quick research helps you.
Best Regards
Has anyone noticed performance degradation by using the library? Or is it a common issue? I've been achieving, on average, 1.5kbits/s when exchanging data with another Android device.
The text was updated successfully, but these errors were encountered: