A Windows 98 & ME forum. Win98banter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » Win98banter forum » Windows 98 » Setup & Installation
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

why won't write-behind stay disabled?



 
 
Thread Tools Display Modes
  #41  
Old January 27th 06, 10:23 PM posted to microsoft.public.win98.setup
external usenet poster
 
Posts: n/a
Default 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.
  #42  
Old January 28th 06, 05: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
---------- ----- ---- --- -- - - - -

  #43  
Old January 29th 06, 09:58 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 18:18:11 +0200, "cquirke (MVP Windows shell/user)"
put finger to keyboard and composed:

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:


typical 41k, 44k, 49k connects.


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


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.


Don't be fooled by the initial connect speed. The client and server
modems will speedshift downwards and upwards as line conditions
change. That's just one of the things that the modem's last call
diagnostic report will tell you. You can also listen in on a dialup
session via the modem's speaker by adding L3M2 to your modem's Extra
Settings in your DUN connectoid. Short blips indicate speedshifts, eg
from 46667bps to 45333bps, and a ~10 sec period of caterwauling during
which no data are transferred indicates a retrain. To minimise your
annoyance you could plug a headset into your modem's speaker socket,
if it has one.

See these abbreviated diagnostic logs:
http://groups.google.com/group/alt.c...e=source&hl=en

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.


The term, "softmodem", is somewhat misunderstood.

In fact there are three types of internal modem, "soft",
controllerless, and "hard" (controller based). Softmodems have a DAA
(telephone line interface), controllerless modems have a DAA and DSP
(digital signal processor), and "hard" modems have a DAA, DSP, and
controller.

Among other things, a modem's controller handles AT command parsing,
UART emulation, data compression and error correction. These functions
do not impact significantly on the host CPU. OTOH, the functions of a
DSP are highly CPU intensive, so a softmodem (which emulates the DSP
in software) may impact noticeably on CPU performance.

Examples of softmodem chipsets are PCtel HSP, Motorola SM56,
Smartlink, and Conexant HSF. Controllerless examples include Conexant
HCF, Intel HaM, Lucent Win Modem, and USR Winmodem.

Note that the term "Winmodem" is a USR trademark and refers to their
line of controllerless modems.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
  #44  
Old February 3rd 06, 01:56 PM posted to microsoft.public.win98.setup
external usenet poster
 
Posts: n/a
Default why won't write-behind stay disabled?

On Mon, 30 Jan 2006 07:58:56 +1100, Franc Zabkar
On Sat, 28 Jan 2006 18:18:11 +0200, "cquirke (MVP Windows shell/user)"


The client and server modems will speedshift downwards and
upwards as line conditions change.


Yep - that's why I like download speeds as a better guide, though
there are all sorts of variables there too. A fave trick was to
connect at high speed (to look good in the log) and then almost
immediately kick down to a speed that actually works.

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.


In fact there are three types of internal modem, "soft",
controllerless, and "hard" (controller based). Softmodems have a DAA
(telephone line interface), controllerless modems have a DAA and DSP
(digital signal processor), and "hard" modems have a DAA, DSP, and
controller.


DSP are highly CPU intensive, so a softmodem (which emulates the DSP
in software) may impact noticeably on CPU performance.


What they all have in common is a dependence on "drivers" (code, not
just an .INF of AT language) and no serial interface, so they can't be
troubleshot from DOS. You live and die by Windows drivers, and we all
know how flaky those can be... so they aren't fun to troubleshoot.

I prefer to avoid any sort of "soft" modem (but especially ones with
no DSP) on PCs slower than 500MHz or so. For field and
troubleshooting work, I prefer to use an extrnal serial port modem.



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

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

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
write protection error kel via WindowsKB.com Disk Drives 3 January 17th 06 11:21 PM
Whoa. What was that? 98 load failure and.... keith General 20 March 3rd 05 07:46 AM
Restart 3-4 times before it can be use frustrated 98se user General 18 February 12th 05 05:14 PM
Please help! Display settings !! Mitzi Monitors & Displays 12 July 11th 04 05:19 AM
Disk write errors Bob Ninow Disk Drives 4 June 6th 04 07:00 PM


All times are GMT +1. The time now is 11:04 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 Win98banter.
The comments are property of their posters.