Re: bug in throughput?

A thousand apologies, my email client gets mad. So, one more time:

If we have one thread why not to use some time-expired flags?

Say, after sms was submitted, set "mute_submitting_till" to (now +
1.0/throughput), where now = current time in usec

Then if kannel wakes up, it do incoming data processing, and if it
wakes up before (mute_submitting_till < now) == true, he don't send
anything and do gwthread_sleep(now - mute_submitting_till)

Stas.

On 5/13/07, Vincent CHAVANIS <[email protected]> wrote:
> Yes this is true. We have an old issue here.
> We are trying to find a global solution for this but this is not so trivial.
> You can use/adapt a patch (for EMI/UCP Smsc) i posted few month ago to the
> ML
> If i remember well, Stuart Beck has already adapted it for SMPP.
> But we get a new issue after using this patch, the Throughput will be
> respected
> but you will limit the incoming stream because we have only one thread that
> do RX and TX
>
> Vincent
>
> ----- Original Message -----
> From: "Stanislaw Senotrusov" <[email protected]>
> To: <[email protected]>
> Sent: Sunday, May 13, 2007 10:52 AM
> Subject: bug in throughput?
>
>
> > Hello.
> >
> > My SMPP connection is configured with throughput = 1
> >
> > Looking at logs I see what kannel trying to do submit_sm more than 1 per
> > second.
> >
> > I have a 1 message per second limit, and carrier SMSC responds to my
> > high volume message flow with SMSC returned error code 0x00000008
> > (System Error) in response to submit_sm
> >
> > As I noticed, throughput handled through gwthread_sleep() function
> > which is unblocked on incoming data in socket.
> >
> > So, kannel do submit_sm, and then trying to sleeps for 1 second, but
> > that sleep is breaks by incoming data from SMSC.
> >
> > Am I right or I can't get something?
> >
> > --
> > Stanislaw Senotrusov
> >
> >
>
>
>


-- 
Stanislaw Senotrusov