by David the Gno » Sat, 10 Nov 2001 16:12:48
Thanks
by Newbi » Sun, 11 Nov 2001 00:19:20
Quote:> I use a LAN at a large state college. I get great file transfer rates
> on everthing here EXCEPT music sharing programs (Morpheus/Audio
> Galaxy). When I first got here, the bandwidth for these programs was
> great, almost as good as everything else, and then it fell to about
> 0.02 kb/sec There have been a lot of rumors about the Residential
> Computer Network people controlling the bandwith of these programs.
> How can I get around this?
> Thanks
by *Matt » Wed, 14 Nov 2001 04:03:21
1. Hardware Flow Control isn't Controlling Flow
The problem is simple to describe. Nothing seems to cause
hardware flow control to work. Here are the details:
The modem is a Multi-Tech 1432EAB, capable of V.42 and the
modems it must talk with are USR Sportsters. The terminal server that
these USR's are connected to requires hardware flow control so it is not
a question of whether or not the modems on the other end are set to do
this.
The Multi-Tech is set for hardware flow control via at&E4 and
at&E13 which turns on pacing and allows the terminal connected to it to
send RTS/CTS signals to the modem. Both the RTS and CTS signals are
known to be present because I put a breakout box between the terminal
and the modem and the RTS light does change state when the terminal
would like for the incoming data to shut up for the terminal to catch up
with it. This has absolutely no effect at all on the incoming stream
which roars right along regardless of what happens.
If I manually disconnect CTS, I can't send any out-going data,
but incoming data aren't stopped. If I manually force RTS low by
patching it to a low signal so that it is perpetually off, the modem
blows data right by no matter what RTS does. I seem to have hardware
flow control in one direction, but not the other.
I have tried a different modem, (a USR Sportster none the less),
and I still have the same problem.
The terminal is an old P.C./XT equipped with a 16550 UART and
running MSKermit. It is definitely trying to send the shut-off signal
since I see the RTS indicator go low right about the time one would
expect the system to do flow control. Again, RTS has no effect of any
kind.
This same system performs flawlessly when using Xon/Xoff flow
control, but that is not an option with this particular server. The
server that uses Xon/Xoff is most likely going away in a few months so I
need to figure out what else to check.
The Multi-Tech modem has a jumper setting for enabling hardware
flow control and it is shipped enabled so I have almost ruled that out.
Does this sound familiar to anybody? The modem configuration
registers which are important to the problem are:
at&E4 for hardware flow control, at&E13 to enable pacing.
I may not be understanding something about this correctly, but
my impression is that RTS from the computer should stop the data which
are incoming and then CTS from the modem should shut down out-going data
when the other end is swamped. This half appears to work so it is the
RTS line I am concerned about.
I have tried:
different modem, different cable, swapping RTS and CTS, rereading every
mention of hardware flow control from the modem manual until I can
almost state whole passages from memory, and I am frustrated.
Any ideas?
Martin McCormick
3. Sen. Edwards Intro's 'Spyware Control Act'
4. ISO small office firewall recommdation
5. VPN behind a 'firewall' I don't control
7. Access Control - for someone who is NOT a supervisor to reset password
8. Series 3a-mx: Touch Screen software solution
9. Can someone explain these ISDN 'tarrifs' .. ??
10. Linksys won't/can't answer this question, can someone here?
11. catalyst 2960 port bandwidth control
12. Bandwidth Control on Cisco 3750 EMI Switches.
13. Bandwidth Control Per IP address.