Re: [PATCH] - FIX - UCP/EMI Throttling MT v4.0

I may be talking out of turn here but unless there has been sweeping changes to the way this patch operates, there should be minimal impact 
on incoming traffic.
I used this patch as a base for a similar patch to fix the same problem in the SMPP SMSC code. (and got burnt by the timestamp 
initialisation problem there also - I can provide an updated version of my patch if anyone would like to persue it further)

This attempts to work around the fact that it is a single thread that manages both incomming and outgoing traffic and forces the wait only 
if it is outgoing traffic.  Kannel will continue accept any message when it is received from the smsc as the throttling code is only applied 
when sending to the particular smsc.

Tust my two bits worth.

Stuart Beck


Vincent CHAVANIS wrote:
> 
> We want to limit outgoing throughput as many SMSC requires.
> But yes, if we apply this patch we will also limit the incoming 
> throughtput.
> I don't know to fix this because we are using only one sender thread
> Even if we checks UCP51 and apply a sleep,
> when the sender thread will be awakened (to nack a DLR or MO for example),
> then the MT will be send without respecting throughput.
> 
> Vincent.
> 
> ----- Original Message ----- From: "Alexander Malysh" <[email protected]>
> To: <[email protected]>
> Sent: Saturday, March 24, 2007 1:53 PM
> Subject: Re: [PATCH] - FIX - UCP/EMI Throttling MT v4.0
> 
> 
>> Hi,
>>
>> if I understand Vincent right, he will limit outgoing throughput. It's
>> indeed needed on many SMSC implementations. But we never want delay
>> incoming traffic. We limit it implicitly if our queue reach incoming 
>> limit.
>>
>> Andreas Fink wrote:
>>
>>> I think the question is do we want to limit the throughput on
>>> incoming or on outgoing?
>>>
>>> on incoming,we have to delay the ack / delay the processing of the
>>> next incoming message.
>>> on outcoming we would delay our own sending.
>>>
>>> Actually I dont see why we should delay at all as windowing will do
>>> the rest. But maybe some people have bogous implementations to
>>> connect to that it would be needed?
>>>
>>> On 24.03.2007, at 00:55, Alexander Malysh wrote:
>>>
>>>> Hi Vincent,
>>>>
>>>> IMO it's not good to delay acks. It would be better to just check
>>>> throughput
>>>> and not send message but only ack.
>>>>
>>>> Vincent CHAVANIS wrote:
>>>>
>>>>> Hi andreas,
>>>>>
>>>>> The main problem with EMI thread is that actually
>>>>> we have a sender thread awakened
>>>>> when we need to ack an incoming message.
>>>>> This patch fixes the sleeping process when it is awakened.
>>>>> While throughtput is not entirely done, it will sleep until
>>>>> (last_mt_microtime + throughput < now) It actually works with 2
>>>>> differents
>>>>> of our operators.
>>>>>
>>>>> Here is an example : (during this second we tried to send 1 msg
>>>>> and at the
>>>>> same time receiving 21 instructions to ACK)
>>>>>
>>>>> 2007-03-23 18:33:26.733 [31081] [46] DEBUG: EMI2[SMS_6]: QOS:
>>>>> last_mt_microtime:<1174671205.812181> now:<1174671206.733465>
>>>>> delay:<1.0
>>>>> 00000> 2007-03-23 18:33:26.733 [31081] [46] DEBUG: EMI2[SMS_6]: QOS:
>>>>> Traffic Policy exceeded, we need to sleep <0.078716>sec 2007-03-23
>>>>> 18:33:26.810 [31081] [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy
>>>>> exceeded, we need to sleep <0.001345>sec 2007-03-23 18:33:26.811
>>>>> [31081]
>>>>> [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>> <0.000349>sec 2007-03-23 18:33:26.811 [31081] [46] DEBUG: EMI2
>>>>> [SMS_6]:
>>>>> QOS: Traffic Policy exceeded, we need to sleep <0.000327>sec
>>>>> 2007-03-23
>>>>> 18:33:26.811 [31081] [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy
>>>>> exceeded, we need to sleep <0.000307>sec 2007-03-23 18:33:26.811
>>>>> [31081]
>>>>> [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>> <0.000288>sec 2007-03-23 18:33:26.811 [31081] [46] DEBUG: EMI2
>>>>> [SMS_6]:
>>>>> QOS: Traffic Policy exceeded, we need to sleep <0.000230>sec
>>>>> 2007-03-23
>>>>> 18:33:26.811 [31081] [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy
>>>>> exceeded, we need to sleep <0.000213>sec 2007-03-23 18:33:26.811
>>>>> [31081]
>>>>> [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>> <0.000197>sec 2007-03-23 18:33:26.812 [31081] [46] DEBUG: EMI2
>>>>> [SMS_6]:
>>>>> QOS: Traffic Policy exceeded, we need to sleep <0.000180>sec
>>>>> 2007-03-23
>>>>> 18:33:26.812 [31081] [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy
>>>>> exceeded, we need to sleep <0.000164>sec 2007-03-23 18:33:26.812
>>>>> [31081]
>>>>> [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>> <0.000148>sec 2007-03-23 18:33:26.812 [31081] [46] DEBUG: EMI2
>>>>> [SMS_6]:
>>>>> QOS: Traffic Policy exceeded, we need to sleep <0.000132>sec
>>>>> 2007-03-23
>>>>> 18:33:26.812 [31081] [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy
>>>>> exceeded, we need to sleep <0.000115>sec 2007-03-23 18:33:26.812
>>>>> [31081]
>>>>> [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>> <0.000099>sec 2007-03-23 18:33:26.812 [31081] [46] DEBUG: EMI2
>>>>> [SMS_6]:
>>>>> QOS: Traffic Policy exceeded, we need to sleep <0.000083>sec
>>>>> 2007-03-23
>>>>> 18:33:26.812 [31081] [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy
>>>>> exceeded, we need to sleep <0.000066>sec 2007-03-23 18:33:26.812
>>>>> [31081]
>>>>> [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>> <0.000050>sec 2007-03-23 18:33:26.812 [31081] [46] DEBUG: EMI2
>>>>> [SMS_6]:
>>>>> QOS: Traffic Policy exceeded, we need to sleep <0.000034>sec
>>>>> 2007-03-23
>>>>> 18:33:26.812 [31081] [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy
>>>>> exceeded, we need to sleep <0.000017>sec 2007-03-23 18:33:26.812
>>>>> [31081]
>>>>> [46] DEBUG: EMI2[SMS_6]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>> <0.000001>sec 2007-03-23 18:33:26.973 [31081] [46] DEBUG: EMI2
>>>>> [SMS_6]:
>>>>> QOS: Throughput detected, we need to sleep <1.000000>sec
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
>>>>> Service Technique/Reseau - NOC
>>>>> Developpement SMS/MMS/Kiosques
>>>>> http://www.telemaque.fr/
>>>>> [email protected]
>>>>>
>>>>>   ----- Original Message -----
>>>>>   From: Andreas Fink
>>>>>   To: Vincent CHAVANIS
>>>>>   Cc: [email protected]
>>>>>   Sent: Friday, March 23, 2007 8:24 PM
>>>>>   Subject: Re: [PATCH] - FIX - UCP/EMI Throttling MT v4.0
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   On 23.03.2007, at 17:37, Vincent CHAVANIS wrote:
>>>>>
>>>>>
>>>>>     Hi all
>>>>>
>>>>>
>>>>>     For those who are using my throttling EMI patch posted a few
>>>>> month ago
>>>>>     on this ML Here is an rare issue that can make the sending thread
>>>>>     waiting for lifetime.
>>>>>
>>>>>
>>>>>     The issue is reproductible when no MT is sent for a while so
>>>>>     'last_mt_microtime' is not initialized. We fix it at connect
>>>>> (UCP 60),
>>>>>     we will now initialize this variable to the current microtime.
>>>>>
>>>>>
>>>>>     2007-03-23 11:05:30.450 [12348] [53] DEBUG: EMI2[SMSC_8]: QOS:
>>>>>     Throughput detected, we need to sleep <1.000000>sec 2007-03-23
>>>>>     11:05:31.450 [12348] [53] DEBUG: EMI2[SMSC_8]: QOS: Sleeping
>>>>> Done.
>>>>>     2007-03-23 11:05:31.450 [12348] [53] DEBUG: EMI2[SMSC_8]: QOS:
>>>>>     last_mt_microtime:<3689911777816892928.000000>
>>>>> now:<1174644331.450592>
>>>>>     delay:<1.000000> 2007-03-23 11:05:31.450 [12348] [53] DEBUG:
>>>>>     EMI2[SMSC_8]: QOS: Traffic Policy exceeded, we need to sleep
>>>>>     <3689911776642248704.000000>sec 2007-03-23 12:30:41.659
>>>>> [12348] [53]
>>>>>     DEBUG: EMI2[SMSC_8]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>>     <3689911776642243584.000000>sec 2007-03-23 12:30:52.730
>>>>> [12348] [53]
>>>>>     DEBUG: EMI2[SMSC_8]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>>     <3689911776642243584.000000>sec 2007-03-23 12:30:55.739
>>>>> [12348] [53]
>>>>>     DEBUG: EMI2[SMSC_8]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>>     <3689911776642243584.000000>sec 2007-03-23 12:30:57.244
>>>>> [12348] [53]
>>>>>     DEBUG: EMI2[SMSC_8]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>>     <3689911776642243584.000000>sec 2007-03-23 12:30:59.261
>>>>> [12348] [53]
>>>>>     DEBUG: EMI2[SMSC_8]: QOS: Traffic Policy exceeded, we need to
>>>>> sleep
>>>>>     <3689911776642243584.000000>sec
>>>>>
>>>>>
>>>>>     Vincent.
>>>>>
>>>>>
>>>>>     --
>>>>>     Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
>>>>>     Service Technique/Reseau - NOC
>>>>>     Developpement SMS/MMS/Kiosques
>>>>>     http://www.telemaque.fr/
>>>>>     [email protected]
>>>>>     <emi_patch_ack_v4.txt>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   Does it actually work?
>>>>>   The reason why I ask this is because you simply sleep for a certain
>>>>>   delay when the throughput has been reached. the delay however
>>>>> might fall
>>>>>   short if someone wakes this thread in the meantime. I use that
>>>>> often in
>>>>>   my code to trigger another thread telling it that there is now
>>>>> something
>>>>>   to send. I'm not sure if EMI driver does that however.
>>>>>
>>>>>
>>>>>   The effect would be not sleeping that long which is probably just
>>>>>   increasing the throughput a bit.
>>>>>
>>>>>
>>>>>   Andreas Fink
>>>>>
>>>>>
>>>>>   Fink Consulting GmbH
>>>>>   Global Networks Schweiz AG
>>>>>   BebbiCell AG
>>>>>
>>>>>
>>>>>   ---------------------------------------------------------------
>>>>>   Tel: +41-61-6666330 Fax: +41-61-6666331  Mobile: +41-79-2457333
>>>>>   Address: Clarastrasse 3, 4058 Basel, Switzerland
>>>>>   E-Mail:  [email protected]
>>>>>   www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
>>>>>   ---------------------------------------------------------------
>>>>>   ICQ: 8239353 MSN: [email protected] AIM: smsrelay Skype: andreasfink
>>>>>   Yahoo: finkconsulting SMS: +41792457333
>>>>
>>>> -- 
>>>> Thanks,
>>>> Alex
>>>>
>>
>> -- 
>> Thanks,
>> Alex
>>
>>
>>
> 
> 
> 
>