![]() |
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.*