Greg Pomerantz <[email protected]> and I have found that Novatel Merlin
for Ricochet PCMCIA card, while looking like otherwise ordinary serial
PCMCIA device, has the receive buffer 576 bytes long. When regular serial
driver reads the arrived data, it often runs out of 512-bytes flip buffer
and discards the rest of the data with rather disastrous consequences for
whatever is expecting it.
We made a fix that changes the behavior of the driver, so when it fills
the flip buffer while characters are still being read from uart, it flips
the buffer if it's possible or if it's impossible, finishes the loop
without reading the remaining characters.
The patch is:
---8<---
--- linux-2.4.1-orig/drivers/char/serial.c Wed Dec 6 12:06:18 2000
+++ linux/drivers/char/serial.c Thu Feb 1 13:14:05 2001
@@ -569,9 +569,16 @@
icount = &info->state->icount;
do {
+ /*
+ * Check if flip buffer is full -- if it is, try to flip,
+ * and if flipping got queued, return immediately
+ */
+ if (tty->flip.count >= TTY_FLIPBUF_SIZE) {
+ tty->flip.tqueue.routine((void *) tty);
+ if (tty->flip.count >= TTY_FLIPBUF_SIZE)
+ return;
+ }
ch = serial_inp(info, UART_RX);
- if (tty->flip.count >= TTY_FLIPBUF_SIZE)
- goto ignore_char;
*tty->flip.char_buf_ptr = ch;
icount->rx++;
--->8---
I also propose to increase the size of flip buffer to 640 bytes (so the
flipping won't occur every time in the middle of the full buffer), however
I understand that it's a rather drastic change for such a simple goal, and
not everyone will agree that it's worth the trouble:
---8<---
--- linux-2.4.1-orig/include/linux/tty.h Mon Jan 29 23:24:56 2001
+++ linux/include/linux/tty.h Wed Jan 31 13:06:42 2001
@@ -134,7 +134,7 @@
* located in the tty structure, and is used as a high speed interface
* between the tty driver and the tty line discipline.
*/
-#define TTY_FLIPBUF_SIZE 512
+#define TTY_FLIPBUF_SIZE 640
struct tty_flip_buffer {
struct tq_struct tqueue;
--->8---
--
Alex
> I also propose to increase the size of flip buffer to 640 bytes (so the
> flipping won't occur every time in the middle of the full buffer), however
> I understand that it's a rather drastic change for such a simple goal, and
> not everyone will agree that it's worth the trouble:
Going to a 1K flip buffer would make sense IMHO for high speed devices too
On Thu, 1 Feb 2001, Alan Cox wrote:
> > I also propose to increase the size of flip buffer to 640 bytes (so the
> > flipping won't occur every time in the middle of the full buffer), however
> > I understand that it's a rather drastic change for such a simple goal, and
> > not everyone will agree that it's worth the trouble:
>
> Going to a 1K flip buffer would make sense IMHO for high speed devices too
1K flip buffer makes the tty_struct exceed 4096 bytes, and I don't think,
it's a good idea to change the allocation mechanism for it.
--
Alex
Hi Alex!
I'm a little confused here... why are we overrunning? This thing is
running externally at 19200 at best, even if it does all come in as a
packet. I would think the flip buffer would never contain more than a
few characters. Are you running it at a higher rate internally? Does it
buffer up a whole packet if you do this?
Wouldn't it be a little easier to drop somthing like "AT#MRU=500\r" to
the modem than to change the tty driver?
--
Joe
Alex Belits wrote:
> On Thu, 1 Feb 2001, Alan Cox wrote:
>
>
>>> I also propose to increase the size of flip buffer to 640 bytes (so the
>>> flipping won't occur every time in the middle of the full buffer), however
>>> I understand that it's a rather drastic change for such a simple goal, and
>>> not everyone will agree that it's worth the trouble:
>>
>> Going to a 1K flip buffer would make sense IMHO for high speed devices too
>
>
> 1K flip buffer makes the tty_struct exceed 4096 bytes, and I don't think,
> it's a good idea to change the allocation mechanism for it.
On Thu, 1 Feb 2001, Joe deBlaquiere wrote:
> Hi Alex!
>
> I'm a little confused here... why are we overrunning? This thing is
> running externally at 19200 at best, even if it does all come in as a
> packet.
Different Merlin -- original Merlin is 19200, "Merlin for Ricochet" is
128Kbps (or faster), and uses Metricom/Ricochet network.
--
Alex
How does this relate to IrDA with SIR speed of 115200 and max turnaround
of 500ms?
The max throughput is about 5000 bytes in 500ms.
Garst
Alex Belits wrote:
> On Thu, 1 Feb 2001, Joe deBlaquiere wrote:
>
>
>> Hi Alex!
>>
>> I'm a little confused here... why are we overrunning? This thing is
>> running externally at 19200 at best, even if it does all come in as a
>> packet.
>
>
> Different Merlin -- original Merlin is 19200, "Merlin for Ricochet" is
> 128Kbps (or faster), and uses Metricom/Ricochet network.
so can you still limit the mru?
--
Joe
On Thu, 1 Feb 2001, Joe deBlaquiere wrote:
> >> I'm a little confused here... why are we overrunning? This thing is
> >> running externally at 19200 at best, even if it does all come in as a
> >> packet.
> >
> >
> > Different Merlin -- original Merlin is 19200, "Merlin for Ricochet" is
> > 128Kbps (or faster), and uses Metricom/Ricochet network.
>
> so can you still limit the mru?
No. And even if I could, there is no guarantee that it won't fill the
whole buffer anyway by attaching head of the second packet after the tail
of the first one -- this thing treats interface as asynchronous and
ignores PPP packets boundaries.
--
Alex
Hi!
> > I also propose to increase the size of flip buffer to 640 bytes (so the
> > flipping won't occur every time in the middle of the full buffer), however
> > I understand that it's a rather drastic change for such a simple goal, and
> > not everyone will agree that it's worth the trouble:
>
> Going to a 1K flip buffer would make sense IMHO for high speed devices too
Actually bigger flipbufs are needed for highspeed serials and
irda. Tytso received patch to make flipbuf size settable by the
driver. (Setting it to 1K is not easy, you need to change allocation
mechanism of buffers.)
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
On Fri, 9 Feb 2001, Pavel Machek wrote:
> > > I also propose to increase the size of flip buffer to 640 bytes (so the
> > > flipping won't occur every time in the middle of the full buffer), however
> > > I understand that it's a rather drastic change for such a simple goal, and
> > > not everyone will agree that it's worth the trouble:
> >
> > Going to a 1K flip buffer would make sense IMHO for high speed devices too
>
> Actually bigger flipbufs are needed for highspeed serials and
> irda. Tytso received patch to make flipbuf size settable by the
> driver. (Setting it to 1K is not easy, you need to change allocation
> mechanism of buffers.)
The need for changes in allocation mechanism was the reason why I have
limited the buffer increase to 640 bytes. If changes already exist, and
there is no some hidden overhead associated with them, I am all for it.
Still it's not a replacement for the change in serial driver that I have
posted -- assumption that hardware is slower than we are, that it has
limited buffer in the way, and that it's ok to discard all the data beyond
our buffer's size is, to say least, silly.
--
Alex