[hylafax-devel] Re: Another Class1 question

[Dr. Harald Pollack <Harald.Pollack@Datanews.at>]

On 12 Jun 2000 10:16:05 +0400, Dmitry Bely wrote:

Hello Dmitry!

>> >Hmm, I assumed (basing on our previous talks) that CONNECT (== HDLC flags
>> >detection) timeout was specified by T.30 T4 timer (4.5 sec for manual
>> >units). Wrong?
>>
>> :-) obviously, because we talked about RESPONSE-RECEIVED clause :-)
>>
>> Here it's the COMMAND-RECEIVED situation,
>
>No. The receiver is sending CSI and DIS and waiting for the response. This is
>"RESPONSE REC" node of Fig. 5.2B/T.30 -- I just have checked T.30.

Well, I think, we both will be right (and wrong :-). The problem is, that T.30 is - in this 
situation - not quite consistent.
>
>> which is handled quite different. In consequence
>> to T.30 you should NEVER wait,
>
>Sure?

Yes and no :-)

You are right, when you say, that after point (R) of receiving station, there is a 'RESPONSE-REC' 
decision diamond, but if you follow the 'yes' branch, you will come to a point, where also a 
'COMMAND-REC' has its 'yes' branch and 'DTC, DIS or DCS' are assumed and checked for. This is the 
point of confusion :-) because I assume, that both 'RESPONSE-REC' and 'COMMAND-REC' - at point 
(F) - are one and the same and should be handled different (for DTC and DCS like COMMAND-REC and 
for DIS like RESPONSE-REC) but nobody knows in front of an unknown frame, what it will contain 
:-)

In a 'formal' way, you are quite right, but I tend to follow the way of experiences :-)

>IMHO T.30 specifies T2 for that purpose:
>
>...
>Time-out T2 makes use of the tight control between commands and responses
>to detect the loss of command/response synchronization. T2 is 6   1 seconds
>and begins when initiating a command search (e.g. the first entrance into
>the  command received  subroutine, reference flow diagram in 5.2). T2 is
>reset when an HDLC flag is received or when T2 times out.
>...

Ok

>
>i.e. T2 shows how long you should wait for command's HDLC flag, if I
>understand this right.

Yes and no (if I understand this right :-)

I fear, the T.30 standard is not as precise as it should be in this conjunction.

The whole decision diagram (from point (R) over point (F) again to point (R)) was never the base 
to invent fax, it looks more that it is a - maybe quick and dirty - description of what was 
available when T.30 was written.

>>  but that's not as senseful as needed. I have found out, that
>> a value between 1 und 2 seconds (for waiting for CONNECT) is practicable, but this is the
>> ONLY remarkable limitation of class 1.
>
>Then what T2 is for?

In my opinion (and experience) it is a timeout for one single command/response sequence, because 
T2 is resetted at start of COMMAND-REC (if HDLC-flag == V.21 carrier is well received). If this 
single T2 test fails (lost of handshake sync) connection is broken.

>My understanding is:
>
>"RESPONSE REC"
>
>|start responce search  |flag (CONNECT)         |whole frame received
>|                       |                       |
>|-----------------------|-----------------------|
> <--      timer1     --> <--      timer2     -->
>
>timer1 = T4
>timer2 = 3.1 sec because (from T.30)

Ok, I agree!

>"COMMAND REC"
>
>|start command search   |flag (CONNECT)         |whole frame received
>|                       |                       |
>|-----------------------|-----------------------|
> <--      timer1     --> <--      timer2     -->
>
>timer1 = T2
>timer2 = 3.1 sec (same as above)

No, I disagree :-) timer1 is not existing at all, first 'decision diamond' (Flag?) in 'no' branch 
immediatly returns with 'NO'. And I simulate this by a (personnel) timeout of 1 - 2 seconds, 
which is based on experiences only. Class 1 protocol lacks a good method of checking ANY carrier, 
so we must loop (fast) for HDLC-flag (== V.21 CONNECT). Your supposed timer2 is in fact the T2 
timer, which has also two 'subtimers' mentioned in the two decision diamonds '200ms delay' and '3 
s delay'. But these two additional subtimers are almost unimplementable in class 1 protocol (when 
modem is not able to distigiush between FCS and carrier errors).

>
>But if you say that timer1 = 2 sec, I will trust you :-)
>

You may trust, but keep in mind, I am a human too, so I am able to make faults.

>> >> >still have no CONNECT after 4.5 seconds (T.30 T4 counter). Why?
>> >>
>> >> have wait too long!
>
>Had I waited less, I would also have no 'CONNECT' after the first try :-)
>

Yes, but you can restart the whole sequence FASTER (in the window of the T2 timeout of 6 sec).

>> Yes, this 'should' also work, but I have use the "'" to emphasise, that there are some
>> firmewares in some modems (I like very much :-) which will not react to any single
>> character and in consequence will not react to CAN.
>
>Oh, Zyxel again goes its own way :-)

Mainly in 1496 series modem, because they was a kind of copy of the ancient Rockwell datapump :-)

>I've just found Sam Leffler's hack,

As I said, Sams approach was excellent, but times had changed :-)

>that worked around Zyxel Class2 "specifics". Unfourtinately this had made
>some other modems unusable:
>
>		/*
>		 * (In some firmware revisions...) The ZyXEL modem
>		 * appears to drop DCD when the remote side drops
>		 * carrier,

This is 100% correct!

> no matter whether DCD is configured to
> * follow carrier or not.

This belongs ONLY to data mode! Unfortunaly, USR modems behave completely other ... and were 
assumed as 'the standard modem' ...

>  This results in a stream
>		 * of empty lines, sometimes* followed by the requisite
>		 * trailing OK.  As a hack workaround to deal with
>		 * the situation we accept the post page response if
>		 * this is the last page that we're sending and the
>		 * page is good (i.e. we would hang up immediately anyway).
>		 */

Best workaround is, to IGNORE DCD in ANY CASE!

>BTW, current algorithm is the following:
>
>	/*
>	 * Our criteria for accepting is that there must be
>	 * no more than 10% non-zero (bad) data and the longest
>	 * zero-run must be at least at least 2/3'rds of the
>	 * expected TCF duration.

This might by mutual exclusive :-) It is also correct, if 1/3 is non-zero ... as long as 2/3 are 
continous zero run.

>> Well, than why you (or your code) will complain pixel count ? If you are quite sure it is
>> EOL, well than stay to your decision :-)
>
>This is not my code yet :-) It's still trying to decode everything between
>RTC (ETX)  and "NO CARRIER".

That's the fault! RTC and DLE+ETX are NOT the same!

RTC is the 'logical' page end, as the remote compressor will see it.

DLE+ETX is the response from local modem, as a consequence to lost of data carrier (quite equal 
what the reason was).

NO CARRIER is a response from modem, mainly to show us, that modems command mode is reentered 
(like OK response) and only secondary (and redundant) a sign of real lost of carrier.

> Obviously the bug, but I am trying understand,
>why this garbage happened there -- was it supplied by sender or it was our
>side that appended it?

The garbage is from our side, it is the local demodulator which does not know anything about the 
RTC :-) Keep in mind, that remote sender can deliver RTC code and send also additional garbage 
(hours for hours in worst case :-) as long as data carrier is activ.

>Does Class1 allows such garbage?

Is not depending on class 1, depends on modulation (eg V.29 or V.17 etc).

>> >I don't see how multiple threads could help here.
>>
>> Logging !!! The logfile is written, which will waste time and CPU ...
>
>Do you think that 1.5 sec delay was caused by too slow logging? (decoding
>could not eat so much CPU time).

I hope, it will not be so! But we must  search for that long delay!

>Perhaps it's possible in the worst case
>(yes, I also prefer non-blocking logging :-)) But if the 1.5 sec between
>RTC and "NO CARRIER" was really present, then we had no chances to win the
>game?

If this delay is a result of modem, than we have lost the game, but I think, the modem is much 
faster:

13:12:50.08 Info:     19049 octets received, 18178 bytes extracted, 70 frames saved
13:12:50.08 Receive:  <DLE><ETX>
13:12:50.08 Receive:  <CR><LF>
13:12:50.08 Receive:  NO CARRIER<CR><LF>

13:13:14.80 Info:     25953 octets received, 23448 bytes extracted, 90 frames saved
13:13:14.80 Receive:  <DLE><ETX>
13:13:14.80 Receive:  <CR><LF>
13:13:14.86 Receive:  NO CARRIER<CR><LF>

10:42:37.44 Receive:  <DLE><ETX>
10:42:37.44 Receive:  <CR><LF>
10:42:37.44 Receive:  NO CARRIER<CR><LF>
10:42:37.44 Receive:  29989 characters

10:43:07.06 Receive:  <DLE><ETX>
10:43:07.06 Receive:  <CR><LF>
10:43:07.06 Receive:  NO CARRIER<CR><LF>
10:43:07.06 Receive:  31477 characters

10:43:48.78 Receive:  <DLE><ETX>
10:43:48.78 Receive:  <CR><LF>
10:43:48.78 Receive:  NO CARRIER<CR><LF>
10:43:48.78 Receive:  46013 characters

12:04:17.58 Info:     13769 octets received, 12067 bytes extracted, 46 frames saved
12:04:17.58 Receive:  <DLE><ETX>
12:04:17.58 Receive:  <CR><LF>
12:04:17.58 Receive:  NO CARRIER<CR><LF>

Examples from Zyxel Elite 2864 and Zyxel U90E ...


Mit herzlichen Gruessen / Yours sincerely

Dr. Harald Pollack

Harald.Pollack@DATAnews.at



____________________ HylaFAX(tm) Developers Mailing List ____________________
 To unsub: mail -s unsubscribe hylafax-devel-request@hylafax.org < /dev/null