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 - [EMAIL PROTECTED] | 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 | +--------------------------------------------------------------------+