Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!zephyr.ens.tek.com!tektronix!sequent!mntgfx!bgriffin From: bgriffin@mentor.com (Brian Griffin) Newsgroups: comp.sys.amiga Subject: re: DNET Message-ID: <1990Mar15.234740.7379@mentor.com> Date: 15 Mar 90 23:47:40 GMT Sender: Brian Griffin Reply-To: bgriffin@.UUCP (Brian Griffin) Distribution: usa Organization: engr Lines: 108 In article <1990Mar7.000117.6984@ncsuvx.ncsu.edu> you write: >In a previous article, kent@swrinde.nde.swri.edu (Kent D. Polk) wrote: > >]Also, I have been loaned an Telebit Trailblaser for a while & tried to >]run Dnet in the PEP (19200) mode, but severe thrashing between Dnet and >]the Trailblazer occurred. My effective throughput is about 600 baud in >]PEP mode (needless to say, I went back to 2400 baud). I have tried >]about every combination of setup parameters with Dnet & the >]trailblaser, but none work. At first it appeard to be a handshake >]problem, with dnet maybe loosing characters when the TB spits out a >]burst of chars, but I'm not so sure now. > >I think that this particular problem lies outside of DNET. I also got >ahold of a trailblazer for awhile, and ran into the same difficulties. >I was just using terminal emulators doing file transfers (typically >Zmodem in JRCOMM, various protocols in other things like Handshake or >VT100) and I found that my throughput always seemed to be around 600 >cps (about 570 actually). JRCOMM's info window showed that packets were >continuously being resent (about 1 in every 4 or 5 packets) ... I strongly >suspect that this IS some sort of handshaking problem. > I'm currently using a trailblazer T2500 as I type. I've experenced the problems you speak of using kermit and xmodem. The problem is the modem buffers things and sends stuff in bursts. This kinda defeats the high speed transmissions during file transfers since the modem doesn't know when a packet is finished. To get around the problem the modem knows about some common file transfer protocols, specificly kermit, xmodem/ymodem, and UUCP "g" protocol. By telling the modem what file transfer protocol you're using it can then determine when a packet is done and it will fire it off immediately and turn the ACK back around. Now for the tricky part. You must set register S111 for the protocol you intend to use before you make your connection. The modem on the other end must be setup with the same protocol or be setup to take the protocol specified by the remote modem (i.e. yours). After doing this my file transfers became what I expected them to be (no numbers but it is fast). If you forget to set the protocol before making the connection or you want to change it you can force the modems to renegotiate the protocol as follows: "Changing this register (S111) after a connection is established will not change the protocol supported for the session in progress unless an &R1 command is issued to the modem." This also works (I've had to use it several times). Example: +++ -- get modems attention OK -- modem responds ats111=10 -- set the protocol (10=kermit) OK -- modem respondsat at&R1 -- renegotiate OK -- modem responds CONNECT FAST -- modem responds with new connection ato -- go back online >I also did a lot of experimenting with handshaking options, to no avail. >The proper way to configure this beastie should be to enable hardware >handshaking (CTS,RTS). I turned CTS/RTS handshaking on via Preferences, >inside my terminal program, and within the modem (setting some register). >Nothing seem to help (let me know if you have answers!). > My experience has shown that the handshaking does not matter. At least it doesn't seem to affect performance. >------------------------------------------------------------- > >A semi-related question about throughput: > >The modem does all sorts of data compression techniques to get its speed. >Protocols like Zmodem also do compression. >Will the compression done by Zmodem (or "compress" or "arc" or "squeeze"...) >likely *decrease* the transmission rate when using data compression modes >(MNP or PEP) on the modem? (since applying a compression technique to data >which is already well compressed often yields *worse* results). No, I don't believe there is any problem here. There is a note in my manual that says (and I quote) "For additional information when configuring the modem for UUCP protocol support, send electronic mail request, which includes the type of system in which the modem will be used, to: {ames,sun,uunet}!telebit!modems or call your Telebit Technical Support rep..." It may be worth sending these guys some mail about these specific DNET problems. > > > ==[ ml@eceris.ncsu.edu (128.109.135.109) ]== One final note. I've experienced some strange behavior when using emacs on the remote system when I have a protocol defined. Since emacs uses alot of control sequences for commands I think the modem gets confused sometimes thinking a data packet is starting. I've never lost data, I just get strange, long periods of delay. If i disable the protocl (S111=0) then the problem goes away. You win some, you loose some... Hope this helps. __ mntgfx!bgriffin /__) . __ /___)_/-,_/_(_(_/V/_ /