karl@sugar.hackercorp.com (Karl Lehenbauer) (10/31/90)
If you have the choice of connecting to a machine via PEP or V.32, as in the case where both sides have Telebit T2500 modems (and UUNET uses them) and you do a great deal of traffic in small files, like lots of small email files, I have found that V.32 achieves significantly greater throughput than PEP. The reason is (almost certainly) that the half-duplex PEP protocol takes longer to turn the line around back and forth for the short messages that uucp exchanges to negotiate a transfer, plus the short command file that accompanies each transfer, than does the full-duplex V.32. The uucp protocol spoofing in the modems doesn't help during this part since it doesn't spoof that part of the exchange (and you wouldn't want it to -- you don't want your modem acking file transfers that the modem hasn't yet and might not be able to get successfully pushed through to your computer.) -- -- uunet!sugar!karl -- Usenet access: (713) 438-5018
brian@motcsd.csd.mot.com (Brian Smithson) (11/01/90)
karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >If you have the choice of connecting to a machine via PEP or V.32, as in >the case where both sides have Telebit T2500 modems (and UUNET uses them) >and you do a great deal of traffic in small files, like lots of small >email files, I have found that V.32 achieves significantly greater throughput >than PEP. On the other hand, I suspect (i.e., haven't measured) that PEP achieves greater throughput than V.32 for small files when the number of files per call is small. V.32 seems to sit there and train itself interminably, but PEP just screeches and howls a couple of times then and starts sending data. -- -Brian Smithson Motorola Inc., Computer Group, Commercial Systems Division 10700 N. De Anza Boulevard, Cupertino, CA 95014 USA, (408)366-4104 brian@csd.mot.com, {apple | pyramid}!motcsd!brian
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (11/06/90)
karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >The reason is (almost certainly) that the half-duplex PEP protocol takes >longer to turn the line around back and forth for the short messages that >uucp exchanges to negotiate a transfer, plus the short command file that >accompanies each transfer, than does the full-duplex V.32. The uucp protocol >spoofing in the modems doesn't help during this part since it doesn't spoof >that part of the exchange (and you wouldn't want it to -- you don't want your >modem acking file transfers that the modem hasn't yet and might not be able to >get successfully pushed through to your computer.) Something else to look at is running batched SMTP instead of individual rmail jobs. This has the advantage of working with PEP only modems, and gives you even better throughput than running lots of small jobs through V.32, since it practically eliminates file-complete handshake sequence. Of course, both you and your neighbour must be running an MTA that supports this. Smail3 handles this in a very straight forward manner. I'm not sure if there are any other MTA's that do this right now. It could be added to sendmail without too much work. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca The only thing open about OSF is their mouth. --Chuck Musciano
david@twg.com (David S. Herron) (11/11/90)
In article <406@aupair.cs.athabascau.ca> lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: >karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >Something else to look at is running batched SMTP instead of individual >rmail jobs. This has the advantage of working with PEP only modems, and >gives you even better throughput than running lots of small jobs through >V.32, since it practically eliminates file-complete handshake sequence. Yes, that and the fact that you get to use real RFC-822 mail without all those groady & uncertain translations to UUCP/RFC-976 format. (Remember the perenniel argument on Rabid ReRouting? It becomes a lot simpler if you're using absolute domain names ...) >Of course, both you and your neighbour must be running an MTA that supports >this. Smail3 handles this in a very straight forward manner. I'm not sure >if there are any other MTA's that do this right now. It could be added to >sendmail without too much work. Ahem .. at least the incoming portion is available already in comp.sources.unix archives everywhere. Even though I have religious difficulties with sendmail I made this program work with both sendmail & MMDF... It does assume that you have a real mail system ... I have some patches in my mailbox which I'll get to eventually and there'll be a new version popping out sometime in the next few months. Promise ;-) The problem is correctly doing outgoing batching ... You really want to make sure that there's some number of messages inside the UUCP batch file. In MMDF what I would do is only run the deliver daemon infrequently -- and assumably this will usually give me UUCP jobs with multiple messages. But this isn't certain to batch multiple messages, and also if the neighbor polls at the wrong time then they'll miss picking up messages .. So it would be good to push the message into the UUCP queues as soon as possible after it arrives. Which is counter waiting awhile so that you can be more sure of having multiple files batched up. One solution I know of, I didn't think of it -- the guys who are/were at SanDiego.NCR.COM did (yes, I'm talking about you guys again) -- is to keep track of the current UUCP job which has batched messages in it. Then "know" how to translate the UUCP job number into a file name in /usr/spool/uucp. Then append the next incoming message to that file. Groady & low-level but it works. Oh, it's not a simple append since you have to back up prior to the "\r\nQUIT\r\n" at the end of the file. A smallish improvement to that might be to treat QUIT as an RSET, so that you can use a simple append & maybe save a bit of ugly code. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Use the force Wes!
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (11/15/90)
david@twg.com (David S. Herron) writes: >The problem is correctly doing outgoing batching ... You really >want to make sure that there's some number of messages inside the >UUCP batch file. In MMDF what I would do is only run the deliver >daemon infrequently -- and assumably this will usually give me UUCP >jobs with multiple messages. But this isn't certain to batch >multiple messages, and also if the neighbor polls at the wrong time >then they'll miss picking up messages .. >So it would be good to push the message into the UUCP queues as >soon as possible after it arrives. Which is counter waiting awhile >so that you can be more sure of having multiple files batched up. It's easy. You spool the messages in BSMTP format, one per file without the HELO/QUIT wrappers, using seperate directories for each site you chat with. Next, create a simple shell script that can be run to batch and compress all outstanding messages for a given site and queue it up in UUCP. For outgoing polls, run the script just prior to the uucico run. For incoming polls, give the site a login "shell" that: 1) Kicks off the mail batcher, then 2) exec's uucico This requires every site that polls you to have a unique login name (well, it makes it a lot easier to implement). -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca The only thing open about OSF is their mouth. --Chuck Musciano
chip@tct.uucp (Chip Salzenberg) (11/20/90)
According to lyndon@cs.athabascau.ca (Lyndon Nerenberg): >It's easy. You spool the messages in BSMTP format, one per file >without the HELO/QUIT wrappers, using seperate directories for >each site you chat with. Next, create a simple shell script that >can be run to batch and compress all outstanding messages for a >given site and queue it up in UUCP. Code to support the above approach is provided with Smail 3.1. >For incoming polls, give the site a login "shell" that: > 1) Kicks off the mail batcher, then > 2) exec's uucico This is an interesting approach, but it may be counterproductive if you desire to increase batch size despite frequent polls for incoming mail. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I've been cranky ever since my comp.unix.wizards was removed by that evil Chip Salzenberg." -- John F. Haugh II