Re: [hylafax-users] V.34-Fax, was: large multiport systems

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Now that HylaFAX CVS HEAD supports Class 1.0 and V.34-Fax in Class 
1/1.0 I can respond to some of the issues you raised back in 
September...

On 2003.09.10 17:27 Darren Nickerson wrote:

> There are a couple of V.34 advantages I'd like to highlight/excerpt
> from that body of "propaganda" you love to hate that you might want to
> take into account, since some of them are at least partially relevant
> to even single-page faxing:
>
> 1. V.8 fast handshaking only occurs when both sender and receiver
> support it,

This is true.

> so there's no time lost trying to negotiate this
> capability.

Well, the sender and receiver don't try to negotiate it, but the 
receiver does initially send the ANSam signal instead of CED.  The 
sender will be sending CNG, and if it detects ANSam at the receiver 
then it stops the CNG signal and starts ANSam also.  If the receiver 
doesn't get a response to the ANSam signal within a short period of 
time then it will start sending CED.  So, a non-V.34 fax to a 
V.34-capable receiver will take about 3 seconds longer to begin than if 
the receiver were not V.34-capable.

By "handshaking" I refer to the process which occurs during the time 
indicated on the receiver between ATA and CONNECT.

A typical V.34 -> V.34 fax will take about 14.5 seconds to handshake.
A typical anything -> non-V.34 fax will take about 10 seconds to 
handshake.
A typical non-V.34 -> V.34 fax will take about 12.5 seconds to 
handshake.

So there is some "lost" time (2.5 - 4.5 seconds per call), but the 
1200/2400 bps control channel rate will almost always recoup that in 
the initial NSF/CSI/DIS/TSI/DCS/CFR HDLC frame exchanges (and that's 
not even factoring the big savings due to not needing TCF or any of 
those obnoxious pauses that cause timing problems so frequently).  So 
the only lasting time loss due to handshaking is when the sender 
doesn't support V.34 and calls a V.34-supporting receiver.

> 2. V.8 fast handshaking  really is (theoretically at least)
> significantly faster. With a 9.6 Kbps or a V.17 modem, the handshaking
> is done at 300 bps. With V.8 (ie: when sender and receiver support
> V.34) the handshaking is done at a much faster rate of 1,200 bps. The
> result is that handshaking time is reduced from approximately 16
> seconds with 9.6 Kbps and V.17 to 7 seconds with V.34.

The "handshaking" to which you are referring (the fax protocol HDLC 
frame exchanges) is actually done with V.34, not V.8.  V.8 is only used 
to start the connection.  From the completion of the V.8 handshaking to 
the end of the fax session everything is done with V.34; the carrier is 
never changed.  But yes, the V.34 control rate does use 1200 or 2400 
bps (almost always 1200).

And if we're talking about how much time is saved with V.34-Fax during 
the non-image-data portions of the fax (the HDLC frame exchanges), then 
I think that a 9-second improvement is possible, although perhaps 
liberal.  On a one-block fax with no errors it will essentially save 
3-5 seconds in the HDLC frames exchanges alone, and then the omitted 
time required for TCF will be another 2-3 seconds.  So it compensates 
for the longer connect time and then some, but not 9-seconds worth.  My 
testing shows an overall improvement of 5 seconds on a one-block, 
one-page, error-free fax, not counting the time involved with the 
actual block image data, but including the connect time.  That is 
significant, but the really noticeable improvement is due to the image 
data transmission speeds when transmitting pages with large or multiple 
blocks of data.

Since connection rates will vary (but usually will be 21600 or 24000 
bps) the actual improvement due to a faster image data transmission 
speed also varies, but obviously faster is better - if the frames get 
received without error.

However, that's the big time-involving crutch: errors.  It's not always 
easy to say that, in the presense of errors, a fax would go faster with 
V.34 (requires ECM) than with V.17 and ECM (because we're dealing with 
a different carrier, different modulations), although that's generally 
going to be true.  Likewise, it's not always easy to say that, in the 
presense of errors, a fax would go slower with ECM than without ECM, 
but that's also generally going to be true.  It's therefore quite 
difficult to say whether a V.17 non-ECM fax will be faster or slower 
than a V.34 fax in the presense of errors.  After the limited amount of 
bulk testing I've yet been able to do on this, I'd have to say that in 
general a run of bulk faxes will go faster with V.34 support than 
without it - with one significant caveat: when V.34 cannot deliver the 
block of image data in four attempts V.34 cannot be enabled.

T.30 Annex F specifically prohibits the use of the CTC (continue to 
correct in ECM) in V.34-Fax sessions, and we cannot switch modulation 
protocols as we can do with non-V.34-Fax sessions.  Thus, if a block of 
image data cannot be delivered properly in four attempts with V.34 the 
sender can use EOR (end of retransmissions, causing data corruption) or 
DCN (disconnect, try again in another call).  HylaFAX wisely does the 
latter in Class 1.0 and V.34-Fax when dealing with MMR data (MH and MR 
usage in V.34-Fax will be uncommon, I think) because corruption in MMR 
image data translates into data loss.  I cannot say with any certainty 
what happens in Class 2/2.0/2.1 with such a situation.  I suspect that 
a manufacturer that is trying to limit the incidence of disconnections 
may actually do the former and hope that the receiver goes along with 
it - to the detriment of data integrity.

In the relatively small amount of bulk testing that I've yet done with 
Class 1.0 and V.34-Fax this concern is relevent for about 10% of the 
destinations that support V.34-Fax.  In those cases HylaFAX in Class 
1/1.0 will mark the destination as "hasV34Trouble" and will not use 
V.34 on subsequent attempts.  Without this feature we would repeatedly 
resend over and over until we happened to get the fax through, until 
the fax job failed completely, or (in the case of EOR use) the receiver 
would have to notify us that the entire image did not come through, and 
we'd need to manually resend and risk the same problem.

> 3. V.34 implements a "line probing" procedure that is much more
> efficient at retraining on noisy calls. Immediately following the
> handshake stage, a signal exchange allows the V.34 receiver to analyze
> the characteristics of the connection before beginning the data
> transmission stage, and choose several key session parameters. This
> isn't only performed on every new connection, but can occur at any
> time during the connection as part of the retraining process, which
> can be a huge win on multi-page faxes.

Well, this retraining can occur at nearly any time.  T.31 Appendix A 
Annex B states that it can be requested at any time but occurs only on 
the next transition from the primary to control channels (i.e., 
changing from image data to fax-protocol HDLC frames), so it may likely 
have to wait until after the next block is sent if it's done while 
using the control channel.

> Consider the following table of average fax transmission times. I
> think it's safe to assume the author used ECM throughout, and that the
> numbers are for relatively healthy line conditions (Source: Davidson
> Consulting, 2003):
>
>                 9.6 kBps 4-Page Fax   V.17 4-Page Fax    V.34 4-Page
> Fax
>                    (seconds)           (seconds)           (seconds)
>
> Handshake             16                   16                  7
> Page 1                18                   12                  5
> Retraining             6                    6                 0.25
> Page 2                27                   18                  7
> Retraining             6                    6                 0.25
> Page 3                27                   18                  7
> Retraining             6                    6                 0.25
> Page 4                54                   36                  14
> Retraining             6                    6                 0.25
> ==========================================================================
>
> Total                166                  124                  41

Well, I think that "handshake" here means something different than what 
I've used it as, and the authors clearly aren't including the V.8 
handshaking time into those V.34 figures while they did seem to include 
part of the connection establishment in the other figures.  
Furthermore, feel free to do the math yourself, but the authors here 
are using faster-than-33600 speeds for their V.34 page-data figures (18 
* 9600 / 5 = 34560, and that's the lowest speed they use).  V.34-Fax 
cannot go faster than 33600 bps (maybe they were counting 
synchonization bytes or something in the V.17/V.29 figures, I don't 
know), and you'll almost never see that speed in practice.  Average 
V.34-Fax connections are 21600 or 24000 bps.

Again, as I've said before, these figures are propaganda used by 
manufacturers to promote their product, but they are not reflective of 
reality.  V.34-Fax is faster, but not nearly as fast as these figures 
make it appear.  I've reworked the same figures here (just for V.17 
14400 bps and V.34 24000 bps):

Fax           V.17 14400 bps    V.34 24000 bps
              (seconds)           (seconds)
Handshake     20                  17
Page 1        12                  7.2
Retraining    3                   1.25
Page 2        18                  10.8
Retraining    3                   1.25
Page 3        18                  10.8
Retraining    3                   1.25
Page 4        36                  21.6
Retraining    3                   1.25
==========================================================================
Total         116                 72

So they skewed the V.17 14400 figures by 7% (up) and the V.34 figures 
by 43% (down).  And that's why I call it propaganda.

If you have a telco that does not bill in partial minutes, then both 
calls will be billed to the sender equally, and there will be no 
monetary savings here - the bigger advantage will be in having the 
opportunity of a modem being made available some 44 seconds sooner 
(important for those with limited modems and time but lots of faxes).

> Clearly V.34, with the quick handshake, faster data transfer and
> super-quick line-probe retrains is very relevant to multi-page faxing.

I think the relevancy depends upon the application.  If someone is 
dealing with only a handful of faxes daily then it probably won't be 
relevent.  If someone's fax lines are actively busy (i.e., there are 
fax lines in a hunt group), then it probably will be relevent.

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*