From: jim@n5ial.mythical.com (Jim Graham) Subject: Re: 38400 or 57600 baud, which to use? With what FIFO trigger setting? Date: Fri, 6 Aug 1993 14:42:21 GMT
In article <1993Aug4.200222.3018@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro)
writes:
> Okay, I have a USRobotics 9600 Sportster modem, which I use to
>connect to the university through a terminal server, which supports
>V42bis. The modem can handle speeds up to 57600 to and from the
>computer (it can't do 115.2 Kbaud, I tried :( ). With it running at
>57,600 I have seen transfer rates up to 28 K baud, so I know I should
>keep the port rate at at least 38400.
I'm assuming here that the USR 9600 Sportster supports V.32, but not
V.32bis (as implied by the name). If this is the case (sorry, I haven't
spent much...ok, any...time with the Sportster line from USR), then
38.4 kb is PROBABLY as high as you'll need to set the serial port.
A plain V.32/V.42 connection (i.e., async-to-sync conversion is active)
will provide approximately 1100 cps to 1150 cps. Let's be optimistic
and use 1150 cps---this is probably closer to what you'll see (minus any
protocol overhead for file transfers). If V.42bis is to extend beyond
38.4 kb, that would need to be 3840 cps, or a 3.34:1 compression ratio.
In other words, you're ok for MOST applications at that speed.
Now, if you're actually using V.32bis, you'll want 57.6 kb as long as it
doesn't cause any problems.
Also, you indicate that the system is doing ok at 57.6 kb, so as long as
this is the case, personally, I'd set it at 57.6 kb. Of course, I can't
do this, because the USR DS I have (large footprint, square LEDs, V.32bis)
can't handle a port speed higher than 38.4 kb. :-( Be *ABSOLUTELY* sure
that you have the flow control set to use hardware flow (RTS/CTS).
> Also, what should I be thinking of setting the 16550 FIFO
>trigger at?
[....]
> Too low a setting I've gathered increases load, but I also
>seem to think that too high a setting could result in overruns or
>higher delays
Well, let's start by eliminating 1 and 14. Setting the trigger level at
1 byte virtually eliminates one of the strengths of the 16550---the
ability to issue one interrupt for multiple bytes. On the other hand,
setting the trigger level to 14 is pretty dangerous---the FIFO is almost
full when you issue the interrupt, and if the system load happens to be
pretty high at the moment (with higher-priority interrupts all over the
place), you are likely to see some data overruns...not good.
This leaves us with trigger levels of 4 and 8 bytes. These values provide
for a balance between the number of interrupts issued and the delay. As
for which is better, there isn't an easy/exact answer to that one. :-)
I'd say do tests with both, and see which one gives you the best overall
performance in the applications you have in mind.
>(yes, I know about the counter timer interrupt, but the
>delay is still non-negligable).
The delay is only 4 character times at the port speed setting. In other
words, at a port speed of 57.6 kb, the delay will be 0.694 ms, and at a
port speed of 38.4 kb, the delay will be 1.042 ms. Not too substantial
(normally). Of course, we have to add the delay for characters that are
already in the FIFO (after all, they did take time to get there). So
assuming a port speed of 57.6 kb, and trigger_level - 1 characters in the
FIFO before the pause, a trigger setting of 4 bytes could give as much
delay as 1.215 ms (7 character times), and a trigger setting of 8 bytes
could give as much delay as 1.910 ms (11 character times). This might
just end up being a problem.
Btw, how sensitive is SLIP (or PPP) to delays in this range?
--jim