I've been struggling with two IrDA stations in achieving optimal=20
transfer rates between them. Both IRda devices are FIR capable, but one=20
has slightly different negotiation parameters then the other. Eg. window=20
size is 7 for device1 and 3 for device2.
After negotiation devices agree on different window size parameters=20
(which is OK). During transfer though window size and max turn time play=20
major role in transfer latency.
device1 as primary station (window_size 3, max_turn 500ms)
device2 as secondary station (window_size 7, max_turn 500ms)
- device1 is sending data
- device2 is receiving data
- transfer speed is ~300kbps
In this case data is transfered with no delay (or very little delay).=20
irdadump shows that receiving station (device1) responds with I or RR=20
frame every 7th frame.
- device1 is receiving data
- device2 is sending data
- transfer speed is ~3kbps
In this case data is transfered with great latency. irdadump shows that=20
primary receiving station responds with I or RR frame every 3th frame.=20
The problem is - primary station almost always waits max_turn time for=20
secondary station to timeout. After timeout, link is turned around, and=20
primary can send RR / more data.
Shouldn't Fast RR kernel config option handle this kind of scenario?
My expectations were, that enabling fast RR would send RR packet (and=20
turn link around) from primary station immediately after secondary sent=20
negotiated number of frames that primary can receive in one window,=20
without waiting for max_turn timeout.
=C4=8CETRTA POT, d.o.o., Kranj
Tel. +386 (0) 4 280 66 37
Get latest updates about Open Source Projects, Conferences and News.