rlcarr@athena.mit.edu (Richard L. Carreiro) (09/30/90)
I have decided to take the plunge and get a 9600 baud modem.
I need an HST because most of my local BBSs use HST.
However, after I graduate, I'm gonna hafta be searching for a UUCP feed.
So, a USR dual standard seems the way to go.
Some questions:
(a) does the V.32(V.42bis) work with UUCP/USENET
(b) what features should I get, i.e. MNP, V.42, V.42bis, compression, etc?
Money is no object (to an extent)
I've never deailt with anything more than your generic hayes-compataible
2400 baud modem, so I'm rather clueless on all this stuff.
What IS MNP, V.32, V.42, V.42bis, etc?
(c) what is the best place to get one from?
Any help will be gratly appreciated!
--
Rich Carreiro The "War on Drugs"
ARPA: rlcarr@athena.mit.edu is merely a smokescreen for
UUCP: ...!mit-eddie!mit-athena!rlcarr The War on the Constitution
BITNET: rlcarr@athena.mit.edu JITTLOV FOREVER!larry@nstar.uucp (Larry Snyder) (10/01/90)
rlcarr@athena.mit.edu (Richard L. Carreiro) writes: >Some questions: >(a) does the V.32(V.42bis) work with UUCP/USENET yes - providing transfers in the 600-850 cps range - which isn't nearly as good as the telebit modems which yield throughput as high as 1300-1400 cps. >(b) what features should I get, i.e. MNP, V.42, V.42bis, compression, etc? > Money is no object (to an extent) then get a trailblazer for uucp, and get a regular HST to stay in touch with the DOS boards -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
oliver@real.fidonet.org (Oliver McDonald) (10/01/90)
oliver@real.fidonet.org (Oliver McDonald) writes: > rlcarr@athena.mit.edu (Richard L. Carreiro) writes: > > > However, after I graduate, I'm gonna hafta be searching for a UUCP feed. > > So, a USR dual standard seems the way to go. > > > > Some questions: > > (a) does the V.32(V.42bis) work with UUCP/USENET > > If you can get a feed that has v.32 yes. This will usually mean a T2500, > which will (usually) give v.42bis also. > > > (b) what features should I get, i.e. MNP, V.42, V.42bis, compression, etc? > > Get the full load (14.4, V.32, MNP, V.42bis). > > > Money is no object (to an extent) > > I've never deailt with anything more than your generic hayes-compataible > > 2400 baud modem, so I'm rather clueless on all this stuff. > > What IS MNP, V.32, V.42, V.42bis, etc? > > (c) what is the best place to get one from? > > Become a Sysop and get the Sysop deal from USR. This works out to GREAT > savings. The best place to ask is your local FidoNet node(s). If you need > to find one in your area, send me mail and I will look one up for you. > Ooops, had everything set up wrong. First message never left my system... *-----------------------------------------------------------------------* | oliver@real.fidonet.org \ "Ever notice how much they look | | ...alberta!ncc!real!oliver \ orchids?" | | Aurora Computer Technologies \ Lazarus Long, _Time enough for love_ | *-----------------------------------------------------------------------*
terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr) (10/01/90)
In article <1990Sep30.171414.5132@nstar.uucp>, larry@nstar.uucp (Larry Snyder) writes: > yes - providing transfers in the 600-850 cps range - which isn't nearly > as good as the telebit modems which yield throughput as high as 1300-1400 > cps. Running Kermit (with packet size 512, 3 windows) between an old HST (9600 baud top speed) and a Rackmount Dual Standard, I get 1060 CPS on binary files. If I replaced my old HST with one that spoke either V.42 or the new- er HST protocol (14400), I'd see a proportional increase. Of course, this doesn't address the UUCP g protocol, but since it's also a windowing protocol you should see similar results. I have seen reports of UUCP transfers over V.32 modems where the transfer rate is approximately equal to the CPS rate through the modem. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, US terry@spcvxa.spc.edu (201) 915-9381
grr@cbmvax.commodore.com (George Robbins) (10/01/90)
In article <1990Sep30.024433.28717@athena.mit.edu> rlcarr@athena.mit.edu (Richard L. Carreiro) writes: > I have decided to take the plunge and get a 9600 baud modem. > I need an HST because most of my local BBSs use HST. > However, after I graduate, I'm gonna hafta be searching for a UUCP feed. > So, a USR dual standard seems the way to go. > > Some questions: > (a) does the V.32(V.42bis) work with UUCP/USENET It "works" with uucp, however only a very small (but increasing) percentage of usenet sites have v.32 compatible modems. If you are planning on getting a feed from uunet, no problem, but if you hope to get a local feed from Joe's Bar and Grille, you'll be stuck @2400 BPS. > (b) what features should I get, i.e. MNP, V.42, V.42bis, compression, etc? > Money is no object (to an extent) All of the above are nice to have, especially in the BBS world, but with usenet's usual pre-compressed binary transfers, they won't help much.... -- 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)
rlcarr@athena.mit.edu (Richard L. Carreiro) (10/02/90)
First - thanks for all the information, folks! Now, some more questions... In article <1990Sep30.171414.5132@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >rlcarr@athena.mit.edu (Richard L. Carreiro) writes: >>(a) does the V.32(V.42bis) work with UUCP/USENET >yes - providing transfers in the 600-850 cps range - which isn't nearly >as good as the telebit modems which yield throughput as high as 1300-1400 >cps. Ok - speed aside, does it work? For the sake of this question, assume I I don't care that I can't get the full 1200+ cps rates. Will a USR dual standard with V.32, V.42, V.42bis be able to communicate with Trailblazers at >4800 baud? >>(b) what features should I get, i.e. MNP, V.42, V.42bis, compression, etc? >> Money is no object (to an extent) Perhaps I should have rephrased that - I don't mind shelling out the $$$ to get a fully loaded modem, but to get two modems would be a bit much. Of course, I may be wrong about that - I have really no idea what high-speed modems cost, other than that they are rather expensive. >then get a trailblazer for uucp, and get a regular HST to stay in touch >with the DOS boards This seems interesting (again, please bear with me as I have zero experience in the high-performance modem world). If I were to go this way, what should I expect to pay - how much is a USR regular (but new - 14.4) HST modem (I should get MNP with that, right?). And, how much is a Trailblazer? Also, these would be being used with an Amiga 2500 or Amiga 3000. Will any special cable have to be hacked up, or do they have standard DB-25 connector sockets (the modems, that is). Also (I'll probably also ask this on the amiga groups), does Matt Dillon's AmigaUUCP have any problems with certain modems? Thanks again! One last thing - I wouldn't be getting a complete feed. Just the amiga groups, tv, Trek, the Big Four sports, sf-lovers, comics, and a couple other random groups. Yes, I realize thats a lot of bytes, but it's not a full bore feed other. Does this affect any of the answers/recommedations that people have given me? -- Rich Carreiro The "War on Drugs" ARPA: rlcarr@athena.mit.edu is merely a smokescreen for UUCP: ...!mit-eddie!mit-athena!rlcarr The War on the Constitution BITNET: rlcarr@athena.mit.edu JITTLOV FOREVER!
c60b-2ax@e260-2f.berkeley.edu (10/02/90)
As far as I know, a Dual Standard modem goes for about $999 average price, and an HST plain could be purchased for something like $600. If you qualify for a SYSOP discount, you can reduce those by a significant percentage. A USR Dual Standard will give you 14.4k HST as well as v.32 9600. Both modes include v.42bis data-compression and v.42 error-correction.
larry@nstar.uucp (Larry Snyder) (10/03/90)
rlcarr@athena.mit.edu (Richard L. Carreiro) writes: >In article <1990Sep30.171414.5132@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >Ok - speed aside, does it work? For the sake of this question, assume I >I don't care that I can't get the full 1200+ cps rates. Will a USR >dual standard with V.32, V.42, V.42bis be able to communicate with >Trailblazers at >4800 baud? Yes - with a T2500 (with V.32) but not with a T2000 or Trailblazer Plus. >>then get a trailblazer for uucp, and get a regular HST to stay in touch >>with the DOS boards >This seems interesting (again, please bear with me as I have zero experience in >the high-performance modem world). If I were to go this way, what should I >expect to pay - how much is a USR regular (but new - 14.4) HST modem >(I should get MNP with that, right?). And, how much is a Trailblazer? HST DS to Sysops is around $750, end-user discount price is around $899, Trailblazer T2500 is around $950 and the Trailblazer Plus is around $790. The Telebits (as you know) will hold the line much better than the HST - while the HST will produce the highest transfers using non-uucp protocols - but the Telebit wins hands down on UUCP transfers. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
mjs@cbnews.att.com (martin.j.shannon) (10/09/90)
In article <1990Sep30.211908.558@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr) writes: > In article <1990Sep30.171414.5132@nstar.uucp>, larry@nstar.uucp (Larry Snyder) writes: > > yes - providing transfers in the 600-850 cps range - which isn't nearly > > as good as the telebit modems which yield throughput as high as 1300-1400 > > cps. > > Of course, this doesn't address the UUCP g protocol, but since it's also > a windowing protocol you should see similar results. I have seen reports of > UUCP transfers over V.32 modems where the transfer rate is approximately > equal to the CPS rate through the modem. Yes, the problem is the UUCP g protocol. That is fairly widely accepted. I get 97% of the available bandwidth using the 'e' protocol. Of course, using it requires an error-free link between the uucico programs -- that includes hardware flow control. -- Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ, USA (Affiliation is given for identification only: I don't speak for them; they don't speak for me.)
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (10/09/90)
In article <1990Oct8.195418.1817@cbnews.att.com> mjs@cbnews.att.com (martin.j.shannon) writes: >Yes, the problem is the UUCP g protocol. That is fairly widely accepted. >I get 97% of the available bandwidth using the 'e' protocol. Of course, >using it requires an error-free link between the uucico programs -- that >includes hardware flow control. No. False. Incorrect. Wrong. Negative. Bad assumption. Hardware flow control (also know as RTS/CTS, hardware handshake etc) is *NOT* needed for uucp. van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow control. The only requirement is that each end of a uucp connection have the normal amount of bufferring that was offerred in the old style tty drivers. Specifically about 255 bytes. uucico sends up to 3 64+7 byte packets and then stops and waits for an acknowledgement packet from the other end. As long as there is no place in the chain between the sender and the receiver (where the ack's are generated) that has less than about 220 bytes of buffer nothing will be lost because that's the most uucp will send. If you have a constricting point that has less than 220 bytes of bufferring then yes it is a good idea to put hardware handshake into effect. For the default case of two Unix boxes hooked directly together, and for use with PEP modems there is always enough room. You should not need to have hardware flow control. -- Stuart Lynne Unifax Communications Inc. ...!van-bc!sl 604-937-7532(voice) sl@wimsey.bc.ca
mjs@cbnews.att.com (martin.j.shannon) (10/09/90)
In article <2461@van-bc.wimsey.bc.ca>, sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: > In article <1990Oct8.195418.1817@cbnews.att.com> mjs@cbnews.att.com (martin.j.shannon) writes: > > >Yes, the problem is the UUCP g protocol. That is fairly widely accepted. > >I get 97% of the available bandwidth using the 'e' protocol. Of course, > >using it requires an error-free link between the uucico programs -- that > >includes hardware flow control. > > No. False. Incorrect. Wrong. Negative. Bad assumption. I beg to differ. 'e' protocol does *NO* *ERROR* *CHECKING*. This is why, *WHEN* *USING* 'e' protocol, one needs an error free link between the uucico programs, including anything to do with the serial ports. > Hardware flow control (also know as RTS/CTS, hardware handshake etc) is > *NOT* needed for uucp. True, iff you're using 'g' protocol (the default). > van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow > control. Great! But I don't use a Telebit, so I can't do PEP, and I don't have uucp 'g' protocol spoofing in my modem. > The only requirement is that each end of a uucp connection have the normal > amount of bufferring that was offerred in the old style tty drivers. > Specifically about 255 bytes. Yep, that gives about 140 millisecs minimum interrupt latency for a bit rate of 14400 bits/sec. > uucico sends up to 3 64+7 byte packets and then stops and waits for an > acknowledgement packet from the other end. Again, this is true for 'g' protocol, but *NOT* for 'e' protocol. > As long as there is no place in the chain between the sender and the > receiver (where the ack's are generated) that has less than about 220 bytes > of buffer nothing will be lost because that's the most uucp will send. But, even better, 'g' protocol will keep trying to send a packet *UNTIL* it gets the appropriate ack. So, in reality, all you really need is to be able to receive a single packet intact at a time. > If you have a constricting point that has less than 220 bytes of bufferring > then yes it is a good idea to put hardware handshake into effect. Call that 71 (64+7) bytes and specify that you're talking about 'g' protocol, and I don't have any argument. > For the default case of two Unix boxes hooked directly together, and for use > with PEP modems there is always enough room. You should not need to have > hardware flow control. Except that the original article was specifically about modems that *AREN'T* PEP capable. Did you read any of it? Sheesh! -- Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ, USA (Affiliation is given for identification only: I don't speak for them; they don't speak for me.)
larry@nstar.uucp (Larry Snyder) (10/10/90)
mjs@cbnews.att.com (martin.j.shannon) writes: >Yes, the problem is the UUCP g protocol. That is fairly widely accepted. >I get 97% of the available bandwidth using the 'e' protocol. Of course, >using it requires an error-free link between the uucico programs -- that >includes hardware flow control. my uucico doesn't support the e protocol - where can one obtain source code for a version that does (so it runs under 386 unix?) -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
larry@nstar.uucp (Larry Snyder) (10/10/90)
sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: >van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow >control. are you using the same modem for your slip connection and bi-directional uucp transfers via dial up lines? which pep modem are you running slip with (t2500?) what kind of throughput do you get slip-slip (is it higher than uucp-uucp connections)? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (10/11/90)
In article <1990Oct9.161454.10476@cbnews.att.com> mjs@cbnews.att.com (martin.j.shannon) writes: >In article <2461@van-bc.wimsey.bc.ca>, sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: >> In article <1990Oct8.195418.1817@cbnews.att.com> mjs@cbnews.att.com (martin.j.shannon) writes: >> >I beg to differ. 'e' protocol does *NO* *ERROR* *CHECKING*. This is Hm. Now if I could just find an off the shelf uucp that offer's 'e' for my Xenix system, or my SCO UNIX system. Or any of the standard System V platforms. Any idea when AT&T will be offerring 'e' as a standard part of their uucico? You're in a better position than I am to know. I'd love to be able to use 'e'. But I'm stuck with all of these inferior type uucico's which only have 'g'. So I guess I just assume that if most uucp's don't offer 'e' then the default has to be 'g'. I'd love to hear different though. Keep us informed. Thanks. -- Stuart Lynne Unifax Communications Inc. ...!van-bc!sl 604-937-7532(voice) sl@wimsey.bc.ca
john@jwt.UUCP (John Temples) (10/11/90)
In article <2461@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: >van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow >control. How can you pump data at 19.2k bps into a modem which can only transmit it at 17-18k bps without using flow control? -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
csg@able (Carl S. Gutekunst) (10/11/90)
The uucp 'e' protocol has been in System V since Release 3.0. It's not public domain, so source isn't available. Reverse engineering it would be trivial for any competant UUCP hacker, though. (I still haven't gotten it clear whether Peter Honeyman is accepting the blame for 'e' or not...) (I did a version for 4.3BSD. Alas, I did it by swiping the SVR3.0 source, so I can't give it back to Berkeley.) <csg>
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (10/11/90)
In article <1990Oct10.164530.1672@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: > >>van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow >>control. > >are you using the same modem for your slip connection and bi-directional >uucp transfers via dial up lines? No. Two Telebit Pluses (getting a bit decrepit now, must be about three years old) for uucp dialup. The are locked at 19.2, and answer only in PEP mode. (2400 bps users have their own lines.) We have a T2500 used to for the slip line. It dials on DTR to connect to our other end in V.32 mode. We tried PEP but didn't like it. Our traffic is mostly nntp news and smtp mail. And the PEP mode introduced delays to the IHAVE/SENDME messages that nntp uses. The overall throughput for nnpt is higher with V.32. >what kind of throughput do you get slip-slip (is it higher than uucp-uucp >connections)? Havn't really measured it. We're just happy when it all works. About all we did was compare the average number of articles received via nntp to compare PEP and V.32. I don't have any stat's on kbps throughput for ftp. -- Stuart Lynne Unifax Communications Inc. ...!van-bc!sl 604-937-7532(voice) sl@wimsey.bc.ca
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (10/11/90)
In article <2170@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >In article <2461@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: > >>van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow >>control. > >How can you pump data at 19.2k bps into a modem which can only >transmit it at 17-18k bps without using flow control? With uucp you only ever send a maximum of 220 bytes of data before stopping and waiting for an ack packet. The modem will not send an ack when it no longer has enough buffer space. But it always can receive without error the three packets (220 bytes) that you will send without acknowledgement. This will also work between two Unix systems. Again because the serial driver will always buffer at least 220 bytes without loosing anything even if uucico has been swapped out. It's most likely the reason that the packet size has been kept at 64 bytes. Three of them will fit into the default buffer on modern (post V7) Unix's (255 bytes). The big problem that people tend to confuse this with is character overrun. Where the receiving system just cannot receive the data at that speed and looses characters even though it's buffer is not full. -- Stuart Lynne Unifax Communications Inc. ...!van-bc!sl 604-937-7532(voice) sl@wimsey.bc.ca
mjs@cbnews.att.com (martin.j.shannon) (10/12/90)
In article <2502@van-bc.wimsey.bc.ca>, sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: > In article <1990Oct9.161454.10476@cbnews.att.com> mjs@cbnews.att.com (martin.j.shannon) writes: > >In article <2461@van-bc.wimsey.bc.ca>, sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: > >> In article <1990Oct8.195418.1817@cbnews.att.com> mjs@cbnews.att.com (martin.j.shannon) writes: > >> > >I beg to differ. 'e' protocol does *NO* *ERROR* *CHECKING*. This is > > Hm. Now if I could just find an off the shelf uucp that offer's 'e' for my > Xenix system, or my SCO UNIX system. Or any of the standard System V > platforms. Hmmm. Did you try any? I know that ISC 2.0.2 includes 'e' protocol. Since ISC has it, it wouldn't surprise me if it was in the porting base for SVR3.2. That implies that ESIX and others should have it, too. > Any idea when AT&T will be offerring 'e' as a standard part of > their uucico? You're in a better position than I am to know. See my .signature below and my guess above. I am not currently connected with the folks who develop the UNIX System, and even if I was, it is certainly not my place to disclose policy on such matters. Sorry. > I'd love to be > able to use 'e'. But I'm stuck with all of these inferior type uucico's > which only have 'g'. All I can suggest is "try it". Use the protocol subfield in either the Systems file, or the protocol subfield of the Devices file (no idea where it is in either of these files). The docs have all the info (except which protocols are actually supported, natch). I don't want to rely on some fuzzy recollection of what I did. > So I guess I just assume that if most uucp's don't > offer 'e' then the default has to be 'g'. I'd love to hear different though. > Keep us informed. Thanks. Yes, the default is 'g'. Notice that you don't specify that 'g' protocol is to be used in any of your uucp files. You have to actively edit one to get 'e' protocol. To find out if a remote site supports it, use Uutry and look for the "Pge" message (that's what ISC 2.0.2 gives); if 'e' appears in that string, your neighbor does have it. Additionally, to verify that you're requesting to use 'e', make sure that your machine responds with "Ue". Remember that you *must* have an error-free link, *including* hardware flow control, if you want to make this work. It does for me. -- Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ, USA (Affiliation is given for identification only: I don't speak for them; they don't speak for me.)
mjs@cbnews.att.com (martin.j.shannon) (10/12/90)
In article <1990Oct10.164315.1594@nstar.uucp>, larry@nstar.uucp (Larry Snyder) writes: > my uucico doesn't support the e protocol - where can one obtain > source code for a version that does (so it runs under 386 unix?) I don't *know* of any source for uucico, but you might look at GNUUCP or FSUUCP for starters. But, I'm curious, what flavor of 386 UNIX System are you using that doesn't support 'e' protocol? -- Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ, USA (Affiliation is given for identification only: I don't speak for them; they don't speak for me.)
gemini@geminix.in-berlin.de (Uwe Doering) (10/12/90)
sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: >In article <2170@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >>In article <2461@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: >> >>>van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow >>>control. >> >>How can you pump data at 19.2k bps into a modem which can only >>transmit it at 17-18k bps without using flow control? > >With uucp you only ever send a maximum of 220 bytes of data before stopping >and waiting for an ack packet. The modem will not send an ack when it no >longer has enough buffer space. But it always can receive without error the >three packets (220 bytes) that you will send without acknowledgement. Stuart, I think you didn't read the original article of this thread very well. The statement about uucico needing hardware flow control refered to the `e' protocol. This has nothing to do with the `g' proto. `e' proto is a streaming protocol and doesn't have the windowing technique that `g' proto is using. If only works over error free channels that do their own flow control. Therefor your computer as well a the modem has to have hardware flow control. `e' proto was developed for LANs. Due to this design goal most implementations in use today have a flaw that makes it unreliable over serial line. It simply gets stuck under certain conditions. This has to do with the message receiving function assuming that messages will arrive in one single packet (which is true for LANs), whereas error free modems do their own packetizing which usually confuses the uucico. It took months until I discovered the reason for this instability. I don't know whether this is fixed in newer releases of HDB UUCP. At least in ISC 2.0.2 it isn't fixed. Don't know about ISC 2.2. Therefor, try it out if you have `e' proto but don't be disappointed if it doesn't work. Note that both sides need a clean `e' proto. This makes it even less likely that you can use it in the real world. :-( Uwe -- Uwe Doering | Domain : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | Bangpath : ...!unido!fub!geminix!gemini
larry@nstar.uucp (Larry Snyder) (10/13/90)
gemini@geminix.in-berlin.de (Uwe Doering) writes: >`e' proto was developed for LANs. Due to this design goal most >implementations in use today have a flaw that makes it unreliable >over serial line. It simply gets stuck under certain conditions. >This has to do with the message receiving function assuming that >messages will arrive in one single packet (which is true for LANs), >whereas error free modems do their own packetizing which usually >confuses the uucico. It took months until I discovered the reason >for this instability. I don't know whether this is fixed in newer >releases of HDB UUCP. At least in ISC 2.0.2 it isn't fixed. Don't >know about ISC 2.2. Where in the Systems file (please give an example) of where the e goes (we run ISC 2.20 and would like to try it)? -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
root@zswamp.fidonet.org (Geoffrey Welsh) (10/13/90)
> From: john@jwt.UUCP (John Temples) > Organization: Private System -- Orlando, FL > > How can you pump data at 19.2k bps into a modem which can only > transmit it at 17-18k bps without using flow control? If they are only using windowed protocols (e.g. UUCP-g), the TB's 1.75K buffer will keep ahead of the host's transmissions. -- 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 No one pays me enough to represent any opinions but my own.
aris@tabbs.UUCP (Aris Stathakis) (10/15/90)
In article <2502@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: >Hm. Now if I could just find an off the shelf uucp that offer's 'e' for my >Xenix system, or my SCO UNIX system. Or any of the standard System V >platforms. Any idea when AT&T will be offerring 'e' as a standard part of >their uucico? You're in a better position than I am to know. I'd love to be >able to use 'e'. But I'm stuck with all of these inferior type uucico's >which only have 'g'. So I guess I just assume that if most uucp's don't >offer 'e' then the default has to be 'g'. I'd love to hear different though. >Keep us informed. Thanks. Well, I just got a (supposedly) PD implementation of the HDB uucp suite of programs. Its uucico included the 'g' 'e' 'x' and 'd' protocols. Since source is available, it shouldn't be hard to add other protocols such as the 'f' protocol. I got this little gem via anon-uucp from 'anomaly' which is dedicated to archiving source code for Xenix. Here is the login info: phone: 401-455-0347 [PEP] login: xxcp passw: xenix For a list of all files available, request the file ~/SOFTLIST. For the PD HDB implementation, request file ~/archives/hdbuucp.tar.Z Hope this helps! Aris -- Aris Stathakis | Bang: ..!uunet!ddsw1!olsa99!tabbs!aris or aris@tabbs.UUCP - - - You cannot achieve the impossible without attempting the absurd -
davem@nro.cs.athabascau.ca (10/15/90)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > > > From: john@jwt.UUCP (John Temples) > > Organization: Private System -- Orlando, FL > > > > How can you pump data at 19.2k bps into a modem which can only > > transmit it at 17-18k bps without using flow control? > > If they are only using windowed protocols (e.g. UUCP-g), the TB's 1.75K > buffer will keep ahead of the host's transmissions. > -- The HST and other error correcting modems use the CTS and DSR lines to "handshake" with their host computer, telling it when to stop sending data while the modem deals with what's already in its buffer. When it's ready for more, the modem sets the line high and the computer starts sending again. It's not a new concept; serial printers have operated like this for years and parallel printers use a ready/busy line in the same manner. Dave McCrady | ersys!davem@nro.cs.athabascau.ca Edmonton Remote Systems | 13324-138 Street | BBS: (403)-454-6093 300-9600 bps (HST) Edmonton, AB Canada T5L 2B4 | USENET (403) 452-3254 300-2400 bps
gemini@geminix.in-berlin.de (Uwe Doering) (10/16/90)
larry@nstar.uucp (Larry Snyder) writes: >gemini@geminix.in-berlin.de (Uwe Doering) writes: >> [stuff about HDB `e' protocol deleted] > >Where in the Systems file (please give an example) of where the e >goes (we run ISC 2.20 and would like to try it)? You can put the desired protocol character either into the Systems file: fub Any;5 HST,e 19200 <phone#> ogin:-\r\d-ogin: Ugeminix ssword: <password> or into the Devices file: HST,e ttyF02 ttyF02 19200 HSTARQ If you want to try `e' proto over the modem I think you should put the `e' character into the Systems file as you need to set it on a per system base. Note that the HDB default for modem devices is ACU. I have changed this on my system to HST, PEP, V32, V22 etc. so that I can give every system its own specific dialer string (via the Devices file which contains at least one line for each modem type). To test whether `e' proto works I use the following command: uucp <remote>!~/<filename> <local>!~/ <remote> is the site you want to use `e' proto with. Make sure that the file indicated by <filename> is in the remote site's uucppublic directory. <local> is replaced with your own site name. Try this three or four times. If the conversation doesn't get stuck you have a fixed uucico. Uwe -- Uwe Doering | Domain : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | Bangpath : ...!unido!fub!geminix!gemini
jpr@jpradley.uucp (Jean-Pierre Radley) (10/18/90)
In article <1990Oct10.164315.1594@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: > >my uucico doesn't support the e protocol - where can one obtain >source code for a version that does (so it runs under 386 unix?) An article came across here lately in comp.archives and/or comp.unix.xenix.sco concerning a repository of source code for SCO systems. Among its listings is uucp-hdb code, somehow coming from Microport. (beats me, I thought it was copyright stuff ?!?) So if you don't find that article in your news directories, inquire of mpd@anomoly.sbs.com who seems to own the systm with that source code and a couple other dozen other interesting pakages. -- Jean-Pierre Radley HIGH-Q jpr@jpradley CIS: 72160,1341
bh1e+@andrew.cmu.edu (Brendan Gallagher Hoar) (10/19/90)
Is there any anonymous FTP site that I can get the HDB uucp source from? I also need uucp documentation (information on protocals, etc.) Any help would be appreciated, and I'm sorry if I sent this to the wrong person or group, as I have no idea where to start looking... Brendan G. Hoar bh1e+@andrew.cmu.edu Carnegie Mellon, Inc.