AW: AW: flexfax: Problems submitting very large Number of jobs sequentially

[Christoph Stotz <pif@logo.de>]

Hello!

The 50MB was "spinning" out of my mind. Only 1 Page/fax, about
45-60kb/fax.

The number of errors and the idle-Times of the modems is constant.

How do you changed the assignModem behaviour ? Any patch or code
snippit avaible ?

Thanks!

Christoph

-----Urspr�ngliche Nachricht-----
Von: Didier Gautheron [mailto:dgautheron@magic.fr]
Gesendet am: Montag, 27. Juli 1998 04:42
An: Christoph Stotz
Cc: flexfax@sgi.com
Betreff: Re: AW: flexfax: Problems submitting very large Number of jobs
sequen tial ly

Hi

Christoph Stotz wrote:
> The theory of too many files don�t seem to me to be the solution.
Yes but a 1500-5000 files in a directory is a problem on all OS. and
here you have 4 to 5 dirs :
info
sendq
doneq
docq

and the directory from where jobs are 'sendfaxed'.

I don't undertand yours numbers
- Where did you get the 50Mbytes number for faxq?
- Spool partition 5000 faxes --> 3.5 Giga? How many pages per fax?

> Is it possible to tell hylafax to call a batch-file if the number
> of jobs in queue is smaller than the number of free modemlines
> avaible ?
I don't think you could do this out of the box.
But you could use some trick on xferlog and or faxwatch to get a tick
each time a fax is sent.


- Do you have starvation: some modems are staying a little idle at the
end of a call with plenty of jobs waiting? 
- Do you have more errors than under light load? 
 
The text below is over simplified but I hope there's no big mistake.

The delay is coming from the faxq's scheduler : it's a multi threads prg
using fork and exec to achieve its goals.
The main thread (faxq) is waiting in a loop for events:
events are coming from:
fifo : 
- hfaxq submiting job
- faxgetty
- faxsend (not sendfax , faxsend is the prg which actually sends the
fax)
child's dead:
- mainly faxsend
timeout
- mainly from jobs waiting queue

Of course when faxq is not in its waiting loop it doesn't see other
events coming, they are waiting in system's buffers.

faxq is shooting itself in the foot and it's pushing your computer in
the red zone with big queue :
runScheduler in faxd/faxQueueApp.c++ is processing all the jobs in the
run gueue even if no modems are in READY state. So in your case the main
thread is reading 1500 and up files (jobs status file) for nothing - if
the main goal of hylafax is sending faxes, not trashing out of
delay,tries or whatever faxes, of course - And runSheduler is called
many times: each time you add a job, each time a job finished, and so
on.

It's easy to change this ie : change assignModem behavior so
runScheduler will return when there's no more modems available . I tried
and yes now with a 10000 run queue, sendfax takes the same time. 
But side effects are unknow, after all it's just faxq's main routines
:).


Didier.