I think there is still a known issue with the SMPP throttling implementation in Kannel - it's the same issue as was reported forthe EMI implementation (I think) a while back - in both cases, some hacky patches have been submitted to resolve them. Check the Kannel *dev* mailing list for an SMPP throttling patch submitted by Stuart Beck last year, and see if that helps you!
Cheers, Giulio Harding ----- Original Message ----- From: "Dave Clarke" <[EMAIL PROTECTED]> To: "Alejandro Guerrieri" <[EMAIL PROTECTED]> Cc: [email protected] Sent: 22 March 2008 01:02:50 o'clock (GMT+1000) Auto-Detected Subject: Re: Understanding Throttling Thanks Alejandro I see what you're saying, but my issue is that this throttling is allegedly not coming from the carrier I'm connected to, but from an operator further downstream. My carrier says I am allowed throughput of 50/sec. Even when I set my end at 30/sec I still get these throttling problems. I'm confused. Can you clarify the effect that max-pending-submits has on the throughput? Say I have 2000 to send, I fire off 50. Now I have 50 pending submits. When I get a submit_sm_resp, I have 49 pending submits. Is this correct? Dave On Fri, Mar 21, 2008 at 1:31 PM, Alejandro Guerrieri < [EMAIL PROTECTED] > wrote: Dave, Throttling error is usually fixed by playing with "throughput" and "max-pending-submits" parameters. Try lowering the output a little, if you get throttled it's obvious that the operator has not set the throughput as high as he's claiming. Throttling causes performance penalties (messages gets requeued and retried, thus reducing the overall throughput) so maybe a little lower throughput will get you higher performance. Hope it helps, Alejandro On Fri, Mar 21, 2008 at 10:13 AM, Dave Clarke < [EMAIL PROTECTED] > wrote: Hi As my mission to push up throughput continues, and I follow the moving goalposts around the field, I am at the point where I have tweaked my OS, application and DB to cater for higher volumes, have patched my code to sort out DLR sequencing issues (thanks Ben) and have pushed my throughput setting to 50 messages per second through the carrier. My current issue is that I am being throttled by the carrier, but not in the way that I expected. They have me set to 50 messages per second, and I am presenting to them on dual binds, set at throughput of 25 each. Sounds ok. When I go to send say 2000 messages, I can parse my access.log, and I'll see some sends where I'm hitting 45+ messages Sent. But more often, I am seeing 0, or 1, or 2 being sent. When I look at the individual bind log, I'll see, 2008-03-21 12:53:57 [32228] [13] ERROR: SMPP[smppA]: SMSC returned error code 0x00000058 (Throttling error) in response to submit_sm. When I talk to the carrier, they say that this throttling is being passed back, not by them, but by the individual operator. Problem is, kannel will then back off for X seconds, so even though it has 2000 messages to send to multiple networks, it can't send any, as it regards the bind as throttled. Can anyone outline for me just how throttling operates. I see from the source that it appears to back off for 15 seconds, before re-commencing. Would it be a mistake for me to reduce this 15 to 2 or 3 seconds. Has anyone seen before where an aggregator will pass back a throttling error from an individual operator, thus gagging kannel completely? Thanks for your thoughts, Dave
