If you need a “guarantee” in these efforts it is much more complex. You must 
likely need a real-time OS and interrupt driven code. A general purpose 
language, os and hardware probably won’t cut it. 

This of it this way though, if you had 20 cpus to spread the work on, you only 
need to interrupt every 10 ms - far more achievable. As long as the work is 
independent. 

> On Jan 30, 2022, at 11:10 PM, envee <neeraj.vaidy...@gmail.com> 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.
>>> 
>>> -- 
>>> 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.
> 
> -- 
> 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/3f9d1c36-4820-4555-a5f3-9721e661530bn%40googlegroups.com.

-- 
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/304FB85C-CBF6-4E91-83E8-04FC4A7A239B%40ix.netcom.com.

Reply via email to