Hi,
Indan Zupancic:
> E.g. some mechanism where the buffer size and buffer count is chosen
> dynamically depending on how fast the device turns out to be, and some
> latency constraints.
You can't measure how fast the device is. If you send too much too fast,
you simply get dropped or mangled data at the other end of the data link;
if you're doing PPP, completely wedging the channel, requiring a
reconnect or even a powercycle of the card to recover, is not at all
unlikely in my experience. :-(
I've even observed re-ordered data, which is why N_OUT_URB is currently
set to 1 -- which (together with OUT_BUFLEN=128, 'cause the damn card
sometimes dropped data with =256) *really* limits the send rate. Doesn't
matter for plain-and-simple GSM, but beyond that ... ouch.
The receive buffers, on the other hand, shouldn't require
parameterization. There are five of them per channel, and
they are large enough to catch whatever the card throws at us.
Hopefully.
There's also no way to ask for the current uplink data rate at the
driver's level. It'd need to send some AT-style command to the card,
which is a no-no because the user's GUI is more likely than not to hold
the other data port open, for text messages / incoming call indications.
I see no way to do this without previous knowledge about acceptable
buffer sizes and/or the availability of flow control.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf at smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
A little humility is arrogance.
-- Bill Gray
