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. |
|
|
Thread Tools | Display Modes |
#41
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
write protection error | kel via WindowsKB.com | Disk Drives | 3 | January 17th 06 10:21 PM |
Whoa. What was that? 98 load failure and.... | keith | General | 20 | March 3rd 05 06:46 AM |
Restart 3-4 times before it can be use | frustrated 98se user | General | 18 | February 12th 05 04: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 |