tim@nytim.UUCP (Tim's Personal Id.) (03/19/89)
We have telebit Trailblazers operating in the USA and Hong Kong. Within the US we achieve >13000 baud easily. However US/HK throughput is very poor. Watching the lights, it *looks* like there are 7 exchanges then a significant (1-3 seconds) pause before communications continues. Has anyone seen similar performance and fixed the problem ? Both telebits are using version 4.00 ROMs - is there a bug or is it a configuration problem. Thanks in advance for e-mail replies - I'll summarize and post the results. Tim. +---------------------------+ At work: | Tim Stone | UUCP: ...!rutgers!hombre!marob!nytim!tim | Chase Leasing Services Co,| Tel : (212) 552-7132 | 1 Chase Plaza, | Fax : (212) 269-9690 | New York, NY 10081, | | U.S.A. | "God is a comedian playing to an audience too +---------------------------+ afraid to laugh" - Voltaire.
kunkee@ficc.uu.net (randy kunkee XNX MGR) (03/20/89)
In article <404@nytim.UUCP>, tim@nytim.UUCP (Tim's Personal Id.) writes: > We have telebit Trailblazers operating in the USA and Hong Kong. > Within the US we achieve >13000 baud easily. However US/HK throughput > is very poor. Watching the lights, it *looks* like there are 7 > exchanges then a significant (1-3 seconds) pause before communications > continues. > > Has anyone seen similar performance and fixed the problem ? > Both telebits are using version 4.00 ROMs - is there a bug or is it a > configuration problem. Last year (Sept. 88) we purchased some TB+ modems along with our other half in England hoping to get great e-mail service. It worked great for about 2 or so months and then suddenly we started to really eat it on performance. We'd call and sometimes not even get carrier, or connect and loose the line before the uucp login could succeed, or just drop in the middle of a transfer. Funny thing is that, through all of this, if the Brits initiate the call, they get through and can get all of the work performed just fine! Several things have happenned since we first set up: our ROLM system was "upgraded" with more capacity for extensions (no flames about going through the ROLM, please -- we tried a direct line with little or no better results); our long distance carrier (unknown to me) started switching over to "One plus dialing" (apparently, the ROLM system, invisibly except for time, was calling a number and entering an access code whenever we dialed a long distance number). Now I can code the ROLM to give me an AT&T trunk instead of our normal carrier (of course it all really goes through AT&T anyway), and that seems to have helped but not enough. One thing that is really strange is that when we connect, we just get CONNECT, not CONNECT FAST, not CONNECT FAST/COMP/UUCP (which is what we really should be getting). Yes, we have Q0 and X3, so we should get the whole thing right? We call other systems in the U.S., the only difference is the number, and here we get FAST/COMP/UUCP! I'm sure they have their registers set correctly at the other end to enable COMP/UUCP. In any case, the FST light on the modem is on, but the modem doesn't give the extended result code it should. I've talked to Telebit and need to talk to them some more, but if anyone has any thoughts that might help (we're playing with S120 and S36) I'd like to hear them. -- Randy Kunkee Ferranti International Controls Corporation 12808 W. Airport Blvd. Sugar Land, TX 77478 UUCP: uunet!ficc!kunkee ph: (713) 274-5132
piet@cwi.nl (Piet Beertema) (03/21/89)
Watching the lights, it *looks* like there are 7 exchanges then a significant (1-3 seconds) pause before communications continues. Has anyone seen similar performance Yes. and fixed the problem ? yes: go back to 3.0 software level. Both telebits are using version 4.00 ROMs The problem is in 4.0; and you can *hear* it going wrong: first give "atm2" to constantly enable the speaker, then set up the connection by hand. And then listen to the endless retrains/renegotiates of the modems trying to get "in sync" again; those are the pauses you observe. -- Opinions expressed above reflect those of my employer, except when they don't. Piet Beertema, CWI, Amsterdam (piet@cwi.nl)
vjs@rhyolite.SGI.COM (Vernon Schryver) (03/21/89)
In article <3474@ficc.uu.net>, kunkee@ficc.uu.net (randy kunkee XNX MGR) writes: > > ...Last year (Sept. 88) we purchased some TB+ modems along with our > other half in England hoping to get great e-mail service. It worked > great for about 2 or so months and then suddenly we started to really > eat it on performance.... > > Randy Kunkee > Ferranti International Controls Corporation > 12808 W. Airport Blvd. Sugar Land, TX 77478 > UUCP: uunet!ficc!kunkee ph: (713) 274-5132 I had similar problems with TB's between the Bay Area (in CA) and KY (near eye sight of Cincinnati) using either MCI or SPRINT. There didn't seem to be enough [?bandwidth?] to allow the TB's to work. They'd retrain every few seconds, and give up and drop the connection after 10-30 seconds, if they got carrier at all first. Turning on the speaker during data was illiminating, as was checking the numbers while the link was trying to be up. A nice fellow at Telebit gave me some magic &J and S112 numbers to try, but they did not help significantly. Switching to AT&T solved the problem. This despite the fact that the MCI circuits sounded better to my ear. This bugged me since I hold grudges against Mother Bell, being able to remember Carterphone and $15/mon DAA's and accustic couplers and racks of obsolete 103's that they wouldn't allow us to replace and ... So my dialer scripts have lots of '10xxx1' prefixes. Vernon Schryver Silicon Graphics vjs@sgi.com
kunkee@ficc.uu.net (randy kunkee XNX MGR) (04/01/89)
In article <3474@ficc.uu.net>, kunkee@ficc.uu.net (randy kunkee XNX MGR) writes: > ... > One thing that is really strange is that when we connect, we just get > CONNECT, not CONNECT FAST, not CONNECT FAST/COMP/UUCP (which is what > we really should be getting). The answer is: in the dial string we were using X's appended to the end to make uucico wait longer before giving up. After pulling my hair out (of which I don't have much to afford this sort of behavior) I discovered that after my call if I printed the registers the X register magically went from X3 to X0. Hmmph, I say. Apparently the Trailblazer+ is inter- preting the X's in the dial string as an X command and defaulting it to zero. I have reported this to Telebit. We have 4.0 proms. -- Randy Kunkee Ferranti International Controls Corporation 12808 W. Airport Blvd. Sugar Land, TX 77478 UUCP: uunet!ficc!kunkee ph: (713) 274-5132