|
|
| Author |
Message |
| 25 new of 227 responses total. |
keesan
|
|
response 150 of 227:
| 
Feb 12 04:07 UTC 2000 |
Jim did not exactly turn off hardware handshaking. What he did was switch
back from Procomm Plus to Procomm, which has no hardware handshaking option.
Apparently this bothers some modems and not others. He will figure it out.
|
gull
|
|
response 151 of 227:
|
Feb 13 02:50 UTC 2000 |
Basically, if your computer is fast enough to send data faster than the
modem can send it out, you'll have problems uploading with any protocol,
Ymodem included. What happens is that the characters the modem can't get to
fast enough simply get dropped, which leads to things like CRC errors.
There are two ways to fix this: reduce the baud rate the computer talks to the
modem at, or use hardware handshaking. Hardware handshaking simply lets the
modem tell the computer, 'hey, wait a second while I catch up!' Since
data-compressing modems can send data faster than their rated speed, it's
preferable to use hardware handshaking and let the computer talk to the modem
faster than the modem can necessarily send data. (I've gotten sustained
data rates of 4.0Kbytes/second on a 28.8kbps modem, with data compression
and hardware handshaking. The computer's baud rate was set to 57,600
baud.)
The reverse problem can also occur -- your modem might receive data faster
than your computer can accept it. This leads to the opposite problem -- you
can't download at any reasonable speed.
|
keesan
|
|
response 152 of 227:
|
Feb 13 22:15 UTC 2000 |
Thanks, we will experiment based on your information. It is a 386DX33
computer with a 14.4K modem (probably data-compressing). How do you calculate
which is faster?
|
gull
|
|
response 153 of 227:
|
Feb 14 00:03 UTC 2000 |
You don't; there are a lot of variables (including whether you're running
DOS or Windows.) I've just always run hardware handshaking as a matter of
course.
|
keesan
|
|
response 154 of 227:
|
Feb 14 01:41 UTC 2000 |
DOS, is this faster or slower than Windows? Jim is more interested in whhy
things work than in keeping them working. So I am always surprised when
things occasionally continue to work. (Today grex did not work until I
switched com ports, he had two modems attached at the same time.) Today seems
to be Procomm Plus and the internal modem that would not do Ymodem uploads
before, I suppose we have to try with and without the handshaking. And then
switch to the external modem on Com2 and try the same experiment.
|
gull
|
|
response 155 of 227:
|
Feb 14 02:07 UTC 2000 |
Because Windows is a multitasking OS, the computer isn't constantly paying
attention to the serial port. (It's "distracted" now and then by other
programs that are running.) So handshaking is more important under Windows.
|
pfv
|
|
response 156 of 227:
|
Feb 14 02:30 UTC 2000 |
"Windows is a multitasking.." Umm, a BAD mt-OS, maybe..
|
gelinas
|
|
response 157 of 227:
|
Feb 14 02:40 UTC 2000 |
Last I heard, Windows used co-operative multi-tasking rather than pre-emptive
multi-tasking, so it has to wait for the current task to give up the CPU to
whichever one is next.
|
remmers
|
|
response 158 of 227:
|
Feb 14 10:50 UTC 2000 |
Windows 3.1 used cooperative multitasking.
|
davel
|
|
response 159 of 227:
|
Feb 16 02:23 UTC 2000 |
But at any rate multitasking under later versions of Windows does not always
seem to work terribly well. It definitely shows up in serial-port handling.
|
jazz
|
|
response 160 of 227:
|
Feb 16 13:03 UTC 2000 |
Not to mention some of the core applications which should, one would
think, be written with more tight multitasking, likce cdplayer. Cdplayer's
infamous for stopping everything on a system - including the explorer shell
- while it advances a track. Yuck.
|
gull
|
|
response 161 of 227:
|
Feb 16 15:37 UTC 2000 |
One gets the impression they wrote cdplayer once, then never touched it
again except to make cosmetic improvements. I usually use 3rd-party CD
player software, because I like to have CDDB support.
|
keesan
|
|
response 162 of 227:
|
Feb 16 16:27 UTC 2000 |
If upload does not work and download does work with my 14.4 modem and 386
computer, would this imply that the computer is faster than the modem?
|
remmers
|
|
response 163 of 227:
|
Feb 17 11:17 UTC 2000 |
Getting back to Grex system problems...
When I try to connect to "cyberspace.org" I get an "unknown host"
message, although "grex.cyberspace.org" still works. This is new
behavior in the last day or two.
|
mdw
|
|
response 164 of 227:
|
Feb 17 12:37 UTC 2000 |
"telnet cyberspace.org" works for me. Is your DNS server confused?
|
remmers
|
|
response 165 of 227:
|
Feb 17 14:01 UTC 2000 |
That's probably it. I use netperson.net as my ISP these days,
and use their DNS servers. I believe that's all part of the
wwnet empire.
|
scg
|
|
response 166 of 227:
|
Feb 17 19:01 UTC 2000 |
Hmm... Both of WWNet's DNS servers, which are authoritative servers for the
cyberspace.org domain, appear to be answering correctly.
|
orinoco
|
|
response 167 of 227:
|
Feb 17 19:14 UTC 2000 |
fwiw, grex.org also works just fine for me.
|
remmers
|
|
response 168 of 227:
|
Feb 18 02:27 UTC 2000 |
Well, as of right now, "cyberspace.org" is working again. It wasn't
this morning. I didn't change anything.
|
gelinas
|
|
response 169 of 227:
|
Feb 18 03:26 UTC 2000 |
A frequent cause of intermittent errors like these is that someone forgot
to increment a serial number when updating records. However, it doesn't
look like cyberspace's DNS records have been updated recently, so that
explanation doesn't seem to fit.
|
keesan
|
|
response 170 of 227:
|
Feb 18 18:42 UTC 2000 |
Re the problem with Ymodem and hardware handshaking, the internal modem is
doing okay without handshaking. Probably it is faster than the serial port
that the external modem was using. 386DX33 with built in serial port.
|
bdh3
|
|
response 171 of 227:
|
Feb 19 09:33 UTC 2000 |
(blind talking to deaf) Yes, this is often the case that an 'internal'
modem with a 'wider' bus and internal buffering will perform better than
an external modem talking to a motherboard serial port which emulates
the original 8550.
|
mdw
|
|
response 172 of 227:
|
Feb 19 11:07 UTC 2000 |
It's the 8250, and it doesn't matter, because most modems (that aren't
winmodems) are emulating the NS 16450/16550 series with a fifo, the same
chip used on the few serial cards made today or emulated on many modern
motherboards. The CPU overhead is the same in either case whether the
16450/550 be a real discrete chip, part of some larger chip set on the
motherboard, or buried into some slightly smaller chip on an internal
modem. The only possibilities to improve things are if the motherboard
16450/550 chip has fewer I/O wait states (the motherboard can optimize
this; it can't optimize wait states on an I/O bus), or if the whole
interface is scrapped and replaced with some sort of high performance
DMA interface. A "win-modem" could conceivably do this, but is not
likely to--the "winmodem" market is driven by minimizing hardware cost,
not maximizing performance, and indeed, there is little incentive for
hardware makers to optimize modem performance under windows. [ People
who care won't be running windows or modems in the first place. ] The
market that would most likely really care about modem performance is the
small-scale ISP, but even they aren't buying linux machines and hanging
modems off of them anymore (if they ever did), they're buying livingston
portmasters or equivalent. They won't even be running POTS lines since
the ISP end of 56K dialup service needs ISDN.
|
keesan
|
|
response 173 of 227:
|
Feb 19 23:07 UTC 2000 |
It is a 14.4 modem and no windows. Jim switched back to Procomm because it
is shareware, but it has no hardware handshaking so I will do internal modems.
Or use Kermit to upload. Anyone want to explain in beginner's language what
Marcus is talking about? What is a wait state?
|
scott
|
|
response 174 of 227:
|
Feb 20 22:53 UTC 2000 |
I think there's a modem not answering, but nobody has complained about it yet.
|
