|
Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] V.34-Fax, was: large multiport systems
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*
