tech@mich-ns.Michigan.COM (Mich. Network Sys. TECH SUPPORT) (05/08/91)
In article <tim.673550409@mismpc> tim@dal.fsd.mot.com (Tim Dawson) writes: > ". . . . 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! " I've heard a few complaints about V.32 and holding the line. My problem with V.32 involves a newsfeed from UUNET via CompuServe's V.32 local modems. I can't seem to get anything more than about 250cps when getting news from UUNET. A CompuServe problem or a UUNET problem? May just be that either their net or UUNET is so overloaded that throughput drops drastically. Anyone else have a similar problem. I sent e-mail to uunet, but so far, no reply has been received. Does anyone know what kind of V.32 modems CompuServe Network uses?? -- Michigan Network Systems Technical Support Division 1-800-736-5984 BBS: +1 313 343 0800 E-MAIL: tech@mich-ns.Michigan.COM TELEBIT DIGIBOARD WESTERN DIGITAL 3COM SCO INTERACTIVE UNIX MICROPOLIS ADAPTEC
gandrews@netcom.COM (Greg Andrews) (05/09/91)
In article <43@mich-ns.Michigan.COM> tech@mich-ns.Michigan.COM (Mich. Network Sys. TECH SUPPORT) writes: > >I can't seem to get anything more than about 250cps when getting news from >UUNET. A CompuServe problem or a UUNET problem? > CompuServe uses US Robotics Dual Standard modems with the HST modulation disabled. Matter of fact, ALL modulations besides V.32 are disabled on those numbers! I think you're simply seeing that uucp across the CompuServe network works about as well as Kermit, Xmodem and Ymodem: Not well at all. Compuserve developed their own protocol to run efficiently across their network. I don't know how it differs from something like uucp g, but it may be related to filling network packets efficiently and using large enough data blocks to keep the stream running. That's my best guess... -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'