Thanks for the explanation. So I went back dig though mail list and come back with this relative topics: http://lists.policyd.org/pipermail/users/2009-October/002827.html http://lists.policyd.org/pipermail/users/2010-May/003033.html http://lists.policyd.org/pipermail/users/2010-January/002905.html
If the windows is dynamic, then I could send double the total of quota limit. Example: Period: 300s(5 minutes), quota limit 8(which means block at 10th recipients) Dec 13 13:26:15 mailman cbpolicyd[2234]: module=Quotas, mode=update, host=192.168.0238, helo=kkkkk, [email protected], [email protected]=quota_update, policy=10, quota=7, limit=8, track= Sender:[email protected] <sender%[email protected]>, counter=MessageCount, quota=*1/8* (12.5%) Dec 13 13:26:16 ... quota=2/8 (24.2%) Dec 13 13:26:17 ... quota=3/8 (35.2%) Dec 13 13:26:19 ... quota=4/8 (47.2%) Dec 13 13:26:20 ... quota=5/8 (59.4%) Dec 13 13:26:21 ... quota=6/8 (71.3%) Dec 13 13:26:22 ... quota=7/8 (86.6%) Dec 13 13:26:22 ... quota=8/8 (98.8%) Waited( look below at *formula 1)* Dec 13 13:29:57 ... quota=*3/8* (40.5%) Dec 13 13:30:32 ... quota=4/8 (48.3%) Dec 13 13:30:33 ... quota=5/8 (60.6%) Dec 13 13:30:34 ... quota=6/8 (72.9%) Dec 13 13:30:35 ... quota=7/8 (85.2%) Dec 13 13:30:36 ... quota=8/8 (97.4%) Dec 13 13:30:37 ... quota=9/8 (109.6%) waited Dec 13 13:31:10 .. quota=9/8 (110.0%) Dec 13 13:31:11 Dec 13 13:31:11 mailman cbpolicyd[12995]: module=Quotas, action=*reject* quota=*10/8* (122.1%) Dec 13 13:31:11 *formula 1:* http://lists.policyd.org/pipermail/users/2010-January/002905.html Delta = (1 - (Now - LastUpdate) / Period) * LastCount + 1 = (1-(13:29:57 - 13:26:22)/300) * 8 + 1 = 3.26 3.26 rounds down to 3 So, in total, I was able to send 16 messages(recipients). My intention is to limit a client to send 100 emails(recipients) a day. 2010/12/12 Stähelin, Simon (ID) <[email protected]> > > >Nigel Kukard wrote: > > > >> > Eg, suppose you set a rate of 10 messages per 60 seconds, and you > >>> sent 1 message every 6 seconds. After the first message, the counter > >>> will be 1, after another 6 seconds, the counter will be 1 - ( 1 * > >>> 6/60 ) + !, which is previous counter less 6/60ths of it's previous > >>> rate because we've gone 6s since the last message, plus 1 for the new > >>> message. So we now have 1.9, not 2. > >>> > >>> After the next message, the rate will be 1.9 - ( 1.9 * 6/60 ) +1, > >>> which is 2.71 and not 3. > >>> > >>> And so it goes on. > >>> > >>> In your case, you've sent those messages over a period of 3 1/2 > >>> minutes, so your counter has been reduced somewhat as a result. The > >>> x/y reported is obviously a rounding of the floating point value (as > >>> you can see where it doesn't change from 5/8 to 5/8 for the 5th and > >>> 6th messages. Then for the 7th message, there is a significant gap in > >>> time and so you can see the counter has reduced somewhat. > >>> > >>> > >>> Hope this helps. > >> > >>Awesome response Simon :) I'm thinking a little FAQ on the site may be > >>a good idea, or even adding the above to the quota docs page. > > > >Feel free to copy/adapt as you wish - I've added a bit more that you > >can use, or not, as you wish. > > > > > >Not having looked at the code, I assume the actual calculation is Cm > >= Cn * (1 - t/T), and add 1 if the message is passed. > >where: > >Cm=new value of counter > >Cn is previous value > >t is time since last message was passed > >T is time period specified for the quota. > >With the condition that if t>T then Cm=1 since you don't want the > >counter going negative and storing up credit. > > > >Or > >If t>T > > then Cm=0 > > else Cm = Cn * (1 - t/T) > >If Cm > Q > > then block message; Cn=Cm > > else pass message; Cn=Cm +1 > >where Q is the message count specified in the quota. > > > > > > > >Which sort of leads on to the question of what T should be - and not > >something I'd considered greatly before now. This may also be of use > >to people struggling to get their heads round what limits to set. > > > >If someone tries to send large volumes of messages continuously, then > >having a rate of (say) 60/minute would have the same effect as > >3600/hour in the long term. In the steady state, both would allow one > >message per second. > >One would settle at : > >60 * (1 - 1/60) +1 = 60 > >the other would settle at : > >3600 * (1 - 1/3600) +1 = 3600 > > > >The difference would be when the user wants to send a batch of > >messages out when they have not sent much (or any) for a while. In > >effect, T controls the burst capability. > > > >Lets say the client and server can process very large volumes indeed > >(so we can ignore limits imposed by the ability of the server to > >handle the messages etc), then with a value of 60 for T, messages > >would get blocked after sending 61 within a second and after that > >would be throttled to 1/second. Whilst with a value of 3600, the user > >could spit out 3601 in the first second before being throttled down > >to 1/second. > >Of course, they aren't likely to spit out that many in that short a > >time, but the principal holds - the larger the value of T for a given > >limit expressed in messages/second, the larger the number of messages > >that can be sent in a burst. > > > >For someone sending (say) 1800 messages, a limit of 60 per 60 seconds > >would throttle them down so the messages take nearly half an hour to > >send, while a rate of 3600 per 3600 seconds would allow them all to > >be sent as fast as the client and server can process them. > > > >-- > >Simon Hobson > > > >Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed > >author Gladys Hobson. Novels - poetry - short stories - ideal as > >Christmas stocking fillers. Some available as e-books. > >_______________________________________________ > >Users mailing list > >[email protected] > >http://lists.policyd.org/mailman/listinfo/users > > Hi Simon > > Thanks a lot, I finally understood how this works in detail. > > Cheers > Simon (as well) > -- > Universität Bern > Abt. Informatikdienste > Gruppe Netzwerk > > Simon Staehelin > Gesellschaftsstrasse 6 > CH-3012 Bern > Raum 106 > Tel. +41 (0)31 631 31 80 > Fax +41 (0)31 631 38 65 > > email: > [email protected] > [email protected] > [email protected] > > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.policyd.org/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users
