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

["Darren Nickerson" <darren.nickerson@xxxxxxxx>]

Lee,

Thanks for the reply, and for the detailed analysis which, in broad strokes
at least, supports our assertion that V.34 can be useful in many instances.
I'm glad to see V.34 may have a place in your faxing, depending upon the
specific application of course ;-)

We recently engineered a "modest" 180-channel (6 x E1) broadcast facility
for one of our customers (apparently it cranked out nearly 250,000 pages
this weekend alone), and the customer has been kind enough to allow us to
gather statistics from this server in the coming months. It should prove to
be a useful source of real-world data for measuring things like V34
penetration, and the pros/cons of V.34 in various applications over a very
large amount of faxing.

We'll share what we learn, as we learn it!

-Darren

-- 
Darren Nickerson
Senior Sales & Support Engineer
iFAX Solutions, Inc. www.ifax.com
darren.nickerson@xxxxxxxx
+1.215.438.4638 ext 8106 office
+1.215.243.8335 fax


----- Original Message ----- 
From: "Lee Howard" <faxguy@xxxxxxxxxxxxxxxx>
To: "Darren Nickerson" <darren.nickerson@xxxxxxxx>
Cc: <hylafax-users@xxxxxxxxxxx>
Sent: Monday, March 29, 2004 6:19 PM
Subject: Re: V.34-Fax, was: [hylafax-users] 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*