TIP: Click on subject to list as thread! ANSI
echo: os2hardware-l
to: Roy J. Tellason
from: Steve McCrystal
date: 1999-09-07 06:38:08
subject: SIO

;
In a msg of , Roy J. Tellason writes to Steve
McCrystal:
;
Roy,

 SM>> While the first part of what you say is quite correct, there
 SM>> is simply no way that a port driver, regardless of how well
 SM>> written, will affect the *analog negotiation* of connect
 SM>> speed.

 RT> I must try and make it a point to read this stuff more carefully.
 RT> I don't think I wrote that with "analog negotiation" in mind,
 RT> nosir,  not at all...

I don't think so either... NOW! :^)

 SM>> At the time the analog negotiation/handshake/whatever you'd
 SM>> call it takes place, the modems don't know what they are
 SM>> connected to, or what driver is controlling the ports, nor
 SM>> do they care!  The negotiation of connect speed, and any
 SM>> subsequent shifts up or down as required, is entirely
 SM>> conducted between the modems, without respect to the quality
 SM>> of the drivers or the serial port hardware.

 RT> Isn't there an upper limit in place, though, determined by the
 RT> modem-to-computer connection speed?

Not at all, or not really might be better. Protocols (and/or) connect speed
negotiation is (again) independent of serial hardware, drivers, or whatever.
THEN flow control takes over, and can influence *throughput*.

An example... say your ports are locked at 38400 (God, it's been a LONG time!) 
and your modem negotiates a 48000bps v.42bis connect with the remote. You will 
still have a 48000bps connection between modems, but throughput will be VERY
poor, and flow control will be asserted most of the time as the data oozes out 
of your modem. In this example, I'd estimate about 90% of the time.

 SM>> Now, it is possible for *flow control* (Xon/Xoff or RTS/CTS
 SM>> or both) to affect *throughput* due to differing driver
 SM>> quality, but that is unlikely on anything newer than a 286
 SM>> machine (even with 16450 UARTS) and that has nothing
 SM>> whatsoever to do with the negotiation of *connect speed*.

 RT> Throughput was probably a lot of what I was thinking of there.

That's what I suspect, now! :^)  And, on this point, there is no disagreement.

 RT> I guess I oughta make it a point not to post when I'm tired,
 RT> too...

Point well taken.  I have the same problem on occasion, especially now that
there are far fewer hours in the day than there were a few years ago!

-[Steve]-

--- GoldED/2 3.0.1/#
* Origin: -[Steve's Place]- New Berlin, WI (FidoNet 1:154/731.2)

SOURCE: echoes via The OS/2 BBS

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.