问题
I have an application that needs to transmit bursts of data to android device.
A sequence of packets during this burst is attached. We observe that during channel change, stack goes too busy and does not transmit anything for ~45-48 ms.
This leads to data loss on transmitting device. We cannot hold that amount of data on transmitter to cope with delay in bluedroid.
Are there any suggested changes in AOSP / bluedroid that can improve this situation? Any suggestions on where to start looking?
Target device is Nexus 7 2013 (flo) with AOSP 5.1.1_r14
回答1:
This is probably hardware specific behavior. Perhaps the hardware buffer is limited to 4 packets, and driver delivers/fetches packets only during interrupt on CI elapse.
回答2:
MD column is "More Data" it tells if transmitter has more data to send. In this case, Slave sets MD=0 on 4th transmitted packet on every CI and so master goes away. Master checks back in next CI with empty packet.
In my application, somehow this gap is 46 ms due to issue in negotiating ConnInterval, so master defaults to 48.75 ms CI. And so it sleeps for ~46ms
My data loss is happening due to issue mentioned by @Gaurav, but on Slave, i.e. Slave LL is dropping packets fed to it while it already has 4 packets. [This is a guess] I'll confirm and update.
Update
Looks like CONNECT_IND contained transmitWindowSize of 2.5ms in the captured log, transmission of 4 packets will take 2.3+ms, and 5th packet wont fit in 2.5 ms. transmitWindowSize might be the real reason why no more than 4 packets are transmitted per CI, still doesn't explain MD=0 in 4th packet though.
来源：https://stackoverflow.com/questions/36542079/bluedroid-hangs-up-for-45-ms-during-channel-switch