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

[Uwe Dippel <udippel@xxxxxxxxx>]

Lee Howard wrote:
> Uwe Dippel wrote:
> > Oct 08 14:18:42.76: [14774]: RECV received frame number 74
> > Oct 08 14:18:42.77: [14774]: RECV received frame number 75
> > Oct 08 14:18:42.77: [14774]: RECV assumed RCP frame with block end
> > Oct 08 14:18:42.77: [14774]: --> [2:OK]
> > Oct 08 14:18:44.77: [14774]: MODEM <Timeout>
> > Oct 08 14:18:46.78: [14774]: MODEM <Empty line>
> > Oct 08 14:18:48.79: [14774]: MODEM <Empty line>
> > Oct 08 14:18:48.79: [14774]: <-- [9:AT+FRH=3\r]
> > Oct 08 14:18:49.18: [14774]: --> [7:CONNECT]
> > Oct 08 14:18:59.18: [14774]: <-- data [1]
> > Oct 08 14:18:59.19: [14774]: --> [2:]
> > Oct 08 14:18:59.19: [14774]: --> [2:OK]
>
> I do not at all mean to dispute your findings with regards to hard 
> disk versus flash drive being the primary reason for the failures, 
> however, let me point out what I see in the above session log 
> snippit... the portion which includes the HylaFAX misbehavior and 
> modem misbehavior which ultimately caused failure for recovery.
>
> I cannot know for sure why the high-speed data carrier dropped 
> prematurely after frame 75.  This is the root problem.  There was a 
> disturbance in the audio or the call was actually disconnected for the 
> modem /dev/ttyU0 (what kind of modem is that?).
>
> The correct recovery procedure in this case would be for HylaFAX to 
> immediately tell the modem to listen for V.21 signaling (AT+FRH=3) and 
> to very patiently await the modem's CONNECT response.  However, from 
> this portion of the log snippit you can see that six full seconds are 
> wasted as HylaFAX (4.4.3) trips over itself in what amounts to a bug.  
> Consequently, when it does get around to telling the modem to listen 
> for V.21 HDLC it almost immediately gets a CONNECT response, but no 
> data after ten seconds.  And that tells me that either the CONNECT 
> response was in error (i.e. a modem bug) or the sender is 
> malfunctioning or that the audio is again corrupted.  I'm going to 
> guess that the modem is giving a CONNECT response on the high-speed 
> data audio (when it shouldn't).
>
> So it looks to me like there are two potential problems here 1) 
> HylaFAX bug, and 2) modem bug.  I don't see from your log any reason 
> to blame the filesystem.
>
> I'd be interested to see failure case session logs when using HylaFAX+ 
> 5.2.7.  I can't say that it would resolve the issue, but it will allow 
> me to provide you a patch to at least address any HylaFAX bugs that 
> may surface there.

Thanks, Lee! I was surprised myself, to find the bad behaviour depending 
very much on the storage. This is why we ran days full of sessions, off 
CF and hard disk. I couldn't believe my eyes. Immediately after posting, 
I got off-list mail confirming the behaviour; where it was pointed out 
to me that only Transcend x266 would be reasonably reliable, and usually 
USB-flash better than CF. I got no permission, though, to copy the 
content of that message to the list.
And, to be very clear, I don't exempt the cheapo modem (Agere) from 
being the original culprit, eventually. But, and this is a but, I still 
take it that there is a buggy behaviour in hylafax, when storage speed 
has a most significant influence of the number of those errors. After 
posting my original message, we have been trying for days, one day off 
CF, one day off hard disk. I did another 'dd' for an identical system. 
The CF days spill over with those errors, and finally, finally, we also 
had the same error when ruuning off hard disk. But only one single 
error, in thousands of pages.
I had an exchange with a quality manufacturer of modems earlier, but 
finally they withdrew, since they don't support OpenBSD; and this is the 
platform we're running on. They argued we should use Debian, but that's 
no choice as of now for us. I will try HylaFAX+ 5.2.7; hoping to get it 
compiled on OpenBSD. If anyone has a compiled version, I can install it 
easily. Otherwise I will try nevertheless to compile it myself. It might 
take some time, since our installs are very minimal, catering as fax 
servers only.
Again, I don't blame Hylafax for the underlying problem. We still fail 
to get a better quality modem supported by OpenBSD. But that's not my 
point for mailing in. In my opinion, hylafax ought to be robust enough 
to not expose any behaviour depending on storage speed. It ought to be 
oblivious of the storage medium, especially when the effective data rate 
stands at 14.4 k as in our case.

By the way, now we are running the hard disk as USB, and the CF also on 
the same USB port, alternately. So the problem is not with USB, only 
with the medium used. Which seems to look like we need to - at least 
partially - blame the underlying file system at compounding the problem 
of a weak modem.

I'll keep you updated on my compilation successes of HylaFAX+ 5.2.7.

Thanks again,

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*