Re: uploads over modem are SLOOOOOW!
On Fri, 20 Aug 1999, Lee Elliott wrote:
> Don't forget that V90 isn't symetrical - I believe it's only only on
> D/Ls that you'll approach 56K. I think the U/L rate is still 33.6K
> max. Even so, it still sounds as though something may be wrong. Have
> you got an external modem, so you can see the LEDs? or if it's
> internal, is there a package that will 'repeat' the LEDs onto the
> screen? Do pppload and wmppp show only data successfully transferred?
> If so, the LEDs might show that the modem's trying to send data all the
> time. What's the CPU utilisation like - is your cpu busy during the
> 'waits'?
This is correct. V.90 modems are 33.6 max upstream. And if there's more
than one analog to digital conversion in the complete path end-to-end
between the calling and the called modems, 33.6 BOTH directions is the
maximum that both directions will work. Brian should consider himself
very lucky to be seeing 50K+ connect rates on a regular basis.
In fact, after having done some very rigorous lab testing of V.90 modems
and having read the specs for V.90, all I can do is shake my head that
anything as silly as this ever got into widespread use! (:
Anyway, other things to check:
(Hopefully you have an EXTERNAL modem...)
- Watch the hardware handshaking lights on the modem during the upload.
Are they changing state at all? If not, you could be set up for software
handshaking which is IMHO not as good as hardware, and could be causing
you some problems.
- Does this happen with EVERY server you try to upload to or only a
particular one? Perhaps the ftpd is optimised for outbound traffic at the
site you're going into or you're experiencing a side-effect of a proxy or
firewall you're travelling through to reach the server.
- If you're not using FTP to upload and you're using something like
XMODEM instead, this is normal behavior. Kermit, XMODEM, and YMODEM all
send pretty small packet sizes (relatively) and require that each packet
be ACK'ed before sending another. ZMODEM eventually fixed this... sort
of... Servers that are optimized for downloading files with X, Y, and
Kermit usually bend the rules a little bit on the older protocols for
better throughput.
- Make sure you run the serial line between the PC and the modem at a
faster rate than line speed at which the modem connects to the other
modem. This allows the PC to push data to the modem faster than it can
send it, and again you need proper hardware handshaking to do this, but it
helps in some cases.
- If the duration of the pauses is more than 8-10 seconds during your
upload, it actually could be an indication that the modems are having
trouble hearing one another and are "re-training" every few seconds -- and
there are scenarios where this would only happen when you send heavy data
from your end to the other... hard to explain, but you could actually try
LOWERING your connect speed and getting overally FASTER throughput.
Sounds crazy, but it can happen.
- If you can, and have access to some modems, try to find out what kind of
modem pool you're dialing into and try to match brand names. Modems vary
WILDLY from brand to brand in their ability to handshake properly at the
start of the call and to stay in communications during the call when chip
vendors are mixed. (Seen this in the lab WAY too many times... I
personally find it sickening that a technology this "mature" in real time
is so messed up on the basics this way.)
This certainly isn't an 100% complete list, but hopefully I covered some
useful things you can check out.
+-----------------------------------+--------------------------------+
| Nate Duehr - nate@natetech.com | Support Amateur Radio & Linux! |
| Private Pilot, Telephony Engineer | Ham Callsign: N0NTZ |
| UNIX Hack, Perl Hack, Tech-Freak | Grid Square: DM79 |
| | "May the Source be with you." |
+-----------------------------------+--------------------------------+
| HamRadio and Linux mailing lists available for interested parties: |
| http://www.natetech.com/mailman/listinfo |
+--------------------------------------------------------------------+
Reply to: