root@zswamp.fidonet.org (Geoffrey Welsh) (10/20/90)
I noted with interest Larry Snyder's question about UUCP throughput over V.32 as compared to PEP, and am disappointed in the answers I've seen so far. One person explained that the Telebit used spoofing... which I'm sure Larry knows. Let me re-pose the question, clarified with respect to the technical background and specifics that I'd like to see (and I'm sure Larry would, too). I know full well that the Telebit gets its speed from the spoofing, but that was necessary because of PEP's unidirectional transmission nature. Spoofing adds nothing to windowed UUCP-g performance over a v.22bis (2400 bps) connection because (a) the ACK packets can be sent back without disturbing the flow of the data packets and (b) a 7-packet window takes two seconds to transmit at 2400 bps, giving the receiver plenty of time to ACK the oldest packet and allow the transmitter to continue non-stop. The question at hand is whether the full-duplex nature of V.32 extends this situation to 9600 bps. I know that the data packets need not be interrupted to send ACKs, but even a 7-packet window would take less than half a second to transmit at 9600 bps; it's entirely possible that the ACK packets might not arrive before the pending window reaches its limit, causing the transmitter to pause. This, of course, would prevent you from getting the maximum theoretically possible throughput (1100-1200 CPS on V.32, using synchronous framing a la MNP3 or V.42). Explicitly: Does anyone out there have throughput figures for UUCP protocols between two well-tuned and reasonably lightly loaded machines over a V.32 link? Thank you, and many apologies to those who are bored or even insulted by the great lenghts to which I've gone to ask a trivial question. Geoff -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards
grr@cbmvax.commodore.com (George Robbins) (10/24/90)
In article <1288.27204357@zswamp.fidonet.org> root@zswamp.fidonet.org (Geoffrey Welsh) writes: > > I noted with interest Larry Snyder's question about UUCP throughput over > V.32 as compared to PEP, and am disappointed in the answers I've seen so far. > One person explained that the Telebit used spoofing... which I'm sure Larry > knows. > > The question at hand is whether the full-duplex nature of V.32 extends this > situation to 9600 bps. I know that the data packets need not be interrupted > to send ACKs, but even a 7-packet window would take less than half a second to > transmit at 9600 bps; it's entirely possible that the ACK packets might not > arrive before the pending window reaches its limit, causing the transmitter to > pause. This, of course, would prevent you from getting the maximum > theoretically possible throughput (1100-1200 CPS on V.32, using synchronous > framing a la MNP3 or V.42). > > Explicitly: Does anyone out there have throughput figures for UUCP > protocols between two well-tuned and reasonably lightly loaded machines over > a V.32 link? I thought I covered this, but if you want some sample numbers, I have one connection that is currently V.32 when we call them and PEP when they call us... (An interesting role reversal for a Telebit fan, but their Trailblazer doesn't seem to answer the phone!) Mode Files Characters Seconds C/Sec B/S Thruput (.55 compression) PEP 21 5858185 4700 1246.4 12460 22.5 KB/S V.32 59 14904357 19764 754.11 7540 13.5 KB/S All data was compressed news batches, transfers of less than 100K were omitted to mimimize skew due to overhead and poor timing resolution. All data transfers were in the same direction, from my system to the other system. Note that these numbers aren't too surprising, the 7500 char/sec is about what you'd get one a direct connect at 9600 baud, the uucp "g" protocol simply doesn't drive the wire to 100% even under the best of conditions. Increasing window size or packet size, or changing protocols would probably help the V.32 get closer to 9600 BPS, but wouldn't do much for the the PEP mode unless the protocol was adaptable to PEP packetizing charactersitics. Protocol experiments are difficult and don't neccesarily help the average guy with a binary license. -- 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)
news@m2xenix.psg.com (Randy Bush) (10/25/90)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > The question at hand is whether the full-duplex nature of V.32 extends this > situation to 9600 bps. I know that the data packets need not be interrupted > to send ACKs, but even a 7-packet window would take less than half a second > to transmit at 9600 bps; it's entirely possible that the ACK packets might > not arrive before the pending window reaches its limit, causing the > transmitter to pause. This, of course, would prevent you from getting the > maximum theoretically possible throughput (1100-1200 CPS on V.32, using > synchronous framing a la MNP3 or V.42). I use V.32 and PEP for many connects a day. I normally use a T2500, but have also used Intel's new 9600EX (damn nice modem, and damn inexpensive, BTW). A local V.32 connect is as fast as PEP. A long distance V.32 connect is significantly slower. I.e., local V.32 gets over 1,000 cps, while a looong distance one (i.e., Oregon to Africa) gets 550 cps. What I want is a Xenix uucico with a bigger window, say 20 or 30. If you are dealing with a *lot* of mail as I do, O(10^2) messages per session, then a nice trick such as batched and compressed mail using fake BSMTP is the biggest win. Uucp-g's inter-file delays are absolutely disgusting, PEP, V.32, or whatever. -- ..!{uunet,qiclab,intelhf}!m2xenix!news
root@zswamp.fidonet.org (Geoffrey Welsh) (10/26/90)
In a message to All on Oct 24, George Robbins (grr@cbmvax.commodore.com ) wrote: >Message-ID: <15363@cbmvax.commodore.com> >Mode Files Characters Seconds C/Sec >PEP 21 5858185 4700 1246.4 >V.32 59 14904357 19764 754.11 Wonderful. Zackly what I needed. >Note that these numbers aren't too surprising, the 7500 char/sec >is about what you'd get one a direct connect at 9600 baud, Don't forget that the modems will have been using a synchronous framing technique (most likely MNP3 plus MNP4 for a couple of T2500s under V.32), which brings the 100% mark close to 1200 CPS (as opposed to 960 CPS for async framing over a 9600 bps null modem). If you take that into consideration, the 750 CPS rating is disappointing. >Increasing window size or packet size, or changing protocols I presume that you were using standard 64-byte packets; what window size were you using (7, 3, or 1)? Thanks for your reply! >help the V.32 get closer to 9600 BPS, but wouldn't do much >for the the PEP >mode unless the protocol was adaptable to PEP packetizing >charactersitics. Hmm, the 'e' protocol should work fine over a PEP modem *if* you are sure that your async connection to the TB is absolutely error-proof. It might even beat 'g' protocol spoofing performance... >Protocol experiments are difficult and don't neccesarily >help the average guy with a binary license. Sad but all too true. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!
root@zswamp.fidonet.org (Geoffrey Welsh) (10/28/90)
In a message to All on Oct 25, Randy Bush (news@m2xenix.psg.com ) wrote: >A local V.32 connect is as fast as PEP. A long distance V.32 connect is >significantly slower. I.e., local V.32 gets over 1,000 cps, while a >looong distance one (i.e., Oregon to Africa) gets 550 cps. Nifty. >What I want is a Xenix uucico with a bigger window, say 20 or 30. Well, that excludes 'g', eh? >Uucp-g's inter-file delays are absolutely disgusting, >PEP, V.32, or whatever. I've also found that when talking to a 3b2/310 running SysV R3.1.1... I finally found a 'mini' that's slower than my XT! -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!
grr@cbmvax.commodore.com (George Robbins) (10/29/90)
In article <1990Oct25.033248.28581@m2xenix.psg.com> news@m2xenix.psg.com (Randy Bush) writes: > root@zswamp.fidonet.org (Geoffrey Welsh) writes: > > > The question at hand is whether the full-duplex nature of V.32 extends this > > situation to 9600 bps. > > I use V.32 and PEP for many connects a day. I normally use a T2500, but have > also used Intel's new 9600EX (damn nice modem, and damn inexpensive, BTW). A > local V.32 connect is as fast as PEP. A long distance V.32 connect is > significantly slower. I.e., local V.32 gets over 1,000 cps, while a looong > distance one (i.e., Oregon to Africa) gets 550 cps. I find this quite confusing and contrary to my own experience. Local PEP calls are almost always faster than V.32, while long distance/international PEP calls do sometimes dip below the rates expected for 9600 BPS (i.e. V.32) connection. The only way that V.32 can "slow down" is via repeated retraining, or posibly fallback to 4800 BPS. The following seem to be the three killers of telebit thruput (though I'd rather lose thruput than take a bit hit on call completion/reliability). 1) International Calls - Europe, Hong Kong, etc... 2) Systems with T1000's or Trailblazers locked at 9600 BPS. 3) Highly loaded systems that can't keep up with the modems. -- 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)
root@zswamp.fidonet.org (Geoffrey Welsh) (10/29/90)
George Robbins (grr@cbmvax.commodore.com ) wrote: >The only way that V.32 can "slow down" is via repeated retraining, or posibly >fallback to 4800 BPS. Not if you're using UUCP-g protocol, in which case a performance limiting factor is how long it takes to transport the packets; since a 7*64 byte packet takes about half a second or less at 9600+ bps, it's possible that the transmitter might stop while waiting for the ACK on the oldest packet before continuing. This isn't a problem with UUCP-spoofed PEP, but might provide a real pain in the proverbial posterior when you're on a LD connection that's carried half a continent north on wireline, piped to microwave for a few hundred miles, uplink to sattelite to cross the continent, and the same (in reverse) on the other coast. Now the ACK packet must do the same on the return path... this could easily push the response time from, say, .5 seconds to .6; if that .1-second pause happens after every packet, you're spending more time waiting for ACKs than actually transmitting, hence very low efficiency figures. DISCLAIMER: This is speculation. I know not of the technology, nor the real-life figures. I go into this only because Mr. Robbins seems to be under the impression that V.32 throughput should be the same at all times because of the fixed-baud carrier. That may be valid for XMODEM, but it sure ain't for UUCP-g! -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!