beyo@beyonet.UUCP (Steve Urich) (05/15/91)
Here is an interesting bit of modemania! My friend and I uucp with our 3b1's. He uses the 3.5 and I use 3.51m. He has a multitech modem with v42bis fixed link rate at 9600. I have a T2500 at 19200 :-). He discovered how to switch from UUCP G protocol to E protocol. Boy what a difference in thoughput! His throughput jumped from an approx avg. 200-226 to 317-960cps. My throughput jumped also the same. Not bad with a connect rate of only 2400 baud. The compression was really working. Even with compressed files it really works better. G protocol looks like x-modem on the RD & SD modem LED's. E protocol looks like z-modem where the SD working at the TX'ing modem and RD working on the RX'ing modem. To enter the change to the protocol you must add ',eg' to the end of the Devices prefix: EX: ACUM24,eg tty000 Thats it! However you must be using a error detection modem or you will have problems. Does anyone know why this works and what would happen if you change the ',eg' to ',ee' or ',ge'??? Steve WB3FTP @ wells!beyonet!beyo@dsinc.dsi.com
burris@highspl (David Burris) (05/16/91)
From article <159@beyonet.UUCP>, by beyo@beyonet.UUCP (Steve Urich): > > My friend and I uucp with our 3b1's. He uses the 3.5 and I use > 3.51m. He has a multitech modem with v42bis fixed link rate at > 9600. I have a T2500 at 19200 :-). He discovered how to switch > from UUCP G protocol to E protocol. Boy what a difference in > thoughput! > > His throughput jumped from an approx avg. 200-226 to 317-960cps. > My throughput jumped also the same. You BETTER have hardware flow control working using the 'e' protocol or you WILL lose data. -- ================================================================ David Burris Aurora,Il. burris@highspl ..!linac!highspl!burris ================================================================
bruce@balilly (Bruce Lilly) (05/18/91)
In article <159@beyonet.UUCP> beyo@beyonet.UUCP (Steve Urich) writes: > ACUM24,eg tty000 > > > Thats it! However you must be using a error detection modem or > you will have problems. > > Does anyone know why this works and what would happen if you > change the ',eg' to ',ee' or ',ge'??? e protocol is designed for use over an error-free channel, such as TCP/IP. Specifying ",eg" says to use e protocol first if it is supported, then g protocol (if e is not supported by the remote system). ",ee" is nonsense (only e protocol would be used, and it makes no sense to repeat the e), ",ge" says to use g protocol if it is supported (I've never seen a uucico that didn't support g protocol), then fall back to e -- in practice this means that g protocol will always be used. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
mhw@fithp (Marc Weinstein) (05/19/91)
From article <159@beyonet.UUCP>, by beyo@beyonet.UUCP (Steve Urich): > > My friend and I uucp with our 3b1's. He uses the 3.5 and I use > 3.51m. He has a multitech modem with v42bis fixed link rate at > 9600. I have a T2500 at 19200 :-). He discovered how to switch > from UUCP G protocol to E protocol. Boy what a difference in > thoughput! > > His throughput jumped from an approx avg. 200-226 to 317-960cps. > My throughput jumped also the same. > Not bad with a connect rate of only 2400 baud. Jeez - that's a hell of a compresion ratio. You sure you're seeing this kind of compression? We've seen UUCP (the xferstats file) report very high throughput, but it's typically off due to short duration granularity problems. Have you demonstrated this kind of throughput sending, say, files of at least 50KB in size? > The compression > was really working. Even with compressed files it really works > better. E allows you to turn off the checksum ACKS in UUCP, which improves throughput. At 2400 baud, we were seeing about a 10% improvement in speed using e vs g. However, e assumes an error free connection, so you should be using MNP or V.42 during the connection. Also, using MNP4 for files already compressed using the UNIX compress utility is better than MNP5, because the MNP5 compression algorithm is less efficient than the UNIX version. And, since MNP provides a pseudo-synchronous connection, you eliminate the start/stop bits between modems and that gives you another 20%. > To enter the change to the protocol you must add ',eg' to the > end of the Devices prefix: > > ACUM24,eg tty000 I've never seen an entry with both protocols specified here. I'm not sure what that means - sending vs receiving?? We just would use 'ACUM24,e'. -- Marc Weinstein {simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL -or- {internet host}!linac.fnal.gov!fithp!mhw
beyo@beyonet.UUCP (Steve Urich) (05/20/91)
In article <1991May18.180655.2944@fithp>, mhw@fithp (Marc Weinstein) writes: > From article <159@beyonet.UUCP>, by beyo@beyonet.UUCP (Steve Urich): <*> [STUFF DELETED] > > > > His throughput jumped from an approx avg. 200-226 to 317-960cps. > Jeez - that's a hell of a compresion ratio. You sure you're seeing > this kind of compression? > <*> Yes, the rate is accurate. Whats also funny is the shorter the file the faster the rate in HDB xferstats become. Because of the calc. it makes. The control files are really strange, sometimes 9000bytes/sec :-))). > demonstrated this kind of throughput sending, say, files of at least 50KB > in size? > <*> Yes, and larger. Using v42bis compressed, even compressed files come over faster then using 'g' without compression. > > To enter the change to the protocol you must add ',eg' to the > > end of the Devices prefix: > > > > ACUM24,eg tty000 > > I've never seen an entry with both protocols specified here. I'm not sure > what that means - sending vs receiving?? We just would use 'ACUM24,e'. <*> ',eg' is used (Thanks to Bruce!) to try 'e' protocol first. IF The host site doesn't have 'e' then it will still use 'g'. If you just use ',e' then it looks for 'e' only. Steve WB3FTP wells!beyonet!beyo@dsinc.dsi.com
mhw@fithp (Marc Weinstein) (05/22/91)
From article <165@beyonet.UUCP>, by beyo@beyonet.UUCP (Steve Urich): > In article <1991May18.180655.2944@fithp>, mhw@fithp (Marc Weinstein) writes: >> From article <159@beyonet.UUCP>, by beyo@beyonet.UUCP (Steve Urich): > > <*> [STUFF DELETED] > >> > >> > His throughput jumped from an approx avg. 200-226 to 317-960cps. >> Jeez - that's a hell of a compresion ratio. You sure you're seeing >> this kind of compression? >> > <*> Yes, the rate is accurate. Whats also funny is the shorter > the file the faster the rate in HDB xferstats become. Because > of the calc. it makes. The control files are really strange, > sometimes 9000bytes/sec :-))). Yeah - I've seen stuff like a 1601 byte file, transferred in 0.001 seconds (right!), so xferstats reports a throughput of 1601000 Bps!!! This system is GOOD! -- Marc Weinstein {simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL -or- {internet host}!linac.fnal.gov!fithp!mhw