chris@alderan.uucp (Christoph Splittgerber) (03/11/91)
This uucp-side uses a T2500 for its mail/news - links and everything
works just fine with about 1400 char/sec.
However, when I do very long distance links (e.g. to the USA) in PEP
modus, my Trailblazer does behave very strange. I understand that I
should not expect 1400 char/sec but just imagine this:
1) I get the CONNECT/FAST/UUCP
I send <CR>
2) I get the half of the announcement from the remote host. E.g:
University of Whatever, Public Access Un
3) Then a very strange delay for about 30 sec.
4) Then the second half of the announcement from the remote host. E.g:
ix System
Login as guest or nuucp
login:
5) I sent nuucp
6) Another strange delay
7) Several of those delays happen during protocol negotiation. And I see
several "alarm 1, alarm 2, alarm ..."
8) Once the file transfer is started those long delays are gone. But the
transfer rate drops to about 300 char/sec. :-(
I have seen this also when I don't connect with /UUCP e.g. when I just
login a BBS in PEP-Modus. To me, it looks like that the modem(s) are
buffering data, and don't transmit or retransmit the data as long their
buffer is not full or some long timeout value (+30 sec.). I know that
this sounds stupid, but that's the way it looks like.
Like I said, this only happens when I call a host in the USA. All my
PEP connections here in Germany run just fine.
Just because it might be something obvious, I include my register
settings:
E0 F1 M0 Q8 P V1 W0 X3 Y0 &P0 &T4 Version GE6.01-T2500
S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006
S10=007 S11=070 S12=050 S18=000 S25=005 S26=000 S38=000
S41=000 S45=000 S47:100 S48=000 S49=000
S50=000 S51:254 S52:002 S54:002 S55=000 S56=017 S57=019 S58:002 S59=000
S61=150 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255 S69=000
S90:001 S91=000 S92:001 S93=008 S94=001 S95=000 S96=001 S97=000 S98=003
S100=000 S101=000 S102=000 S104=000 S105=001 S106=000 S107=020
S110:001 S111:030 S112=001
S121=000 S130:003 S131:001
S150=000 S151=004 S152=001 S153=001 S154=000 S155=000
S160=010 S161=020 S162=002 S163=003 S164=007 S255=000
Any ideas ?
Chris
--
************************ Brain fault (core dumped) *************************
Replies-To: chris@alderan.uucp UUCP: uunet!mcsun!unido!alderan!chris
Phone: +49 711 344375 Fax: +49 711 3460684root@zswamp.fidonet.org (Geoffrey Welsh) (03/12/91)
Christoph Splittgerber (chris@alderan.uucp ) wrote: >1) I get the CONNECT/FAST/UUCP > I send <CR> >2) I get the half of the announcement from the remote host. >E.g: > University of Whatever, Public Access Un >3) Then a very strange delay for about 30 sec. >4) Then the second half of the announcement from the remote >host. E.g: > ix System > Login as guest or nuucp > login: The modems are probably retraining. It is highly likely that the other end has not properly configured handshaking between their modem and host, so data has been lost while the modems retrained. -- 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 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
jiro@shaman.com (Jiro Nakamura) (03/12/91)
chris@alderan.uucp (Christoph Splittgerber) writes: > >However, when I do very long distance links (e.g. to the USA) in PEP >modus, my Trailblazer does behave very strange. I understand that I >should not expect 1400 char/sec but just imagine this: [ strange delays ] Sounds like your Trailblazers are having a hard time keeping the micro packets alive and are busy retransmitting them. I'd recommend e-mailing to modems@telebit.com and asking for their "ADVERSE COMMUNICATIONS LINKS" information. Most notably, you may have to tell the modem to stop using micro packets. Basically, their are three levels for bad lines: ---- Quoted from Adverse Communications Links ------- The three levels are in order of severity of line difficulties, from minor to major. Level 1. AT S120=12 J6 S36=1 Generally, Level 1 will have a very minor impact on performance, both in interactive use and file transfer. It is useful, however, for achieving a degree of reliability, even when the communication lines are very good. The J6 S36 register may be incremented up to 4 in order to better survive adverse line conditions. Level 2 AT S120=2 J6 S36=2 Level 2 will impact interactive performance severely while file transfers remain at close to normal performance. Level 3 AT S120=3 J6 S36=3 Level 3 is a last resort setting which will severly impact interactive performance and limit file transfer speeds to a maximum of 6000 bps. Data compression, S110=1, can make up some of the difference, but only if the data has not been previously compressed. The S121=1 register will enable compensation for echo cancellation on the circuit, and can be enabled at any of these levels. If a stand alone modem is in use, the special register commands should be sent to the modem and saved to Non-Volatile Memory, by sending the save command "AT&W". In situations where a mixture of local and long distance calls are being placed, it is recommended that these special settings be made in a modem initialization file or that the A/B selection switch be used. ==================================== For the meaning of the S120, S36, and J register settings, please get a hold ofthe whole document. I would be wasting net bandwidth to include the whole thing. - Jiro Nakamura jiro@shaman.com -- Jiro Nakamura jiro@shaman.com Shaman Consulting (607) 253-0687 VOICE "Bring your dead, dying shamans here!" (607) 253-7809 FAX/Modem
gandrews@netcom.COM (Greg Andrews) (03/13/91)
In article <356@alderan.uucp> chris@alderan.uucp (Christoph Splittgerber) writes: > >However, when I do very long distance links (e.g. to the USA) in PEP >modus, my Trailblazer does behave very strange. I understand that I >should not expect 1400 char/sec but just imagine this: > > [description of long delays during login deleted] > >To me, it looks like that the modem(s) are buffering data, and don't >transmit or retransmit the data as long their buffer is not full or some >long timeout value (+30 sec.). I know that this sounds stupid, but that's >the way it looks like. > >Like I said, this only happens when I call a host in the USA. All my >PEP connections here in Germany run just fine. > You're probably seeing the modems retraining. A PEP retrain takes 10 or 15 seconds, and the modems can often achieve a long distance link only to retrain very soon afterward. Sometimes the modems will need to retrain three or four times before they are able to overcome problems in the phone line. Very long distance calls and/or satellite links like calls from Europe to the USA can have this trouble. You can check if this is really happening by turning your speaker on all the time and listening to the sounds the modems make. Set M2 and adjust S61 to a comfortable speaker volume and listen to the connection. A retrain sounds just like the PEP answer tones, so it's easy to tell when the modems are retraining. After a few retrains the modems have tuned the PEP characteristics to make the connection stable, and the communications continue without interruptions. You can adjust a couple of registers in the modem to put PEP into the same state without needing to perform retrains. Telebit tech support can advise you of which registers and what values to use. You can send e-mail to modems@telebit.com or uunet!telebit!modems if a phone call would cost too much from Germany. -- .-------------------------------------------. | Greg Andrews | gandrews@netcom.COM | `-------------------------------------------'
devil@techunix.BITNET (Gil Tene) (03/15/91)
In article <356@alderan.uucp> chris@alderan.uucp (Christoph Splittgerber) writes : > >However, when I do very long distance links (e.g. to the USA) in PEP >modus, my Trailblazer does behave very strange. I understand that I >should not expect 1400 char/sec but just imagine this: > > ( description of long (~30 sec.) delays and slow throughput.) > I have a setup that works pretty well for overseas calls. It uses two undocumented T2500 registers : S120 and J6 S36. I suggest that you keep your speaker on for the duration of the call using ATM2. It is a good idea to listen to the modem and try to notice what is happening (I think I should be able to whistle PEP by now :-)). What you have described above are obviously PEP retrains, which are as close to loosing a connection as you can get. A retrain on long distance lines typically takes about 15 sec. What works well for me is : AT S120=12 J6 S36=2 S121=1 To detail : S120=12 means no use only LONG packets, no micro or medium sized packets. This cuts down heavily on retrains. It makes interactive links much worse but does'nt really hurt throughput. J6 S36=2 sets the beep length of a beep sent ahead of a packet. This deals with a problem caused by compansion: where the beggining of a packets gets chopped off because of a period of silence just before it. Unfortunatly this register is not negotiable, which means that only the packets going OUT from you modem get saved by this feature. S121 is documented, it takes care of echos on long distance lines. You shouldn't expect miracles. I get about 300-500 bps FROM UUNET, and about 500-700 TO UUNET (that J6 s36 makes the difference). I think this could be better, but I wouldn't expect anything more than 800bps for that distance. BTW, does anyone know if J6 S36 is negotiable in the V7.0 PROMs ? I really wish it was... HtH, -- Gil. -- -------------------------------------------------------------------- -- Gil Tene "Some days it just doesn't pay -- -- devil@techunix.technion.ac.il to go to sleep in the morning." -- --------------------------------------------------------------------