HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] large multiport systems



On 2003.08.23 13:25 Darren Nickerson wrote:
> 
> > > You're not up to date on deployment statistics ... V.34 is much
> more
> > > common
> > > than that. It's estimated that about 60% of all laser fax machines
> and
> > > 25%
> > > of inkjet models sold today are V.34 enabled. By 2005, as much as
> 75%
> > > of all
> > > laser fax machines and 50% of all inkjet fax machines sold will be
> > > V.34
> > > enabled.
> >
> > In my experience V.8 handshaking (done with V.34 faxing) takes
> longer
> > than handshaking with non-V.34 faxing.  And therefore V.34 only
> proves
> > beneficial if there is enough data to send that the increased
> bitrate
> > will compensate for the V.8 handshaking lag.  Generally speaking a
> > one-page MMR-compressed page, such as this gentlemen is discussing,
> > will not contain enough data to make V.34 worthwhile.
> 
> Lee,
> 
> That has not been our experience, and it's a surprising observation
> since I
> think V.8's entire reason for existing is to make handshaking faster,
> not
> slower.

Ah.  I've miscommunicated.  I didn't mean to imply any conclusion on 
V.8 technology for a single call, but rather as a whole for single-page 
bulk faxing.  Allow me to restate...

In my experience the total time consumed with handshaking for a group 
of faxes to random, uncontrolled locations will take longer when using 
V.8 handshaking (done with V.34 faxing) than if handshaking with 
non-V.34 faxing were done.  And therefore V.34 only proves beneficial 
if there is enough total data to send among the group of faxes to 
V.34-capable destinations that the increased bitrate will compensate 
for the V.8 handshaking lag to non-V.34-capable destinations.  
Generally speaking a one-page MMR-compressed page (all V.34-capable 
receivers *should* support MMR due to the common ECM prerequisite 
hurdle), such as this gentlemen is discussing, will not contain enough 
data to make V.34 worthwhile.

So, I don't mean to make a statement regarding how long handshaking 
takes when a V.34-capable sender calls a V.34-capable receiver versus 
how long handshaking takes when a non-V.34-capable sender calls a 
non-V.34-capable receiver, but rather I mean to say that the total 
"wasted" time trying to perform V.8 handshaking when a V.34-capable 
sender calls non-V.34-capable receivers may not be less than the time 
savings for those instances when the receivers are V.34-capable.

When a V.34-capable sender calls it first tries to initiate V.8 
communication (required for all data communication speeds faster than 
14,400 bps).  If that fails then it falls back to V.21.  That fallback 
takes some time.  If the modem spends some seconds before falling back 
to V.21, then in order for V.34 use to be worthwhile it needs to more 
than "make up" those seconds with another call to a V.34 capable 
receiver.  Most V.34 connections aren't going to be at 33,600 bps, and 
will probably average at 28,800 bps.  So, more than 1800 bytes of data 
will need to be sent at V.34 for every second wasted in failed V.8 
connection attempts.

How long does a modem spend trying to do V.8?  I don't know.  Yes, it 
probably varies from implementation to implementation; however, my 
statement is to say that it takes *some* time.  I don't pretend to know 
the reason for V.8's entire existence.  What I do know is that in my 
experience there is more time consumed in attempting V.8 handshaking 
with all destinations than is generally saved by V.34 data speeds to 
those that do support it.  Now, if the amount of data or the percentage 
of V.34-capable receivers out there goes up, then the chances of V.34 
proving beneficial are increased.  This should be true for *any* 
implementation.

V.34 communication should only be attempted with any single destination 
if it is known to support it or if the amount of image data to send is 
sufficient to make it worthwhile.  Currently HylaFAX cannot make this 
determination, unfortunately.

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@hylafax.org < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@hylafax.org.*




Project hosted by iFAX Solutions