>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
