Re: [hylafax-users] Timeouts depending on disk drive!

["Uwe Dippel" <udippel@xxxxxxxxx>]

On Fri, Oct 17, 2008 at 1:44 PM,  <udippel@xxxxxxxxx> wrote:
> Yes, I did notice that the copying of files is slow, at least opening
> and closing. But, incidentally running on OpenBSD 4.2, dd results in >
> 5MB/sec here.
> (In any case, even with 400kb/sec, I cannot fathom that it should time out.)
>
> Now I tried to uninstall ('make uninstall') 5.2.7, and reinstall 4.4.3
> from packages, but the uninstall of 5.2.7 had not removed dialtest and
> typetest; for whatever reasons. That's on another page, though.
>
> Now I get 'sendmail: unknown option -- u' respectively '-- d'; no clue
> where this comes from. It doesn't show on the installs on which I have
> not removed the 4.4.3-package and installed 5.2.7. I'll try to find
> out where it comes from ...
>
> Next, I moved /tmp/ to RAM disk, but it seems to be unused.
>
> In my subsequent experiment, I will move the spool directory of
> hylafax (var/spool/hylafax for me) to a RAM drive. The RAM drive has a
> 'dd'-speed of >75MB/sec, so opening and writing of files should be
> almost instantaneously. If I still get the Timeouts, it must be some
> condition unrelated with r/w in the spooler directory.
>
> I'll keep you updated ... .

As promised, we have done a huge number of experiments with always the
same hardware (especially the same modem), with a number of operating
systems and CFs.

It remains conclusive that the Timeouts have not much to make with the
modem, contrary to what has been stated. I am still using the cheap
MODEM AGERE OCM V.92 VER2.7A (JUN 14 2004).
My test situation (the one that broke repeatedly) was a fax of > 20
pages, hyperfine. By now my experience stretches across several dozens
of such transmissions, usually lasting in the range of 1 hour each.
OpenBSD 4.2 running from hard disk would experience those timeouts
rarely (maybe 1 in 100 pages, if at all). The same version, simply
'dd'-ed to a CF, would have a large number of errors; in the range of
1 per 12 pages. Setting the CF to 'softupdates' would improve the
situation, without being optimal.

Against our earlier decision, I removed the CF from the embedded
system, plugged in another one (not a faster one, rather a slower
one), with Debian Testing installed, and not much else. Since then,
despite of  > 5 hours of sending hundreds of pages in hyperfine, we
did not experience a single "T.30 T2 timeout".
Please, no flames, I prefer OpenBSD to Debian any day; and I don't
want to imply that either is better or worse. However, our extensive
tests show 2 results:

1. T.30 T2 timeouts - at least in our case - cannot be attributed to
the cheap modem nor noisy lines (all is done directly from a
commercial PABX)

2. T.30 T2 timeouts depend on the operating systems as well as storage.

My personal conclusion would still be, that Hylafax - as well as it
has been written and works - still could be more robust or oblivious
to the underlying operating system, and the signals (interrupts?) that
it receives from there. Comparing the loads, OpenBSD in general needs
many more resources on (the same embedded) system than Debian. It is
my wild guess that this shows the sensitivity of the application. On
the other hand, OpenBSD uses less RAM; and does all the subsequent
image processing (Tiff, p*m) much faster, at least twice as fast.
For us, this is the end of what we can do, we can't follow the details
of signal handling. With a 'sigh', we need to convert everything that
we have devised to Debian, since it seems to guarantee an error-free
communication with the modem.

Again, no flames at all intended. This is only meant for those users,
who suffer from the dreaded timeouts; for their perusal at trying to
improve the situation.

YMMV,

Uwe


____________________ 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*