|
Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] batching almost there
On Jul 29, 2005, at 12:24 AM, Lee Howard wrote:
offman@xxxxxxxxxxxxxxxx wrote:
On Jul 27, 2005, at 10:33 PM, Lee Howard wrote:
Please double-check this by looking at the files in /var/spool/
hylafax/sendq and checking that the "tts" entry is exactly the
same for all of them.
hmm seems not
fax1 tts:1122538209
fax2 tts:1122538324
fax3 tts:1122538324
that would account for it, page 1 takes a little bit longer to
process.
It would seem, then, that the time-to-send is not being set
independently, but rather is being set with a relative value again.
that is now fixed, the programmer nested the call.
Also, one thing that I should make you aware of before you
encounter this on your own and we have another issue over this
matter... HylaFAX doesn't currently maintain batches. So just
because it's batched on the first call, if it is retried (i.e. the
first call results in a busy signal), HylaFAX does not attempt to
keep the jobs in the same order or even at the same rescheduled
time-to-send ("jitter" is added to the time-to-send on
reschedules). So if a batch does not make it through on the first
attempt then it will be highly unlikely [with the way that the code
currently is] that on the second attempt those jobs will be batched
again.
( I had a semi fix for it, in java)
but i'm npt worried about that ,I can see that from the hylafax
code, and I understand the construction of the system enough to see
potential issues.
I used to code embedded systems in C++ & assembly professionally
for over 15 years. I would love to work on Hylafax but i just don't
have the time.
I still feel like your usage of batching is a bit misappropriated.
You seem to be counting on the server-side batching mechanism to
collate your pages, and that's not really what the mechanism was
designed for. As I see it, this collation should really be
happening on the client-side, before the job is submitted to the
server for transmission.
Not exactly counting on it. I'm not expecting the pages to be
collated it's not a printer, that would be nieve, it's more a
document pack
(total maybe 10-50 pages, but it might be 3pages +2pages +4pages
+1page (as separate jobs), but tied together with a ref number), they
are for different people/departments , in the same business relating
to the same supply job.
, it CAN be split up, but it's better if it goes in 1 call. it's more
like buying a 4litre bottle of coke, instead of 8 tins, and i'm not
asking for the jobs needing/must be all together, and in the exact
order.
to clarify exactly what is needed:
Is a way to try to reduce IDD calls, nothing more. as you know It
is not cheap ESP. with redial.
Unfortunatly faxes cannot be batched as you suggest because they may
come from a number of different users,we would have to have some sort
of daemon to grab them server side , bump them into 1 job & pass to
hylafax, very messy , tried it , and it does not interface well, esp.
with hylafax clients
the way it is done currently , stands a risk of 1 Idd call for each
fax, I'm not worried about re-dials now & again, but more about 1 Idd
call for each fax, that can really mess up my budgeting.
The other question is about redials, if we submit 4 faxes to the
same destination & the same TTS , and if the first one hits a busy
signal, do the other 3 also try to call the busy number , or is the
software smarter than that, and puts them all for a re-try?
In the case of FaxSTF, I did read the documentation on this product
and it appears to me that the collation (the so-called "batching")
is being done manually by the administrator/user. So it looks to
me like you submit a few faxes to that product and then you
manually tell FaxSTF to collate them into one call before those are
transmitted. In HylaFAX terms, then, this is all being done on the
client-side... even on FaxSTF. To give you a HylaFAX version of
the same procedure, it would be like submitting all of the jobs and
then later, before the jobs are sent, for you to use something like
faxalter to give them all a common time-to-send.
That's not exactly correct., you can do it "manually" but ,batching
is performed by the faxsoftware,( we've been using it for over 8
years and it does batch, maybe not 100% reliably but close enough,
but the support for different fax machines is poor)
It seems to batch just before the current job is going,it scans the
queue for matching numbers. ( not really suitable for hylafax)
, it does not use timers to trigger jobs to pass into the send queue
( it seems to loop around the send queue looking at the time to send,
sub-optimal, and not scaleable), but appears to sort internally via
fax number, or perhaps , it has a quick look above & below the
current job for other numbers that are the same.
like i said it's not 100% accurate , but it is close enough.
I had one of the programmers write a java daemon( unfortunatly thats
50mb with the jvm), that sits on the faxserver, it takes a look at
the hylafax job queues & if the numbers are the same, alters the TTS,
so that they are all the same for the same numbers. it's a hack , but
it seems fairly effective, as long as the jobs are submitted with a
delay.( this also could fix the redial issue) , that daemon went into
service last night , and it does look good.
lee, I'm not looking for something that is 100%, just budget
reduction, and I'm not happy with what happened at the start of this
thread.
and just for the record, I am down 1 staff member as of last monday.
Thanks,
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*
