Hi,
I'm not so sure about the mtt theory since the stack will always use a
bit of time before sending the next frame (protocol processing), so there
will always be a little delay before sending the first frame. Note that
the transceivers used in mobile phones usually have limited range (30
cm), so you might get problems if you use a longer distance between your
dongle and the phone.
Anyway, an irdadump should tell us what's wrong.
-- Dag
On Thu, 15 Nov 2001 20:46:26 +0100 (CET), Martin Diehl wrote:
> On Wed, 14 Nov 2001, Andrea Arcangeli wrote:
>
> > > Using the RS232 cable, I get TCP throughput of around 3.6KB/s
> > > (28.8Kb/s). Using IrDA with an identical setup (and phone
> > > position) I get only 1.2KB/s. I've tried all the obvious things
> > > like changing the distance between the Ir sensors etc.
> >
> > the latency is horrible for me too (order of seconds), but never tried
> > without irda stack in the middle (I simply don't have the cable :).
> >
> > There seems to be some huge packet loss here too. However I never
>
> Ok. Despite not having a T39 it seems my first guess with the MIR problem
> was a hit - so lets go for another one:
>
> >From the other guy's report I've seen the T39m announces it would announce
> min turn time =0 (or more, of course). While this is perfectly legal from
> IrLAP protocol it would mean our stack is granted to start transmission
> immediately after the phone finished transmitting, i.e. without applying
> any delay to let the T39 receiver recover from saturation. Concerns me
> somewhat whether this would be what the specs for the transceiver say.
> In most cases the transceiver need some time to recover (1-5 msecs for
> most standard devices I've seen). If this fails the first packet to the
> phone would arrive while it's still saturated and gets lost. Our stack is
> then required to wait up to 500 msec before retry - would IMHO perfectly
> explain the bad performance.
>
> So, if you like, lets try to confirm (or rule out) this: The patch below
> adds sysctl net.irda.min_tx_turn_time and uses this is a lower limit for
> the turn time delay to be used for the other end. Hence setting
> /proc/sys/net/irda/min_tx_turn_time to 1000 or 5000 (usec) forces the irda
> stack to overrule the pretty optimistic value from the T39m.
>
> Any improvement detectable with this?
>
> Martin
>
> ------------------------------
>
> diff -ur linux-2.4.14/net/irda/irsysctl.c v2.4.14-md/net/irda/irsysctl.c
> --- linux-2.4.14/net/irda/irsysctl.c Sun Sep 30 15:55:37 2001
> +++ v2.4.14-md/net/irda/irsysctl.c Thu Nov 15 20:12:21 2001
> @@ -33,7 +33,8 @@
>
> #define NET_IRDA 412 /* Random number */
> enum { DISCOVERY=1, DEVNAME, DEBUG, SLOTS, DISCOVERY_TIMEOUT,
> - SLOT_TIMEOUT, MAX_BAUD_RATE, MAX_INACTIVE_TIME, LAP_KEEPALIVE_TIME, };
> + SLOT_TIMEOUT, MAX_BAUD_RATE, MAX_INACTIVE_TIME, LAP_KEEPALIVE_TIME,
> + MIN_TX_TURN_TIME };
>
> extern int sysctl_discovery;
> extern int sysctl_discovery_slots;
> @@ -45,6 +46,7 @@
> extern int sysctl_max_baud_rate;
> extern int sysctl_max_inactive_time;
> extern int sysctl_lap_keepalive_time;
> +extern unsigned sysctl_min_tx_turn_time;
>
> #ifdef CONFIG_IRDA_DEBUG
> extern unsigned int irda_debug;
> @@ -92,6 +94,8 @@
> sizeof(int), 0644, NULL, &proc_dointvec },
> { LAP_KEEPALIVE_TIME, "lap_keepalive_time", &sysctl_lap_keepalive_time,
> sizeof(int), 0644, NULL, &proc_dointvec },
> + { MIN_TX_TURN_TIME, "min_tx_turn_time", &sysctl_min_tx_turn_time,
> + sizeof(unsigned), 0644, NULL, &proc_doulongvec_minmax },
> { 0 }
> };
>
> diff -ur linux-2.4.14/net/irda/qos.c v2.4.14-md/net/irda/qos.c
> --- linux-2.4.14/net/irda/qos.c Sat Aug 4 13:24:16 2001
> +++ v2.4.14-md/net/irda/qos.c Thu Nov 15 20:21:22 2001
> @@ -51,6 +51,14 @@
> * Remember that the threshold time (early warning) is fixed to 3s...
> */
> int sysctl_max_inactive_time = 12;
> +/*
> + * Minimum turn time to be applied before transmitting to the peer.
> + * Nonzero values (usec) are used as lower limit to the per-connection
> + * mtt value which was announced by the other end during negotiation.
> + * Might be helpful if the peer device provides too short mtt.
> + * Default is 0 which means using the unmodified value given by the peer.
> + */
> +unsigned sysctl_min_tx_turn_time = 0;
>
> static int irlap_param_baud_rate(void *instance, irda_param_t *param, int get);
> static int irlap_param_link_disconnect(void *instance, irda_param_t *parm,
> @@ -280,6 +288,23 @@
> int index;
>
> IRDA_DEBUG(2, __FUNCTION__ "()\n");
> +
> + if (sysctl_min_tx_turn_time > qos->min_turn_time.value) {
> + u8 bits;
> +
> + bits = 0x80; /* type 1 parameter - only MSB set */
> + for (index = 0; index <
>sizeof(min_turn_times)/sizeof(*min_turn_times); index++) {
> + if (sysctl_min_tx_turn_time >= min_turn_times[index])
> + break;
> + bits >>= 1;
> + }
> + if (!bits)
> + bits = 0x01; /* IrLAP: max. mtt 10ms */
> +
> + sysctl_min_tx_turn_time = min_turn_times[index]; /* adjust to official
>value */
> + qos->min_turn_time.bits = bits;
> + qos->min_turn_time.value = min_turn_times[index];
> + }
>
> /*
> * Not allowed to use a max turn time less than 500 ms if the baudrate
>
> _______________________________________________
> Linux-IrDA mailing list - [EMAIL PROTECTED]
> http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
>
>
>
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
