View Single Post
  #42  
Old January 28th 06, 04:18 PM posted to microsoft.public.win98.setup
external usenet poster
 
Posts: n/a
Default why won't write-behind stay disabled?

On Sat, 28 Jan 2006 08:23:20 +1100, Franc Zabkar
On Fri, 27 Jan 2006 04:57:36 +0200, "cquirke (MVP Windows shell/user)"
On Sun, 22 Jan 2006 19:42:26 GMT, (Olive) wrote:


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.
This test should saturate your COM port.


That's a good test! Usually it's the receive buffer, as thePC can
pace its sending of data.

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.


This is true - usually if they are a problem, you'd get dropped lines
and/or corrupted downloads.

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.


Thanks - I remember the "shape" of the values, so can spot 16550
(nice) vs. 16450 (nice from far, but far from nice) IIRC.

Modem speed is in bits per second, ...divide by 10 for 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.


Ah, OK; thanks for that!

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.


Nice... I think it helps if you are downloading directly from the PC
you are dialed into, whereas most of my tests involve a few hops (e.g.
I download things I need, like av updates etc. and watch those)

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).


I'dbe surprised if it's even that, as just about anything large and
contiguous will be already compressed (.ZIP, compressed .EXE, .JPG,
..MP3, .AVI, etc. no gold in thar hills)

typical 41k, 44k, 49k connects.


If your connect speeds are really that inconsistent, then I would
suspect a phone line issue.


There are always modem line issues - modems suck rightdown there with
loading programs from domestic cassette recorders, and if it wasn't
for the scale of telco infrastructure, we'd have beaten them to death
decades ago. It's pathetic having to talk "speed", "reliability" and
"dial-up" in the same sentence; it's like trying to make a bicycle
faster to keep up with highway traffic.

[*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.


Yep. I must say, Star Downloader has made a difference with modem
downloads for any site that supports them, on dial-up (simply
beingable to resume a download broken by a disconnect is value enough,
but a 2.5k - 4k speed boost is typical). With ADSL, I hardly bother
except for a few known sucky slow sites.

What may affect our mileage here is telco exchange equipment (which
has improved - the same 41k-49k V.90 modems now routinely do 50k and
even 52k) and ISP peering, which affects hops to overseas servers
(i.e. nearly all servers). Also, the way folks wire up the phone gear
in the house can create line quality issues, e.g. line splitters that
have other phone handsets "in front of" the modem.

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.


Depending how far back you go (and remember, this is the poster who is
quoting 386-era Windows 3.yuk articles at us g ) he may have an
internal modem with true internal UART interface with a bufferless
UART. True, that would be most likely V.32bis, i.e. 14400 bps!

The other worry is that he may have an elderly PCI system (say, a
486DX2-66 or Pentium-133) with a modern "soft" modem, and the
processing overhead of these "soft" modems can give problems that look
a bit like serial port overruns... may even present as such.



---------- ----- ---- --- -- - - - -

Don't pay malware vendors - boycott Sony
---------- ----- ---- --- -- - - - -