Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!execu!sequoia!uudell!bigtex!central!Athena!mismpc!tim From: tim@dal.fsd.mot.com (Tim Dawson) Newsgroups: comp.dcom.modems Subject: Re: T1000 Message-ID: Date: 6 May 91 17:20:09 GMT References: <585@fudd.dataco.UUCP> <35@mich-ns.Michigan.COM> <1991Apr27.233044.22434@nstar.rn.com> <1991May01.021126.1382@nstar.rn.com> Sender: usenet@Athena.UUCP Lines: 85 larry@nstar.rn.com (Larry Snyder) writes: >tim@dal.fsd.mot.com (Tim Dawson) writes: >>larry@nstar.rn.com (Larry Snyder) writes: >>>tech@mich-ns.Michigan.COM (Mich. Network Sys. TECH SUPPORT) writes: >>I guess this could all revolve around phone line quality and what you >>expect on interactive dialups. I routinely use my T1000 interactively into >>a bank of rackmount T2500's and have absolutely not gripes whatsoever as >>to throughput. No, it isn't true 9600, but I can't read that fast anyway >>so BFD! On news feeds with UUCP the T1000 will hands down blow away ANY >>V.32 I have ever seen, and this statement is made after one modem vendor >ahh - not v.32bis - no way. v.32bis will blow the socks of a >T1000 plus v.32bis is much better for interactive applications (like >running X over a slip connection). Try running a T1000 over a SLIP >connection - a 2400 baud modem will work just as good as the T1000. >>spent 3 weeks trying to get V.32 to even come close and gave up! This entailed >>new firmware, setup changes, line testing etc. We also evaluated 3 other >>vendors and found no significant differences. >I don't know what you get with the T1000 doing uucp, but we are getting >around 1050 cps doing uucp for v.32, and around 1650 doing v.32bis --- I get around 850 - 900 with the T1000, and more like 1800 with the T2500's talking to other PEP sites with > T1000 PEP modems. >Of course the T2000 runs around 1420 cps -- my understanding the T1000 will >do around 850 at best - in which case a v.32bis is a much better selection. But can you get V.32bis for $550?????? >>The other problem I have with V.32 (and why I refuse to use it unless there >>is absolutely no other alternative) is that I have been unable to get >>them to hold connections for more than about 10 minutes on some of the long >>distance connections that I routinely make, and V.32 won't talk all of 100 >>feet through my PBX (Rolm), so if I want to use V.32 I gotta get special >>phone lines to boot. Telebits - no problem, tastes great, less filling! >we are now feeding several sites via both v.32 and v.32bis without problems - >all of which are long distance... Maybe you are using poor quality v.32 >modems? With the US Robotics v.32bis modems - we haven't a problem... >>V.32 works great under "ideal conditions", but stinks in my version of >>"reality". >maybe with some vendor's modems - but not with the USR modems USR Codex Telebit's V.32 Implementation in the T2500 UDS . . . . The all fail. The problem is simply this: V.32 knows 9600 and 4800 baud - - - - PERIOD! If you train down to 4800 and then retrain again and 4800 for some reason is not clean (line hit, etc) V.32 standard says to DISCONNECT - they are incapable of continuing from this point, and also cannot train back up to 9600 once fallback has occured. This is not a problem with a vendor, this is a problem with a protocol - V.32 does not have the same kine of robust error recovery and correction as PEP. Also 9600 -> 4800 is a pretty huge step to fallback for a line problem when compared to PEP's 100 baud (or so) increments. Even if throughput on V.32bis is close or even equal to PEP, I still will opt for PEP. Why??? As I previously stated, my experience with V.32 is so bad on holding lines, that I have seen occasions where it took up to 8 HOURS to transfer a 1 Meg file - not because the connection was slow (stats looked fine, actually) but the damn V.32 just LOVED to drop the connection at random, inevitably 80+ percent of the way through the transfer. I ended up with about 6 hours worth of phone charges to haul 1 Meg. UGH! At least with the PEP stuff I can be confident that the file will get there the first tim! >-- > Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391 > HST/PEP/V.32/v.32bis/v.42bis > regional UUCP mapping coordinator > {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry} -- ================================================================================ Tim Dawson (tim@dal.fsd.mot.com) Unix Systems and Networking Administrator Motorola Computer Systems - MIS Bellnet: (214)-888-2231 1701 Valley View Lane, Farmers Branch TX. 75234