Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cbmvax!grr From: grr@cbmvax.UUCP (George Robbins) Newsgroups: comp.dcom.modems Subject: Re: Trans-atlantic uucp with Telebit modem Message-ID: <7387@cbmvax.UUCP> Date: 21 Jul 89 04:22:31 GMT References: <265@hhb.UUCP> <1989Jul19.160009.18318@utzoo.uucp> Reply-To: grr@cbmvax.UUCP (George Robbins) Organization: Commodore Technology, West Chester, PA Lines: 121 In article <1989Jul19.160009.18318@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > In article Bob Sutterfield writes: > >> I need to establish a UUCP connection with a site in the U.K... > > > >Trailblazers are legendary for squeezing the last bit of bandwidth > >juice from the worst imaginable lines... > I seem to recall Rick Adams saying that London, England is the one place > on Earth that even a Trailblazer can't connect to reliably. They will > deliver 4-5kbps dependably in India, where local calls at 300 baud are > impossibly unreliable (!), but not in London. One might also might want to take note of the discussion here a while back about some settings that disabled short packets or something like that, allegedly making the TB+ work reasonably well over some kinds of international connection where they had previously failed... I think Rick's London comments preceeded these "discoveries" so perhaps there is some hope for such sad parts of the universe. Here are some extracted high point: ' >From: jbayer@ispi.UUCP (Jonathan Bayer) ' Date: 26 Mar 89 17:09:53 GMT ' In article <729@impch.UUCP> patg@impch.UUCP (Patrick Guelat) writes: ' > ' >I think there is an undocumented register in v4.0 of the firmware, that allows ' >you to disable the little packets (the ones for interactive use). As far as I ' >can remeber it's register 120 that allows you to set different packet modes. ' >Possibly you have to set 120=2 to allow long packets only, but I'm not ' >sure.. Perhaps telebit can answer this and tell us if there are other ' >undocumented registers. ' ' I was recently talking with Bob Boynton at Telebit, and the subject of ' my problems connecting with UUNET over the 800 lines came up. He ' described register s120, and suggested I try setting it to 2. I did, ' and all my problems went away. I have included a short description of ' the register below. It is a bit-mapped register, and using other values ' won't do anything. Bob said that using a value of 2 might come up with ' a net loss of about 15% throughput, however I have not noticed any ' reduction. ' ' s120= 0 when modems connect, and exchange info, will attempt to ' connect at the shortest possible packet ' 12 forces modem to abondon micropacket (faster on long ' distance lines) ' 2 long packets ' ' ' A suggestion he suggested was to turning the speaker on at all times ' (atm2). If you hear a lot of retrains (period of silence followed by ' re-syncing sound heard upon initial connect) then try setting s120=2. ' ' ' ' ============================================================================= ' ' Reply-To: pete@octopus.UUCP (Pete Holzmann) ' ' Rather than try more homebrew solutions, I actually called Telebit product ' support yesterday. Here's what they said (and the remaining questions I ' will call back for today, and post a second message with the answers): ' ' 1) No need to go back to rev 3.0. The new 'micropackets' in the 4.0 ROMs ' can cause havoc on low quality connections. Setting S120=12 disables ' micropackets and makes your connection look just like rev 3.0. If that ' isn't enough, go to S120=2, which also disables short packets, leaving ' you just 'long' packets. That will make interactive response terrible, ' but should make things happier for file transfers. ' ' 2) It turns out that the retrains-leading-to-connection-death syndrome is ' usually caused by the following: on an international connection, the ' first part of any burst of information is often chopped off by the ' phone connection (satellite echo cancellers? I don't know...). Normally, ' this would destroy the first part of a data packet. If too much of this ' happens, the modems will retrain. If it happens a LOT, they'll retrain ' a LOT, and eventually give up. To solve this, use the J6S36 register ' (that is NOT a typo: it is a hidden debug register...). The default ' value is 0. As you increase the value to 1,2, or 3, you cause an ' increasing period of "guard tone" to be inserted before each packet ' is sent. The guard tone gets chopped rather than your data, and you ' don't have any retrains any more. The guy I talked to suggested starting ' at J6S36=2, increasing to 3 if that doesn't help, decreasing to 1 if ' it works great (just in case you can get along with less tone). ' ' 3) If S120 is non-zero, it will show up in your ATN?. J6S36 will never show ' up. ' ' 4) From personal experiment, S120 *is* saved by AT&W. I have no easy way ' to tell whether J6S36 is saved. ' ' ============================================================================== ' ' >From: kunkee@ficc.uu.net (randy kunkee XNX MGR) ' Date: 24 Mar 89 04:38:41 GMT ' ' | 1) No need to go back to rev 3.0. The new 'micropackets' in the 4.0 ROMs ' | can cause havoc on low quality connections. Setting S120=12 disables ' | micropackets... ' | but should make things happier for file transfers. ' | ... ' | a LOT, and eventually give up. To solve this, use the J6S36 register ' | (that is NOT a typo: it is a hidden debug register...). The default ' | value is 0. As you increase the value to 1,2, or 3, you cause an ' | increasing period of "guard tone" to be inserted before each packet ' | ... ' | 3) If S120 is non-zero, it will show up in your ATN?. J6S36 will never show ' | up. ' | ... ' | ' | b) Must these parameters be used at both ends of the line? ' | ' ' No, not according to my conversations with Telebit. Set one end and the ' other follows suit. This makes a lot of sense. Just 'cause you can't ' do micropackets across a satellite is no reason to have to disable them for ' local phonecalls too. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)