Re: Queued Writes vs. MTU
Re: Queued Writes vs. MTU
- Subject: Re: Queued Writes vs. MTU
- From: Michael Lauer via Bluetooth-dev <email@hidden>
- Date: Fri, 04 Nov 2022 13:32:24 +0100
I see and will do that, thanks.
For the records though, do we agree
that unconditionally returning 512 for WriteWithResponse is an iOS bug?
Best,
:M:
> On 3. Nov 2022, at 17:29, Matthias Ringwald <email@hidden>
> wrote:
>
> Hi Mikey
>
> According to the log, the ATT MTU is 247, which you also get back from
> CBPeripheral: maximumWriteValueLength for Write Without Response. So, that's
> correct.
> It looks like CoreBluetooth sends data shorter then the ATT MTU as write
> without response (write command), and uses prepared writes for longer ones.
>
> I guess if you chunk your data based on the maximumWriteValueLength for write
> without response, you should be good.
>
> Best
> Matthias
>
>> On 2 Nov 2022, at 14:34, Dr. Michael 'Mickey' Lauer <email@hidden>
>> wrote:
>>
>> Hi Matthias,
>>
>>> Is there are reason for write commands longer than 247 bytes? The
>>> over-the-air packets cannot be bigger anyway, so there's not much
>>> throughput improvement.
>>
>> I see. Well, I just want to maximize bandwidth. The commands I’m sending to
>> the device are max. 8K and I though the less fragmentation on the transport
>> layer the better.
>>
>>>
>>> Could you post a PacketLogger trace to check the ATT PDUs?
>>
>> Please find the trace attached. Note that the problematic device is
>> 48:23:35:00:B5:A4 and from the App-perspective I’m sending my first long
>> command (512 bytes of data) @ Oct 25, 15:26:11.676 when the transfer
>> suddenly
>> stalls.
>>
>>> How did you get the max write size? CBPeripheral:maximumWriteValueLength
>>> with both write types?
>>
>> Correct.
>>
>> Best regards,
>>
>> Mickey.
>>
>> <obdlink-cx-512-loss.pklg>
>>>> On 28 Oct 2022, at 15:42, Dr. Michael 'Mickey' Lauer via Bluetooth-dev
>>>> <email@hidden> wrote:
>>>>
>>>> I have a problem with a BLE peripheral and iOS.
>>>> It’s unclear who is to blame, but one (or both) are doing something bogus.
>>>>
>>>> Let’s assume I only want to do WriteWithResponse in order to have
>>>> better diagnostics (delegate being called after transmit).
>>>>
>>>> When I ask iOS for the WriteWithResponse MTU, it returns 512.
>>>> Sending packets up to 247 data bytes works fine (which, by the way, is
>>>> what iOS reports for WriteWithoutResponse), but once I
>>>> exceed this, iOS sends a PREPARE WRITE to my peripheral, which –
>>>> due to that peripheral not implementing queued writes – is not answered
>>>> and the whole transfer stalls.
>>>>
>>>> Unfortunately it is an off-the-shelf BLE device (OBDLink CX OBD2 adapter),
>>>> where I don’t have any control over the stack it’s using.
>>>>
>>>> Could anyone share some light on this? Let’s start by the question
>>>> why iOS claims 512 to be an OK MTU for that peripheral?
>>>>
>>>> Best regards,
>>>>
>>>> Mickey.
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Bluetooth-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden