Serial overrun errors
Steve Gibbs
I am getting good connection speeds with my UK 3Com/USR 56K Professional
Message Modem (45333-50666) but occasionally experience overrun errors
between 5 and 200 in a 60 minute period. The port advanced settings FIFO
levels are set at windows default figures and COM2 set at 115200 bps, using
hardware flow control. Motherboard is FIC VA-503+ & CPU = AMD K6-2 450.
I don't particularly wish to reduce connection speeds in order to solve
this, but wondered if the problem could lie elsewhere.
Regards
Steve
Hooda Gest
Steve Gibbs <lightso...@hotmail.com> wrote in message
news:8ht2rn$3n0ib$1...@fu-berlin.de...
It does lie elsewhere.... In Win98. I am going to assume you are running
Win98 even though you didn't mention it. This seems to be an effect of using
an external modem in Win98. There doesn't seem to be any real harm caused by
these overruns. If you really want to see them go away, you will probably
have to disable the onboard com ports and install a serial card with 16650
(32 byte buffer) UARTs. Other things that have been tried, with varying
success, is updating video and other drivers.
I have these overrun errors myself and see no real effect on throughput.
Your mileage may vary, however.
Hooda
Steve Gibbs
news:8htegl$2ie$1...@slb6.atl.mindspring.net...
> It does lie elsewhere.... In Win98. I am going to assume you are running
> Win98 even though you didn't mention it. This seems to be an effect of
using
> an external modem in Win98.
Yes Win98 SE.
> There doesn't seem to be any real harm caused by these overruns.
True - I don't appear to get disconnected as a result and throughput is
fine.
> I have these overrun errors myself and see no real effect on throughput.
> Your mileage may vary, however.
>
> Hooda
Thanks for your reply :-)
Regards,
Steve
Hooda Gest
One more comment on this... I notice that it is "Overrun Errors" which is
(are?) incremented in Sysmon rather than "Buffer Overruns". I don't
understand why the distinction unless the "Overrun Error" is an erroneous
report of an overrun.The way that might come about is an error flag is set
but the CRC for the supposedly affected data block is fine (meaning the data
was not corrupted). In that case, the error is insignificant since it
should not have any impact on throughput.
Just conjecture on my part.
Hooda
rain...@my-deja.com
Try turning down the port speed on your modem via
dial-up networking. I have also seen conflicts
between some video drivers and modem drivers that
caused com port overruns.
Tim
Sent via Deja.com http://www.deja.com/
Before you buy.
Hooda Gest
<rain...@my-deja.com> wrote in message news:8i1185$lo5$1...@nnrp2.deja.com...
>
>
> Try turning down the port speed on your modem via
> dial-up networking. I have also seen conflicts
> between some video drivers and modem drivers that
> caused com port overruns.
That's not good advice anymore. It used to be common advice but it really
doesn't apply now. Unless someone is using an unbuffered UART on an old
machine, the UART should handle these things just fine. The problem may not
really be a problem, as I said in another post. These don't really appear to
have any effect on throughput and are not pegged as Buffer overruns but as
"Overrun errors".
Since I use an external modem and Win98SE on my home machine, I monitored
both Buffer overruns and Overrun errors with Sysmon and found only the
latter being pegged. I also see no effect on throughput in spite of these
errors so my theory is they are, more or less, cosmetic in nature.
Hooda
Hooda Gest
Enk <em...@yahoo.com> wrote in message
news:394690cf$0$499$7f31...@news01.syd.optusnet.com.au...
> I remember having a dreadful time with internet gaming, with these
> overrun errors (they were always associated with crcs). An internal
> modem fixed the problem.
I hadn't paid much attention to the CRC errors but I will keep an eye on
them (just added that to Sysmon).
I'm not a gamer so that may be why I don't see that problem...
Definitely true that switching to an internal will end the Overrun errors.
The problem only occurs with Win98 and external modems. It does not happen
with internals. This is theoretically because the internals have a larger
buffer than the "standard" 16 byte buffer in the 16550 UART. People have
reported clearing them up by disabling the onboard com ports and installing
I/O cards with 16650 (32 byte buffer) UARTs.
Hooda
Enk
overrun errors (they were always associated with crcs). An internal
modem fixed the problem.
Hooda Gest <be@one_with.com> wrote in message
news:8i3l74$vpe$1...@slb0.atl.mindspring.net...
Franc Zabkar
finger to keyboard and composed:
>Since I use an external modem and Win98SE on my home machine, I monitored
>both Buffer overruns and Overrun errors with Sysmon and found only the
>latter being pegged. I also see no effect on throughput in spite of these
>errors so my theory is they are, more or less, cosmetic in nature.
I suspect that "Overrun errors" are those that occur when a 16-byte
UART FIFO overflows, and that "Buffer overruns" happen when a much
larger software buffer (several KB?) overflows. Hence the prevalence
of the former over the latter.
-- Franc Zabkar
Please remove one 'e' from my address when replying by email.
Franc Zabkar
Zabkar) put finger to keyboard and composed:
>On Mon, 12 Jun 2000 17:36:50 -0400, "Hooda Gest" <be@one_with.com> put
>finger to keyboard and composed:
>
>>Since I use an external modem and Win98SE on my home machine, I monitored
>>both Buffer overruns and Overrun errors with Sysmon and found only the
>>latter being pegged. I also see no effect on throughput in spite of these
>>errors so my theory is they are, more or less, cosmetic in nature.
>
>I suspect that "Overrun errors" are those that occur when a 16-byte
>UART FIFO overflows, and that "Buffer overruns" happen when a much
>larger software buffer (several KB?) overflows. Hence the prevalence
>of the former over the latter.
I am in the habit of checking my ppplog for errors after every
connection to the Internet and today for the first time I saw 1 Buffer
Overrun, 1 CRC Error, but no Overrun Errors. My log normally shows
zero errors for all three. The one previous exception was when the
modem failed to negotiate error correction. On that occasion three CRC
errors, but no overruns or buffer overruns, were detected. This time
the log showed that LAP-M error correction was successfully
negotiated. I'm using a "hard" internal modem in a Cyrix MII-333
system.
Coincidentally (?) my firewall logged an attempted attack on port
12345 which is used by the Netbus Trojan.
Hooda Gest
After enabling the CRC error monitoring in Sysmon, I found the CRC <>
Overrun error connection to be true. My fault for overlooking this.
As stated by someone else, the Buffer overruns probably refer to a different
buffer than the one in the UART.
Hooda
Hooda Gest <be@one_with.com> wrote in message
news:8i6cad$2kq$1...@slb6.atl.mindspring.net...
>
> Enk <em...@yahoo.com> wrote in message
> news:394690cf$0$499$7f31...@news01.syd.optusnet.com.au...
> > I remember having a dreadful time with internet gaming, with these
> > overrun errors (they were always associated with crcs). An internal
> > modem fixed the problem.
>
m...@here.com
> Definitely true that switching to an internal will end the Overrun errors.
> The problem only occurs with Win98 and external modems. It does not happen
> with internals. This is theoretically because the internals have a larger
> buffer than the "standard" 16 byte buffer in the 16550 UART.
That's not necessarily the case. Case in point, my Courier
v.Everything has only the 16550 UART.
Hooda Gest
<m...@here.com> wrote in message news:8i98d1$2p2$1...@schbbs.mot.com...
That's true, the Couriers had (or have, haven't seen newer ones) a physical
UART onboard. Why they work ok with Win98, I don't know, since that would
destroy that theory.
Hooda
Hooda Gest
> I read somewhere that a buffer overrun should always be associated
> with a crc, yet there was always a mismatch in the totals, after a
> long session(say, 500 overruns, but only 470 crcs over an hour or two
> after they began).
So far I have not seen a mismatch between the CRCs and the Overrun errors.
Again, these are not marked as Buffer overruns but as Overrun errors. I get
no Buffer overruns whatsoever.
>
> I also got rid of these by running an awful little pci winmodem for
> ages (actually, it was a great modem if u could get it to work). When
Well, "ages" must mean less than a 1 1/2 years... Since Win98 is when these
started showing up; Win95 (neither version had this problem). Or... you are
talking about a different problem entirely.
Hooda
> Hooda Gest <be@one_with.com> wrote in message
> news:8i7vmn$luq$1...@slb7.atl.mindspring.net...
> > Update:
> >
> > After enabling the CRC error monitoring in Sysmon, I found the CRC
> <>
> > Overrun error connection to be true. My fault for overlooking this.
> >
> > As stated by someone else, the Buffer overruns probably refer to a
> different
> > buffer than the one in the UART.
> >
> > Hooda
> >
> >
> >
> > Hooda Gest <be@one_with.com> wrote in message
> > news:8i6cad$2kq$1...@slb6.atl.mindspring.net...
> > >
> > > Enk <em...@yahoo.com> wrote in message
> > > news:394690cf$0$499$7f31...@news01.syd.optusnet.com.au...
> > > > I remember having a dreadful time with internet gaming, with
> these
> > > > overrun errors (they were always associated with crcs). An
> internal
> > > > modem fixed the problem.
> > >
> > > I hadn't paid much attention to the CRC errors but I will keep an
> eye on
> > > them (just added that to Sysmon).
> > >
> > > I'm not a gamer so that may be why I don't see that problem...
> > >
> > > Definitely true that switching to an internal will end the Overrun
> errors.
> > > The problem only occurs with Win98 and external modems. It does
> not happen
> > > with internals. This is theoretically because the internals have a
> larger
> > > buffer than the "standard" 16 byte buffer in the 16550 UART.
m...@here.com
> That's true, the Couriers had (or have, haven't seen newer ones) a physical
> UART onboard. Why they work ok with Win98, I don't know, since that would
> destroy that theory.
I'm not exactly sure how some of newer modems work, but I can
attest that Win98 has more bugs than a Texas mudhole.
Of course, the third party drivers are often not much better, either.
It's possible that interrupts for true HW modems (w/onboard UART)
are handled differently than for modems w/emulated UART (or no
UART at all!) + SW driver.
Another possibility is that the overrun errors have something to
do with the SW/HW installed, and it shows up only when the right
combination exists. If interrupts are disabled long enough,
buffer overruns are virtually unavoidable.
Enk
with a crc, yet there was always a mismatch in the totals, after a
long session(say, 500 overruns, but only 470 crcs over an hour or two
after they began).
I also got rid of these by running an awful little pci winmodem for
ages (actually, it was a great modem if u could get it to work). When
i removed the winmodem, and plugged external back in, and crcs/bo's
did not return until i installed a network card (this absence remained
for about 3 weeks). Naturally, uninstalling the network card did not
reverse the situation, once they had reappeared :P I've been unable
to duplicated it :(
Enk
Enk
this context :)
Hooda Gest <be@one_with.com> wrote in message
news:8ibceh$9sg$1...@slb7.atl.mindspring.net...
>
> Enk <em...@yahoo.com> wrote in message
> news:39493287$0$493$7f31...@news01.syd.optusnet.com.au...
> > I read somewhere that a buffer overrun should always be associated
> > with a crc, yet there was always a mismatch in the totals, after a
> > long session(say, 500 overruns, but only 470 crcs over an hour or
two
> > after they began).
>
> So far I have not seen a mismatch between the CRCs and the Overrun
errors.
> Again, these are not marked as Buffer overruns but as Overrun
errors. I get
> no Buffer overruns whatsoever.
>
> >
> > I also got rid of these by running an awful little pci winmodem
for
> > ages (actually, it was a great modem if u could get it to work).
When
>
> Well, "ages" must mean less than a 1 1/2 years... Since Win98 is
when these
> started showing up; Win95 (neither version had this problem). Or...
you are
> talking about a different problem entirely.
>
Jim Petersen
Excellent comments I've been following from you on this topic for some
time... I have a USR 56K external on a PII-266 with 96MB RAM, and of
course have had the overrun problem for several years. After reading
your comments earlier this year, I broke down and bought an internal
Zoom. No problems since, at all! The USR gathers dust...
A couple interesting points I'd like to add though, with which you may
not be familiar:
(1) I've had the problem ever since Win95, not just in Win98, so this
problem was also apparent in Win95. I thought getting Win98 would fix
the problem, but it didn't. Never have had success with external
modems in WinXX. (Tried other modems, other modem cables, etc., all to
no avail.)
(2) Amazingly, Linux (Redhat) also shows the problem with external
modems, but internal works fine with Redhat. Apparently then, this
problem is hardware-related, not just Windows-related; maybe something
to do with interrupt latency or precedence levels, as I think you said
in one of your notes. I believe my Zoom internal has a 16550, which
should be the standard 16-byte buffer. It shows up that way (i.e. 16
bytes) in the slider bar of the modem advanced settings dialog in
Win98. (I remember you suggesting internal modems might have 32-byte
buffers that alleviate the overrun problems.)
--Jim Petersen
In article <8ibceh$9sg$1...@slb7.atl.mindspring.net>,
Hooda Gest
Jim Petersen <jpet...@my-deja.com> wrote in message
news:8ieu5o$pn3$1...@nnrp1.deja.com...
> Hooda,
>
> Excellent comments I've been following from you on this topic for some
> time... I have a USR 56K external on a PII-266 with 96MB RAM, and of
> course have had the overrun problem for several years. After reading
> your comments earlier this year, I broke down and bought an internal
> Zoom. No problems since, at all! The USR gathers dust...
>
> A couple interesting points I'd like to add though, with which you may
> not be familiar:
>
> (1) I've had the problem ever since Win95, not just in Win98, so this
> problem was also apparent in Win95. I thought getting Win98 would fix
> the problem, but it didn't. Never have had success with external
> modems in WinXX. (Tried other modems, other modem cables, etc., all to
> no avail.)
If you had the problem in Win95 then you had some driver conflicts/problems;
probably with a video driver.
I have run externals for most of my modem uses and never ran into the
problem until upgraded to Win98SE from Win95. There were a couple of people
who had set up a dual boot with Win95 and Win98 and had these overrun errors
only in Win98. So we pretty much know the problem is with Win98 since it is
consistent there.
I ran Win95a at home and Win95b at work, both with external modems, for over
2 and 1 years, respectively and never had the problem until I upgraded to
Win98SE. I switched an internal modem at work a few months before I upgraded
to Win98SE and, of course, I get no overrun errors there.
>
> (2) Amazingly, Linux (Redhat) also shows the problem with external
> modems, but internal works fine with Redhat. Apparently then, this
> problem is hardware-related, not just Windows-related; maybe something
> to do with interrupt latency or precedence levels, as I think you said
> in one of your notes. I believe my Zoom internal has a 16550, which
> should be the standard 16-byte buffer. It shows up that way (i.e. 16
> bytes) in the slider bar of the modem advanced settings dialog in
> Win98. (I remember you suggesting internal modems might have 32-byte
> buffers that alleviate the overrun problems.)
The internals may emulate the buffered UART as opposed to actually having
one onboard. My theory was that the internal buffer was actually larger than
the 16 byte 16550 UART has even though Win98 only "sees" it as a 16 byte
buffer. Someone blew that out of the water by reminding me of the Courier's
uses of an actual 16550 UART.
The fact that you get these overruns in Linux of any type suggests there is
some other interrupt latency problem in your system. But I couldn't say for
sure.
Hooda
Rick Collins
"Art Jackson" <artj...@mindspring.com> wrote in message
news:394C403A...@mindspring.com...
> Hooda Gest wrote:
> >
> > <m...@here.com> wrote in message news:8i98d1$2p2$1...@schbbs.mot.com...
> > > Hooda Gest <be@one_with.com> wrote:
> > >
> > >
Overrun
> > errors.
> > > > The problem only occurs with Win98 and external modems. It
does not
> > happen
> > > > with internals. This is theoretically because the internals
have a
> > larger
> > > > buffer than the "standard" 16 byte buffer in the 16550 UART.
> > >
> > > v.Everything has only the 16550 UART.
> >
physical
> > UART onboard. Why they work ok with Win98, I don't know, since
that would
> > destroy that theory.
> >
>
> I ran into a curious result of an Intel utility to read the UART
> type of all COM ports. When I run it on my system, it reads the
> two serial ports as 16550A and the internal 3COM 5687-03 as a
> 16450 UART. Strange??????
Not really. Many programs cannot ID UARTS properly - and that's
especially true if only "16550 functionality" is being provided.
Art Jackson
>
> <m...@here.com> wrote in message news:8i98d1$2p2$1...@schbbs.mot.com...
> > Hooda Gest <be@one_with.com> wrote:
> >
> >
> > > Definitely true that switching to an internal will end the Overrun
> errors.
> > > The problem only occurs with Win98 and external modems. It does not
> happen
> > > with internals. This is theoretically because the internals have a
> larger
> > > buffer than the "standard" 16 byte buffer in the 16550 UART.
> >
> > That's not necessarily the case. Case in point, my Courier
> > v.Everything has only the 16550 UART.
>
> That's true, the Couriers had (or have, haven't seen newer ones) a physical
> UART onboard. Why they work ok with Win98, I don't know, since that would
> destroy that theory.
>
> Hooda
I ran into a curious result of an Intel utility to read the UART
type of all COM ports. When I run it on my system, it reads the
two serial ports as 16550A and the internal 3COM 5687-03 as a
16450 UART. Strange??????
--
Art Jackson W4TOY Owensboro, KY USA
email: artj...@mindspring.com
When all else fails, read THE instructions.
Found in the HOLY BIBLE God Bless
m...@here.com
> I ran into a curious result of an Intel utility to read the UART
> type of all COM ports. When I run it on my system, it reads the
> two serial ports as 16550A and the internal 3COM 5687-03 as a
> 16450 UART. Strange??????
Pretty much everything is compatible with the 16450, so better
UARTs might be recognized that because the 16450 is the lowest
common denominator nowadays. Some 3Com modems have discrete
UARTs, and you can just take a look at the board. If it's
an emulated UART then all bets are off, both finding it and
correctly reconizing it with a generic program that looks for
a hardware UART.
Franc Zabkar
<artj...@mindspring.com> put finger to keyboard and composed:
>Hooda Gest wrote:
>>
>> <m...@here.com> wrote in message news:8i98d1$2p2$1...@schbbs.mot.com...
>> > Hooda Gest <be@one_with.com> wrote:
>> >
>> >
>> > > Definitely true that switching to an internal will end the Overrun
>> errors.
>> > > The problem only occurs with Win98 and external modems. It does not
>> happen
>> > > with internals. This is theoretically because the internals have a
>> larger
>> > > buffer than the "standard" 16 byte buffer in the 16550 UART.
>> >
>> > That's not necessarily the case. Case in point, my Courier
>> > v.Everything has only the 16550 UART.
>>
>> That's true, the Couriers had (or have, haven't seen newer ones) a physical
>> UART onboard. Why they work ok with Win98, I don't know, since that would
>> destroy that theory.
>>
>> Hooda
>
>I ran into a curious result of an Intel utility to read the UART
>type of all COM ports. When I run it on my system, it reads the
>two serial ports as 16550A and the internal 3COM 5687-03 as a
>16450 UART. Strange??????
I've always been puzzled why so many utilities have difficulty in
correctly identifying UART types.
AFAIK, to identify a UART type one need only be aware of the following
differences:
8250 - lacks a scratchpad register and FIFO
16450 - lacks a FIFO
16550 - has a 16 byte FIFO
The following DEBUG subcommands test for the presence of a scratchpad
register at COM2:
DEBUG
-o 2ff aa (o = oh, not zero)
-i 2ff
AA (bit pattern 10101010)
-o 2ff 55
-i 2ff
55 (bit pattern 01010101)
If the data written to port 2ff is correctly read back, then a
scratchpad register exists.
The following DEBUG subcommands test for the presence of a FIFO at
COM2:
DEBUG
-o 2fa 1
-i 2fa
C1 (if FIFO exists)
01 (if no FIFO)
After writing a 1 to port 2fa, if the two highest bits are set to 1,
then the UART has a FIFO buffer.
Franc Zabkar
to keyboard and composed:
>I read somewhere that a buffer overrun should always be associated
>with a crc, yet there was always a mismatch in the totals, after a
>long session(say, 500 overruns, but only 470 crcs over an hour or two
>after they began).
I have had one occasion where I experienced three CRC errors but no
overruns or buffer overruns. At that time error correction was not
enabled. The CRC errors occurred because some data bits were
corrupted, probably due to line noise. No overrun errors were
registered because no data bytes were lost. Simply said, CRC errors
were the result of bad data, not lost data.
In your case it appears that your system cannot keep up with the data
rate, ie your CRC errors are the result of lost data. A CRC error is
generated whenever one _or more_ bytes is dropped from any packet. It
appears that in the majority of cases you are losing only one byte
from the affected packets. However, there are a significant number of
instances (~30) where you are dropping two or more bytes per packet.
Bob
<be@one_with.com> writes
>
>Enk <em...@yahoo.com> wrote in message
>news:394690cf$0$499$7f31...@news01.syd.optusnet.com.au...
>> I remember having a dreadful time with internet gaming, with these
>> overrun errors (they were always associated with crcs). An internal
>> modem fixed the problem.
>
>I hadn't paid much attention to the CRC errors but I will keep an eye on
>them (just added that to Sysmon).
>
>I'm not a gamer so that may be why I don't see that problem...
>
>The problem only occurs with Win98 and external modems. It does not happen
>with internals. This is theoretically because the internals have a larger
>reported clearing them up by disabling the onboard com ports and installing
>I/O cards with 16650 (32 byte buffer) UARTs.
>
>Hooda
>
Hello Hooda,
I've also made the observation that all other software being unchanged,
use of internal or external modem alone made the difference between
significant overrun errors or none.
I was likewise pretty convinced that buffer sizes and trigger thresholds
would figure in this, with processor speed probably linearly (more or
less) affecting the presumed interrupt latency problem.
So I have extreme problems in explaining my current Win98 observations
as follows:-
System 1 350MHz Pentium I, 64Mb RAM (mode 4 PIO hard drive
5000rpm) external USR Courier or 3COM/USR pro msg
Never seen a problem with this system with 100's of hours of
connect time.
System 2 200MHz Pentium, 96Mb RAM (similar WD hard drive)
same modems tried as above.
Immediately after a reboot I can run this 2nd system with 115kb
serial connection (confirmed set in the DUN) for about 1/4 to
1/2 an hour, then the overrun errors begin to creep in and once
started will continue ad infinitum.
Immediately after re-booting, I can run DOS boxes, IE5, etc., thrashing
the hard drive and thrashing the display whilst downloading at peaks of
13k - 14k cps (49kb connection with compression..) with not a single
error. Then after around this 15 - 30 minute period the errors begin to
creep in, singly or in bursts of 3 or 4 at an average of 4 or 5 per
minute. If I reboot again and do nothing else but run my mail/new client
(Turnpike) then after the same 15 -30 mins the same thing will happen.
So, I assumed that this system must be somewhere close to the latency
threshold and that moving the FIFO trigger point or slowing the serial
comm port rate should make a noticeable difference. It doesn't!
When I restrict the serial comm port to a mere 33.6k (in the DUN and in
Device Mngr/Modem and /ports just to be sure) I get the same result. I
can see the reported incoming data rate slowed down to a maximum of 3k -
3.5k cps so I know that the interrupt rate must have dropped
accordingly, and thus the required latency *should* have increased
nearly fourfold.
I would have expected that setting the 16550 FIFO threshold to 8 bytes
from 14 would have made a measurable difference, but in line with other
comments noted in these groups, it doesn't seem to.
I've tried to correlate the onset of errors with the growth in size of
the disc cache and with the appearance of the Windows swapfile, (which
is zero after a reboot) but although I'm still suspicious about the
swapfile, no direct connection seems to exist. I've even physically
removed RAM, or filled it with RAM disc to see what happens and still
the 15 - 30 min delay seems to be about the same.
So for the moment, I conclude that something in the behaviour of W98
does change with time after a reboot, and the change in latency isn't
subtle!!
Any thoughts or ideas?
rgds,
--
Bob b...@furfax.demon.co.uk
Hooda Gest
Bob <b...@furfax.demon.co.uk> wrote in message
news:msY7JJAp...@furfax.demon.co.uk...
[trimmed]
Nice job of testing and analisys...
> So for the moment, I conclude that something in the behaviour of W98
> does change with time after a reboot, and the change in latency isn't
> subtle!!
>
> Any thoughts or ideas?
Yes... Bill Gates wants everyone to use internal modems. :)
Hooda