RE: [Bluez-devel] RE: Qualification testing - rfcomm

[Max Krasnyansky <maxk@qualcomm.com>]

At 12:19 PM 7/18/2003, Daryl Van Vorst wrote:
>Marcel,
>
>> > Do you mean you tried the aclsession script and didn't see the same 
>> > send 5 frames, wait 20 sec, send 5 more etc problem?
>> 
>> the aclsession scripts produces this effect, but it also left 
>> the ACL link in some kind of buggy state. It must be some 
>> really stupid that I always overlook. The code looks correct 
>> to me and my Bluetooth 1.0b devices are working fine.
>
>Ok...  I guess we can leave it for now then. If it becomes a more serious
>issue I'll let you know.
Ok. I know what's the problem is. Basically what happens is that we fill up socket 
tx buffer before MSC exchange completes (aclsession script does wait 10) and app goes to 
sleep in sendmsg(). Then we receive MSC and send 5 frames from tx buffer (we only 
send 5 frames at a time when credit flow ctl is not enabled). App is still sleeping 
at this point because sock_def_write_space() will not wakeup the process unless there
is a lot of room in the tx buffer. Eventually (after 30 secs) sendmsg() times out but
it doesn't return an error because it did manage to send a little bit. So the app will 
call sendmsg() again and send some more data, which will trigger tx queue processing 
and we will send 5 more frames, app goes to sleep again because buffer is still full 
and the cycle repeats. 
So it's should be obvious where the bug is :), it is in rfcomm_process_tx(). It's supposed
to reschedule DLC after it sends 5 packets. The reason it works for real world apps is 
because there is always some activity on the link which kicks tx processing.

Also the problem was somewhat hard to trigger before this patch from David went in
> >+++ core.c      Thu Apr  3 14:05:20 2003
> >@@ -1430,7 +1430,7 @@
> >        } else {
> >                /* CFC disabled.
> >                 * Give ourselves some credits */
> >-               d->tx_credits = RFCOMM_MAX_CREDITS;
> >+               d->tx_credits = 5;
> >        }
> >  
> >        if (test_bit(RFCOMM_TX_THROTTLED, &d->flags))

ie We used to send more frames and therefor managed free more tx buffer space and wake up application.

The fix is simple we just need to reschedule DLC when credit based flow control is not enabled. But I'm
not sure how often we need to do that. If we do it too often we'll essentially restore old behavior, too
seldom and performance will suffer. David, any suggestion ?

Max