400ms delay between ATT Write request and response

Question

Hi, 
 On a nrf52840 running SDK 17.0.2 and Softdevice 7.2, while being connected to two devices in central and peripheral role, I observe that on the connection where the nrf is in peripheral role, a whopping 400ms delay between an ATT write request and its response (detected and measured with wireshark) 
 In the Message sequence diagram "GATTS write request without authorization" I get the impression that the response is sent "immediately" by the softdefice, where that immediately intuitively is in the 20ms range rather than 400ms.. 
 My questions are: 
 - What influences the observed delay (I suspect connection parameters a bit..) 
 - Can I have influence on this in such way that the delay is reduced? 
 
 I can see that if I disconnect the peer in peripheral role (where the nrf is central) the delay drops to some 20-50ms. 
 Thank you, jmr.

jmr · Answer

Hej Torbj&oslash;rn, 
 Thanks for the insights and your extensive reply. Your input has led me into the right direction. 
 So after quite a bit of digging and reading, I found the reason to why I suddenly lost communications with peer2: 
 the mentioned connection intervals with peer1 and peer2 do not work well with the softdevice scheduler, which leads to dropped packages and the observed lost communications. 
 With peer2, the connection parameters get set by the remote peer (as it is central, 20,20,0,1000 as mentioned in a previous message) and since we "talk" a lot with peer2, we keep this parameters and do not request an update. (I tried that but however failed for some other reason most probably related to peer2's internals) 
 Peer1 is a sensor in peripheral role which requests the connection parameters to be changed a few times, finally asking for (187.5, 437.5, 3, 6000). 
 originally, my software (in central role here) would process an update request like this (taken from ble_app_multirole example): 
 case BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST: { // Accept parameters requested by peer. err_code = sd_ble_gap_conn_param_update(p_gap_evt->conn_handle, &p_gap_evt->params.conn_param_update_request.conn_params); APP_ERROR_CHECK(err_code); } break; 
 Forwarding (187.5, 437.5, 3, 6000) as requested to the softdevice, as in the code above, the softdevice will confirm the request and set the connection interval to 437.5. Now this is a bad pick, which results in lost or inacceptably delayed packets and eventually a commmunications breakdown with peer2. 
 BECAUSE 
 Chapter 15 in S140_SDS_v2.1.pdf (Or in infocenter/sds_s140/SDS/s1xx/multilink_scheduling/suggested_intervals_windows ) states quite clearly, that connection intervals must be carefully chosen to avoid collisions and / or dropped packages. And a careful choice would be (in my case) that connection intervals of all connections are multiples of a common base. Which is with 437.5 and 20 clearly not the case. So eventually, there are package-timing collisions in softdevice which leads eventually to communications breakdown. 
 MY SOLUTION was to change the conn param update request procedure from above to something that instead of passing the requested parameters directly to SoftDevice, would find a "good" value within the requested min/max and set that as the new connection interval. So from the (187.5, 437.5, 3, 6000) request, we find a value close to 437.5ms which is a multiple of 20ms. So the SoftDevice will get to change parameter to (400, 400, 3, 6000) and that solves my problems with peer2. 
 Of course, this fix only solves my current situation, and by adding more connections (or adding simultaneous scanning while advertising and maintaining a connection) things get worse. One needs to keep a finger on Chapter 15 in softdevice spec. while working with multiple simultaneous connections (and/or attempts). Also worth reading is a post by Edvin on topic Connection Parameter Selection for Central Device with 10 Peripheral Simultaneous Connections which covers some of the same troubles. 
 What I am missing is feedback from the softdevice scheduler to detect such conflicts. I thought setting NRF_SDH_*_LOG_LEVEL to DEBUG severity would give me such insight, but it doesn't. 
 Maybe I am missing something and there IS feedback from the SD-Scheduler? 
 Ah, and I forgot to mention.. the observed 400ms delay (this issue's topic) is most probably due to the scheduler having deferred the response due to being occupied with processing connection with peer1. But of course, without knowing scheduler details (and especially its scheduling strategy) this is only me guessing. Maybe some of you Torbj&oslash;rn or any other nRF cracks can confirm that. 
 hilsen, J&oslash;rn.