why won't write-behind stay disabled?

On Fri, 27 Jan 2006 04:57:36 +0200, "cquirke (MVP Windows shell/user)"
put finger to keyboard and composed:

On Sun, 22 Jan 2006 19:42:26 GMT, (Olive) wrote:

In a nutshell the link between drive write-behind and internet surfing
is this quote "Anything that prevents your CPU from responding quickly
enough to interrupts from your UART can cause overruns."
http://www.cerberus-sys.com/~belleis...aq/overrun.htm

This is true, though the significance varies.

Firstly, do this (sorry, no baby-steps; RTFM):
- find and rename away the modem log
- enable modem logging, append to log
- do your web surfing, etc.
- peruse log for serial port overruns

I'd suggest a worst case test. Set COM port rate to maximum, enable
error correction and modem data compression, disable software
compression, and monitor modemlog and ppplog for serial overruns,
buffer overruns, and CRC errors. Create an "infinitely" compressible
text file consisting of a single letter repeated 1 million times.
Email this file to yourself or ftp it to and from your webspace. Watch
the throughput using sysmon.exe. This test should saturate your COM
port.

See my test results elsewhere in this thread.

If no serial port overruns, forget this issue.
If some, then try the following...
- reduce modem COM port speed
- set UART buffer to trigger interrupt after fewer bytes

If some overruns, then compare their frequency with the total bytes
received. Overruns are correctable errors which, if small in number,
will have no perceptible impact on throughput. In most cases you can
ignore them.

See my test results elsewhere in this thread.

Again, no baby-steps; e.g. I'm not going to describe what the modem
log is called, how to find files, where to change these settings :-)

Also, check the UART your modem uses. An ancient modem may contain an
unbuffered UART, and an ancient serial port card may contain an
unbuffered UART to which an external modem is connected.

Use MSD from DOS mode to check what UARTs you have; I can't remember
the actual namesaccurately, but AFAICR 16550 is OK (16-byte buffer)
whereas 8450 is Bad (1-byte "buffer") and 14550 is also Bad.

8250 and 16450.

Strictly speaking, I don't believe MSD is able to correctly
differentiate between the two bufferless UARTs (8250 and 16450),
although the distinction is moot in this case:

http://groups.google.com/group/comp....e=source&hl=en

BTW, MSD also fails to correctly identify a baud rate of 115200,
showing it as 49664 instead. This is because MSD limits the baud rate
to a two-byte value.

115200 dec = 1c200 hex
c200 hex = 49664 dec

Sandi, as for my definition of of internet speed, all things being
equal, a 56K modem should at best give you an average speed of 7.0
Kbytes per sec (K/sec). My average seldom went beyond 2.3K.sec.

Modem speed is in bits per second, and as communications adds extra
bits (framing, stop, start, whatever - generally 2 fluff bits per 8
data bits per byte) you divide this by 10 for the max bytes per sec.

That's only true for the DTE interface, ie the path between COM port
and modem. The modem-to-modem interface (DCE) differs in that data are
packetised (if error correction is enabled, as it almost always is).
These packets consist of, say, 256 8-bit data bytes (framing bits are
discarded) and a small number of header bytes. The effective
bits-per-byte is therefore somewhere between 8 and 9.

See my test results elsewhere in this thread.

So let's assume a 56k modem connects at 50k (which is really
best-case), you'd expect a maximum byte rate of 5k, all things being
equal.

It would be closer to 5.5KB/s. At 46667bps my throughput is a steady
5.1 - 5.2 KB/s, according to sysmon.exe.

The modem can compress data up to 4 times,

True, but only for highly compressible data, eg some newsgroup
headers. The typical compression ratio for V.42bis (V.90) is 2:1 for
text, and 3:1 for V.44 (V.92).

so the best-case
modem throughput could be as high as 20k, as long as the serial poert
speed can cope. In practice, your modem traffic is either
intermittent scraps of uncompressed HTML, or already-compressed .GIF,
.JPG, .ZIP and self-extracting installer .EXE, so 5k is best-case.

In practice, the best I expect to see is 2 - 2.5k on downloads, unless
I use a download accelerator [*1] to pull the same file down from 4
points in the file at the same time (like a 4-lane highway); then I
get 4k+ that would be close to max on typical 41k, 44k, 49k connects.

If your connect speeds are really that inconsistent, then I would
suspect a phone line issue. You need to query your modem's last call
diagnostic report to find out what is really going on.

See my other post in this thread, or pop over to comp.dcom.modems.

[*1] Use a clean download accelerator like Star Downloader, rather
than Download Accelerator Pus or something similar that's infected
with commercial malware

I very rarely encounter slow web sites these days, so in my case a
download accelerator would be an unnecessary complication. Instead I'd
suggest that the OP first interrogate her modem before trying to "fix"
the Internet.

One final important point. The previous discussion assumes that the OP
has an external serial (RS232) modem. It may be that she has an
internal soft or controllerless modem, in which case it will have a
virtual COM port, with an emulated UART, and will therefore be immune
to overrun errors. It will also be insensitive to port rate settings
and FIFO buffer trigger points. This is because the concept of port
rate only makes sense for a real, single-wire interface. Also, the
"FIFO buffer" is in system RAM or on the modem card, so its status is
visible to the modem's controller. This means that the controller
knows not to add to the buffer when it is full. That's probably why
turning off the FIFO in one of my tests generated no overruns.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.