Please have a look at golang.org/x/time/rate
<https://pkg.go.dev/golang.org/x/time/rate>. This package should solve your
problem.
Here is an example with 10 events per second.
func main() {
log.SetFlags(log.Lmicroseconds)
l := rate.NewLimiter(10, 1)
ctx := context.Background()
for {
if err := l.Wait(ctx); err != nil {
log.Fatal(err)
}
log.Print("event!")
}
}
The package is intended to rate external events, but the simple loop above
works as well. You can generate/handle events also in parallel threads if
one CPU is not sufficient. Note that for high frequencies it doesn't ensure
that the time intervals are exact, but it ensures that the rate limit is
maintained.
On Monday, January 31, 2022 at 6:10:10 AM UTC+1 envee wrote:
> Thanks Kurtis and Robert.
>
> My use-case is for a telecommunications application (HTTP/2 client, 5G
> client to be precise) which needs to send 5G (HTTP/2) requests to a server
> at a configurable rate (TPS).
> While the telecom industry very commonly use the word TPS (Transactions
> Per Second), I would like to control the rate within the second i.e. if the
> TPS is to be 2000, then I would like to spread these 2000 transactions
> (HTTP/2 requests) over 1 second uniformly i.e. 1 request every 500
> mico-seconds which will then result in 2000 requests in that 1 second.
> I believed that by using a time.Ticker to fire every 500 micro-seconds, I
> would be able to achieve this outcome.
>
> Is there any other way you could suggest I do this using Go ?
>
> On Monday, 31 January 2022 at 15:17:23 UTC+11 ren...@ix.netcom.com wrote:
>
>> Pretty much what Kurtis said. Low interval timers usually require
>> specialized constructs if not a real time OS to efficiently (or even at
>> all).
>>
>> On Jan 30, 2022, at 9:16 PM, envee <neeraj....@gmail.com> wrote:
>>
>> Thanks, but I am not sure how that reference solves the issue ?
>>
>> Or are you suggesting that the only way is to use Cgo and invoke usleep
>> to get very close to the Ticker duration specified ?
>>
>> On Monday, 31 January 2022 at 11:25:58 UTC+11 ren...@ix.netcom.com wrote:
>>
>>> See https://github.com/golang/go/issues/27707
>>>
>>> On Jan 30, 2022, at 5:50 PM, envee <neeraj....@gmail.com> wrote:
>>>
>>> Hi All,
>>>
>>> I understand this issue has been discussed in the past, and I have seen
>>> a few comments from Ian and Russ Cox about this topic, but I could not
>>> arrive at a conclusion about how I can make the time.Ticker send me ticks
>>> at atleast close to the Ticker duration I specify. At the moment, I am
>>> seeing ticks being sent at way over the specified duration especially when
>>> I have sub-millisecond durations.
>>> With 1ms duration, the ticker seems to be quite close to the duration
>>> (maybe within +/-5%). I would be happier if it were within 1%, but I can
>>> handle that.
>>>
>>> With 1 micro-second duration, the ticker sends ticks nearly 4 times
>>> slower than expected.
>>>
>>> Here is my sample code
>>> "
>>> ti := time.NewTicker(1 * time.Millisecond)
>>> start := time.Now()
>>> for i := 0; i < 1000; i++ {
>>> <-ti.C
>>> }
>>> fmt.Printf("elapsed time = %v\n", time.Since(start))
>>> "
>>>
>>> The output is usually close to 1 second as expected (close to) when
>>> using 1ms duration.
>>> elapsed time = 1.000159338s
>>>
>>>
>>> My code for the microsecond test is :
>>> "
>>> ti := time.NewTicker(1 * time.Microsecond)
>>> start := time.Now()
>>> for i := 0; i < 1000000; i++ {
>>> <-ti.C
>>> }
>>> fmt.Printf("elapsed time = %v\n", time.Since(start))
>>> "
>>>
>>> With this, I get the following output which shows the elapsed time close
>>> to 4 seconds :
>>> elapsed time = 4.796662856s
>>>
>>> *Is there anyway, I can ensure ticks are sent at approximately within 5%
>>> of my specified duration ?*
>>>
>>> I understand from time.Ticker docs that ticks will be lost if the ticker
>>> handler cannot keep up with the ticker time.
>>>
>>> In the simple code above, I am literally doing very minimal work in each
>>> loop iteration and that is about checking the loop condition.
>>> So I am not sure why ticks are being lost ?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/5f55ccf9-1478-4490-a8f4-a35a5764721dn%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/golang-nuts/5f55ccf9-1478-4490-a8f4-a35a5764721dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/efa204c2-092f-46e1-abe4-8aa5c502d986n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/efa204c2-092f-46e1-abe4-8aa5c502d986n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/fc949d39-b91e-4805-b1c8-a98a283dc719n%40googlegroups.com.
