All,
I was performing some checks on smpp throttling and found the same
behaviour as vincent found below but this time in smsc_smpp.c.
Specific behaviour I found was that I could dump a load of messages into
the queue and while there was no further activity the queue would drain
at the required throttling rate, however the moment extra activity
started, e.g receiving more messages, the throttling behaviour went out
the window and messages started draining at a much faster rate due to
the gwthread_sleep poll function exiting short of the required timeout.
I made a similar change to the code which appears to now provide correct
throttling behaviour.
Just wondering if there is a better place to put this as I suspect the
gwthread_sleep problem will be seen in all smsc adapters.
I've attached a patch for the code change.
The code base is the CVS code set from July 27.
Stuart.
Vincent CHAVANIS wrote:
Dear all,
I want to point out for a second time the throttling issue on EMI/UCP SMSC
Actually, "gwthread_sleep(X) is used expecting the thread to sleep X seconds. This
is not true however when the thread is being awakened by another thread, for example to
inform him that new data has arrived. Here it might happen because the other directional
thread has just sent something back in the other direction and we need to send an ACK for
that one." (afink)
We've made different tests that prove that scenario.
Here is a (v2) patch that can fixe this issue.
It does just store the time in millisec (struct timeval) when a mt is sent
over the smsc and check if throughput is well done.
If not, it just sleep again until (mt_microtime + delay > microtime) is true.
http://bugs.kannel.org/file_download.php?f_id=0000113&f_type=bug
Vincent.
--
Stuart Beck
Systems Administrator
m.Net Corporation
Level 13, 99 Gawler Place
Adelaide SA 5000, Australia
Tel: +61 8 8210 2029
Fax: +61 8 8211 9620
Mobile: 0433 422 400
--- gateway/gw/smsc/smsc_smpp.c-badthrottle 2006-08-01 15:08:07.000000000
+0930
+++ gateway/gw/smsc/smsc_smpp.c 2006-08-01 16:38:03.786945051 +0930
@@ -165,6 +165,7 @@
long wait_ack;
int wait_ack_action;
SMSCConn *conn;
+ struct timeval last_mt_microtime; /* the last microtime a MT was sent
over the SMSC */
} SMPP;
@@ -986,6 +987,9 @@
SMPP_PDU *pdu;
Octstr *os;
double delay = 0;
+ struct timeval tv;
+ double mt_microtime = 0;
+ double microtime = 0;
if (*pending_submits == -1)
return;
@@ -1017,8 +1021,33 @@
/*
* obey throughput speed limit, if any.
*/
+ mt_microtime = (double) smpp->last_mt_microtime.tv_sec + (double)
smpp->last_mt_microtime.tv_usec / 1000000;
+
+ debug("bb.sms.smpp", 0, "SMPP[%s]: QOS: last_mt_microtime:<%f>
now:<%f>",
+ octstr_get_cstr(smpp->conn->id), mt_microtime, microtime);
+
if (smpp->conn->throughput > 0)
- gwthread_sleep(delay);
+ {
+ debug("bb.sms.smpp", 0, "SMPP[%s]: QOS: Sleeping <%f>sec",
octstr_get_cstr(smpp->conn->id), delay);
+ gwthread_sleep(delay);
+
+ gettimeofday(&tv, 0);
+ microtime = (double) tv.tv_sec + (double) tv.tv_usec / 1000000;
+
+ debug("bb.sms.smpp", 0, "SMPP[%s]: QOS: Sleeping Done.",
octstr_get_cstr(smpp->conn->id));
+ while (mt_microtime + delay > microtime)
+ {
+ debug("bb.sms.smpp", 0, "SMPP[%s]: QOS: Traffic Policy
exceeded, we need to sleep <%f>sec",
+ octstr_get_cstr(smpp->conn->id), (mt_microtime + delay)
- microtime);
+ /* Sleeping rest of time */
+ gwthread_sleep((mt_microtime + delay) - microtime);
+
+ /* Refreshing time */
+ gettimeofday(&tv, 0);
+ microtime = (double) tv.tv_sec + (double) tv.tv_usec /
1000000;
+ }
+ gettimeofday(&smpp->last_mt_microtime, 0);
+ }
}
else { /* write error occurs */
smpp_pdu_destroy(pdu);
