ccfj@quagga.uucp (F.F. Jacot Guillarmod) (11/02/90)
I am getting about 500 cps transfer rate on a long distance (South Africa to U.S.) uucp dialup link. Locally, I am using a Multi-Tech V.32 modem, and the site in the U.S is using a Telebit T2500. My dialler program is a version hacked from the Hayes2400 dialler. The local system is a 386 clone running SCO Xenix 2.3.2, and the uucico (which supports only 'g' protocol) has been modified to use a window size of 7 - this change increased throughput from about 220 cps to the present levels. And, yes, I am driving my serial line to the modem at 19.2 kb! Questions: a) is 500 cps over such a link expected, or is better throughput possible? b) if better performance is possible, how can it be attained? My news feed is batched/compressed, and I am using smail 3.1 to compress and batch normal mail as well. c) if this performance is about what can be expected, can anybody give an explanation of why faster transfer just doesn't happen? Our local PTT is willing to assist, but I need to know what to ask them. d) does anybody have a 'genuwine' Multi-Tech V.32 dialler program they are willing to share? Particularly one that uses parameter tailored for talking to Telebits... e) if you could start from scratch, what modems would you use to maximize the speed of such a link? Would V.42 make any difference, given that the files to be transferred are already compressed? The reasoning behind this question is that an improvement in the performance translates into hard cash, and could write off the cost of new hardware in a few months. Thanks in advance for any enlightenment on these points. -- F.F. Jacot Guillarmod - Computing Centre - Rhodes University - Grahamstown Internet: ccfj.quagga@f4.n494.z5.fidonet.org uucp: ..!m2xenix!quagga!ccfj
grr@cbmvax.commodore.com (George Robbins) (11/03/90)
In article <1990Nov1.203225.14074@quagga.uucp> ccfj@quagga.uucp (F.F. Jacot Guillarmod) writes: > I am getting about 500 cps transfer rate on a long distance (South Africa > to U.S.) uucp dialup link. Locally, I am using a Multi-Tech V.32 modem, > and the site in the U.S is using a Telebit T2500. My dialler program > is a version hacked from the Hayes2400 dialler. > > The local system is a 386 clone running SCO Xenix 2.3.2, and the uucico > (which supports only 'g' protocol) has been modified to use a window > size of 7 - this change increased throughput from about 220 cps to the > present levels. And, yes, I am driving my serial line to the modem at > 19.2 kb! > This may be a silly question, but do you have both ends fudged to request the window size of 7? It's not obvious, but each side requests window and packet size and then the other side grants that or less. > possible? > > feed is batched/compressed, and I am using smail 3.1 to compress and > batch normal mail as well. > c) if this performance is about what can be expected, can anybody give > an explanation of why faster transfer just doesn't happen? Our > local PTT is willing to assist, but I need to know what to ask > them. I don't know how much better you could expect, international dialup map is still full of blank spaces and "here be dragons". The 500 CPS is similar to what I see between the US and Hong Kong using Telebit modems in PEP mode. I think you really need to spend some time analyzing why the thruput is so slow. If there is a lot of line noise or periodic events that make characters dissapear, then I wouldn't expect much improvement. If the problem seems to be due to long propagation delay in one or both directions then switching to a version of uucp which support one of the "error free path" protocols might do wonders. You also want to double check to make sure the modems aren't running in 4800 BPS V.32 fallback mode or periodically retraining. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
cec@cup.portal.com (Cerafin E Castillo) (11/03/90)
With 500 cps (5 kbps) using V.32 it seems that your modem is suffering
from fallback. That is, your V.32 modulation is doing 4800 bps and
not 9600 bps due to line conditions. This has been my constant experience
with V.32 in international calls (Tokyo to San Francisco).
Your best solution is to use TELEBIT PEP modems at each end of your
connection with a window size 3 uucico and the TELEBIT UUCP protocol
support. You will more likely see 8-10 kbps. PEP has better performance
over international line and adverse phone line conditions.
For more information, e-mail TELEBIT at modems@telebit.com and ask for
the document: TELEBIT PEP MODEM CONSIDERATIONS FOR ADVERSE COMMUNICATIONS
LINKS. Good Luck!
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \|| \\|
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
NTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================rwhite@nusdecs.uucp (0257014-Robert White(140)) (11/06/90)
In article <1990Nov1.203225.14074@quagga.uucp> ccfj@quagga.uucp (F.F. Jacot Guillarmod) writes: >a) is 500 cps over such a link expected, or is better throughput > possible? Better V.32 performance is, indeed possible. The lag you indicate is a little large to be induced by the real transmittion delays induced by things like satalite travel time and such. "Local" V.32/V.42/V.42bis calls I make always have more-than 9600baud performance barring alarms from garbeled info. (I have a sometimes-unreliable communications board in my host). >b) if better performance is possible, how can it be attained? My news > feed is batched/compressed, and I am using smail 3.1 to compress and > batch normal mail as well. >e) if you could start from scratch, what modems would you use to > maximize the speed of such a link? Would V.42 make any difference, > given that the files to be transferred are already compressed? > The reasoning behind this question is that an improvement in the > performance translates into hard cash, and could write off the > cost of new hardware in a few months. Many yesses here (to follow)! First the V.32, V.42, and V.42bis info... V.32 is basically a "standard" modulation technique w/answer protocol recommendations. One of the bizzare things about it, however, is that it dosn't spesify the "inital connect data rate" in the V.32 specs. Some modems will initally connect at 9600bps and others will start at 2400bps. In both cases the modems are V.32 compliant. The fast-start modems fall-back and the slow-start modems fall-forward durring protocol initiation. If you mix-and-match these techniques you may end up running at 4800bps on a line that could easily do full 9600bps work. If you are having this problem you should: a) see if you can man-handle the slow-start modem into fast-start mode. b) See if you can restrict the connection to higher speeds only. c) lengthen the fallback time on the fast-start modem and shorten the fall-forward time on the slow-start modem. V.42 and V.42.bis summary; if your modem does not have BOTH get it upgraded or turn it in on a real(tm) modem. V.42 is the ARQ (automatic retransmit request) and protocol negotiation standard. It is equavilant to mnp1-4 for all purposes. It does not do any data compression but it does let the modems argue about life after the connection is established, without disturbing the data flow. I beleive (read "disclaimer") that without the V.42 the lines will retrain down to lower speeds when disruptive line noise occurs but the retrain up is much rarer. That as may be, without V.42 the software protocol has the full responsibility for error control; since the modem(s) becomes a dedicated processor for error control the V.42 can usually correct minor problems faster and more effeciently than the software protocols. V.42bis is the data compression technique. This technique is/was more commonly known as "LAPM" and is substancially different than mnp5. mnp5 data compression will *reduce* the throughput on already compressed or truely random data. This is because bandwidth is used to transmit and reinitalize the mnp5 data dictionary. V.42/LAPM does not have this problem so it is OK to use on already compressed files. As an added bonus, V.42/V.42bis will not send the automatic-noise-burst durring connect attempts to non V.42/V.42bis modems. Simplifying most dilaing/login scripts in various environemnts. Remember that V.32, V.42, and V.42bis are all independant of ehachother as standards (tho 42bis ?may? require 42 don't actually know on that score) and the combination of all three are your best-bet. What I would (and indeed did) do: I have USRobotics V.32 modems on my host machines. Their support is good and modem bios upgrades and warentee service/support are free for a year (or more, I don't remember). I would have opted for the dual standard modems (both V.32 and a propriatary "HST" protocol upgrades from either available). I have a dual standard at home (I use the HST stuff for other uses but have never been able to test uucp using that protocal) and consider it a good deal in general. I have set the modems to use V.42bis at all times and to answer calls using CCITT answering tones. (the dual stnadard will auto-switch from CCITT to HST but not the other way around). A couple of hours of setup experimentation has gotten me a good number of optimal (modem-spesific) settings both in the hardware and in my uucp files. I am quite satisfied with this setup. Would it be worth it for you to change? Probably not. Under bad conditions I have gotton as low as 700cps on local calls. I happen to beleive that this has been caused by the modem being able to go to fast for the host port and then having to wait around for a uucp alarm to restart/continue transmission. You may be able to up your transmission rate by 1) getting V42/V42bis. 2) watching the modem to see if you have several-second dead spotts durring transmission (indicating a flow control problem or some such). and 3) tweaking the ARQ or uucp packet sizes DOWN where possible while increasing the window size in whatever protocols you use. Don't know how much help I have been... Enjoy. Rob.