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] What is your percentage of hard failures
Lee,
Andrew Taylor wrote:
We have 18 modems here in the US handling about 4000 fax jobs a day
with a 35% average failure rate.
We also run HylaFAX in 12 overseas locations with single modem setups
and see from 30-50% failure rate.
Failure rates from 30 to 50% are catastrophic. But, since you're
including "busy", "no carrier", and "no answer" results in your "error
count" that's going to throw things off. Normally those kinds of
results should be discarded completely as there is no way to
categorically know if it was an error or if it wasn't. Run
'xferfaxstats' and divide the number of errors by the number of pages
transmitted. That should be your "error rate". That number should not
be anywhere near 30%. On the bulk of the systems that I administer this
value is much less than 1%.
I use errorstats.sh to produce a daily report, which is what I base my
failure rate on. We started using HylaFAX in March and early monitoring
of performance showed that a lot of failures were due to bad data from
the staff, not a problem with the package.
/u/sbin/xferfaxstats is run daily also. The most recent xferfaxstats
output shows:
Total 2688 44:11:20 1.0 677, so about 25%.
But lines like this indicate a probable user problem:
(**xag)281 4:27:28 1.1 151 14400 2-D MR = 54% failure
I know of 1 fax machine that will not work with our MultiTechs, a
Lexmark T520 printer/modem but I am sure there are others.
I'd love to take a look at this session log and perhaps send a test fax
or two to the destination. What kind of MultiTech modem are you using,
anyway?
I've sent you the error log for the Lexmark; I don't want to post it.
The most common problems are bad fax numbers or extremely busy numbers.
They're problems, yes, but they shouldn't be counted as errors against
HylaFAX performance.
Quite right; I know our users enter a lot of bad numbers; some are also
due to a problem in our applications, such as bad data in the fax field
of our customer records. All faxes are generated from our operational
software.
We don't know if we are getting better or worse performance with this
package against the previous one, but we can certainly troubleshoot it
much more. When users complain their faxes don't go through I can check
specifics and invariably find it was not a problem with HylaFAX.
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*
____________________ 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*