On Nov 16, 1995 I had asked,
Hardware DECpc 150 AXP, US Robotics 28.8kbps V.34 Sportster modem
Software D*UNIX V3.2B, PPP V2.2(Steve Tate's implementation srt_at_cs.unt.edu).
Ocassionally, in dxconsole window while running FTP, I see error messages
like
acerint: error, overflow status = 62 (or 63) (...not sure about this...)
ace1: input silo overflow
Should I be concerned about these messages? I see CRC errors from the
Windows NT 3.51 on the same hardware, are these errors the same?
I had three replies from
Gyula Szokoly (szgyula_at_skysrv.Pha.Jhu.EDU)
Ross Alexander(rwa_at_cs.athabascau.ca)
Thanks guys...
Here are their suggestions and answers,
Gyula says,
Not quite, but:
1. Make sure you are using hardware flow control (modem AND machine).
2. Don't go above 38400. Actually only 19200 is supported as far as I know
(at
least on the 3000 series machine -- not sure about the 150).
Since PPP does error detection, you loose only some bandwidth.
Gyula also suggested some changes as follows:
I use getty, and the relevant line in /etc/gettydefs is (one line):
38400NP# B38400 OPOST ONLCR TAB3 IGNPAR IXON IXANY ISTRIP ECHO ECHOE ECHOK
ISIG CS8 CREAD HUPCL CLOCAL # B38400 OPOST ONLCR SANE TAB3 IGNPAR IXON IXANY
ISTRIP ECHO ECHOE ECHOK ISIG CS8 CREAD HUPCL #login: #38400NP
/etc/inittab looks like (relevant line):
dialup:23:respawn:/usr/sbin/getty -h /dev/tty00 38400NP vt100
Ross provided the following insight:
I have a strong suspicion (based on having used many of them for
client PPP support) that the USR modems are a little slow to respond
to transitions on the RTS/CTS flowcontrol lines, and that lag is
enough to overflow the 16550afn input FIFO, which is only 16
characters deep. At 56 kbaud, 16 chars isn't a long time. I can't
remember if there's a way to set the receive FIFO trigger depth or not
(the hardware can trigger on 1, 4, 8, or 14 characters in the FIFO)
but if so try setting it lower.
And yes, I'd expect that the two diagnostics are about the same underlying
problem.
As far as being concerned, I'd worry only if you're dropping a lot of
packets on the floor and getting poor transfer rates - the TCP stack
handles the problem very nicely via retransmission. A few silo overflows
an hour can be ignored - but 1000's would be a distinct problem.
As Ross suggests, I see only a few errors per hour, which I'll probably live
with for the time being, till I can do some more research and add some more
info to this.
.Tushar.
Received on Mon Nov 20 1995 - 18:23:47 NZDT