Re: [go-nuts] Issues when using time.Ticker microsecond duration

[envee]

Uli, Robert, 
I finally settled on using the rate limiter package to achieve what I need. 
I have a machine with 40 vCPUs and when I use a rate limiter with a rate 
limit of 1000, I am able to generate HTTP requests at that rate. (There are 
other processes running on this RHEL 7 machine, but it is very lightly 
loaded).

When I increase the limit to anything higher than 3000 TPS (transactions 
per second), my program can only generate 1000 TPS less than that rate.
For example, if I need to send 4000 TPS, I can see (using some custom 
Prometheus metrics), that I am generating only 3000 TPS. Likewise, if I set 
the limit to 8000 TPS, I can see request rate of 7000 TPS. 
I can live with that for now. Because atleast I have a mechanism to control 
the rate and get close to what I need.

I will see if I can tune my program any further to get much closer to the 
desired rate.

Thank you all for your help.

On Thursday, 3 February 2022 at 19:05:02 UTC+11 Amnon wrote:

> > From the tests that I have performed, I can see that a Ticker pretty 
> accurately fires at every 1ms interval.
>
> It will depend on the load on your machine. As the load on the machine 
> increases, so with the jitter in the tick time.
>
> On Thu, Feb 3, 2022 at 1:19 AM Robert Engels  wrote:
>
>> I am unclear why you need to use an N of M. I would make sure the hardest 
>> case is handled and you can use a variety of techniques to partition the 
>> work. 
>>
>> On Feb 2, 2022, at 6:58 PM, envee  wrote:
>>
>> And I forgot to mention that approach I mentioned talks about waking up 
>> N goroutines at a time. The way I plan to do is to select a range of N 
>> goroutines from my list of goroutines and only allow those goroutines to 
>> send HTTP requests.
>> I could use this approach to select the N goroutines or even use a 
>> Semaphore. I presume using a Semaphore, will allow a good amount of random 
>> N goroutines out of M goroutines to execute.
>>
>> On Thursday, 3 February 2022 at 10:26:28 UTC+11 envee wrote:
>>
>>> Thanks Robert, Uli and Ian for your suggestions.
>>>
>>> I think what I will probably do is use a Ticker with a duration of 1ms. 
>>> At every 1ms, I will "wake-up" N number of goroutines to trigger HTTP 
>>> requests.
>>> That number N = (request rate per second / 1000)  = requests per ms.
>>> So, if I need to ensure a rate of 1 requests per second, I believe 
>>> it should be possible for the Ticker to return after every 1ms and then 
>>> fire about 10 requests at every such interval.
>>> From the tests that I have performed, I can see that a Ticker pretty 
>>> accurately fires at every 1ms interval.
>>> I think it's only when the Ticker duration falls below 1ms, that I see 
>>> issues.
>>>
>>> If my desired rate is less than 1000 per second, then I will create a 
>>> Ticker to return every 1000/request rate milliseconds, which will be a 
>>> number greater than 1ms. 
>>>
>>> This approach is closely based on Robert's suggestion about using a 
>>> higher duration for Ticker time and waking up a small subset of goroutines.
>>>
>>> I think it should be ok for a client to be accurate at the level of 
>>> granularity of 1ms.
>>>
>>>
>>> On Thursday, 3 February 2022 at 01:14:20 UTC+11 ren...@ix.netcom.com 
>>> wrote:
>>>
 Because 2 is a magnitude larger than 2000. 

 > On Feb 1, 2022, at 1:44 PM, Uli Kunitz  wrote: 
 > 

>>> -- 
>> 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/209b18aa-1317-4d72-80a1-222f10a26013n%40googlegroups.com
>>  
>> 
>> .
>>
>> -- 
>>
> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/3GUnjdoWjqU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/F912EE7E-4F80-4C16-ABC1-943572FD576C%40ix.netcom.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/a28d882f-df54-48e2-9cd7-5e1304216050n%40googlegroups.com.

Re: [go-nuts] Slices of pointers or not?

[Robert Engels]

I think the OPs question was specifically about the cost of returning from a 
function - it is the same. 

> On Feb 3, 2022, at 8:03 PM, Connor Kuehl  wrote:
> 
> On Thu, Feb 3, 2022 at 7:07 PM Paulo Júnior  wrote:
>> 
>> Hi all.
>> 
>> I hope you are well.
>> 
>> Is there a big difference, in terms of performance or functionality, between 
>> declaring []*Person or []Person as a return type of a function?
> 
> If you find yourself iterating over a group of structs like this a lot
> (especially if there's a lot of them to iterate over), you might want
> to consider measuring the performance differences between []*Person or
> []Person. With pointers, the actual structs might be far away from
> each other in memory, which may prevent you from taking full advantage
> of your processor's cache since it won't be able to benefit from the
> spatial locality that an array (or slice) offers.
> 
> Connor
> 
> -- 
> 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/CAC_QXZS-QEKTgvsK3TKk-yUyc1jP81HngHz6dcDV8bZwqLBT6Q%40mail.gmail.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/EF34CFE5-9A6A-4CF7-80C4-83F730518260%40ix.netcom.com.

Re: [go-nuts] Slices of pointers or not?

[Connor Kuehl]

On Thu, Feb 3, 2022 at 7:07 PM Paulo Júnior  wrote:
>
> Hi all.
>
> I hope you are well.
>
> Is there a big difference, in terms of performance or functionality, between 
> declaring []*Person or []Person as a return type of a function?

If you find yourself iterating over a group of structs like this a lot
(especially if there's a lot of them to iterate over), you might want
to consider measuring the performance differences between []*Person or
[]Person. With pointers, the actual structs might be far away from
each other in memory, which may prevent you from taking full advantage
of your processor's cache since it won't be able to benefit from the
spatial locality that an array (or slice) offers.

Connor

-- 
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/CAC_QXZS-QEKTgvsK3TKk-yUyc1jP81HngHz6dcDV8bZwqLBT6Q%40mail.gmail.com.

Re: [go-nuts] Register-based ABI benchmarks

[Robert Engels]

+1. Sometimes the compiler optimizations are even worse if they change the 
behavior the chip was typically expecting. 

> On Feb 3, 2022, at 2:23 PM, Ian Lance Taylor  wrote:
> 
> On Thu, Feb 3, 2022 at 7:21 AM Didier Spezia  wrote:
>> 
>> It seems Aarch64 benefits more from the register-based ABI than x86_64.
>> I don''t see really why. Does anyone have a clue?
> 
> My view is that the x86 architecture has fewer registers and has had a
> massive decades-long investment in performance, so stack operations
> are highly optimized in hardware, including things like forwarding
> values stored in the stack by the caller to the retrieval from the
> stack by the callee without waiting even for the memory cache.  The
> ARM architecture has more registers and has historically focused more
> on power savings than on raw performance, so it has less optimization
> on stack handling and benefits more from a smarter compiler.
> 
> In my experience testing compiler optimizations can be frustrating on
> x86 because the hardware is just so good.  Almost every other
> processor architecture shows bigger benefits from compiler
> optimizations.
> 
> Ian
> 
> -- 
> 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/CAOyqgcVBg%2BWkrT636M-VuBjnaSOjUiAd_Einso_%3DBWFWMKRttA%40mail.gmail.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/32CF3C8F-EE52-4A60-8EB0-53B8CB2E164D%40ix.netcom.com.

Re: [go-nuts] Slices of pointers or not?

[Robert Engels]

No. Because a slice is a slice. But there are several performance differences 
in the usage. 

> On Feb 3, 2022, at 7:09 PM, Paulo Júnior  wrote:
> 
> Hi all.
> 
> I hope you are well. 
> 
> Is there a big difference, in terms of performance or functionality, between 
> declaring []*Person or []Person as a return type of a function?
> 
> Code sample https://go.dev/play/p/tBAod1hZvYu
> 
> Thank you and best regards.
> Paulo.
> -- 
> 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/964eb09d-cd5f-4da1-b1ca-cac3e9b5bb69n%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/5C7F5D64-0B5D-41D6-9DFE-0A9CB6AC9A67%40ix.netcom.com.

Re: [go-nuts] Slices of pointers or not?

[Marcin Romaszewicz]

It depends on what you do with it, and how you use it.

[]*Person is a slice of pointers, they're small.
[]Person is a slice of structs, they're bigger than pointers.

The first requires a level of indirection to access, the second doesn't.
The first requires no copying of structs when you're iterating or resizing,
while the second requires copying entire structs.

So, either could be faster based on what you do with it.

On Thu, Feb 3, 2022 at 5:10 PM Paulo Júnior 
wrote:

> Hi all.
>
> I hope you are well.
>
> Is there a big difference, in terms of performance or functionality,
> between declaring *[]*Person* or *[]Person* as a return type of a
> function?
>
> Code sample https://go.dev/play/p/tBAod1hZvYu
>
> Thank you and best regards.
> Paulo.
>
> --
> 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/964eb09d-cd5f-4da1-b1ca-cac3e9b5bb69n%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/CA%2Bv29LtxpB6cdryT0sfh1AXmf1X%2BJS0di40y0%2BYpmxz94Z1CeQ%40mail.gmail.com.

Re: [go-nuts] Is Go good choice for porting graph based app?

['Dan Kortschak' via golang-nuts]

On Thu, 2022-02-03 at 14:26 -0800, Kamil Ziemian wrote:
> Hello,
>
> I was handed proof-of-concept app written in Python. It seems
> underdeveloped, buggy and running it first time is a pain, because of
> dependencies. Basically it need to read some graphs stored in JSON
> files and manipulated them accordingly and write them to JSON files
> again.
>
> It seems that porting it now to more suitable language is worth a
> gain at this stage and I wonder if Go is a good choice? I read and
> watch many Ian Lance Taylor presentations about generics, so I know
> that only that generic graph (tree) data structure is something that
> can be a pain,  but in this case it would be were small issue. It
> seems that we have only few data types to be stored in graph, mostly
> strings and ints.
>
> I'm not true gopher, so I don't know if Go is proper choice for this
> task. I don't believe that Python is any better, but maybe I should
> check another language.
>
> Also, if someone know better thing to sore graphs than JSON, I would
> appreciate it any suggestion.
>
> I don't write anymore about this app, since I don't know if company
> allows for it.
>


I have had success writing graph handling code in Go. The answer to
your question though lies in the details of what it is that you want to
do.


-- 
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/de7029aad39c310a4b74eab497fd6fd774a9731b.camel%40kortschak.io.

[go-nuts] Slices of pointers or not?

[Paulo Júnior]

Hi all.

I hope you are well. 

Is there a big difference, in terms of performance or functionality, 
between declaring *[]*Person* or *[]Person* as a return type of a function?

Code sample https://go.dev/play/p/tBAod1hZvYu

Thank you and best regards.
Paulo. 

-- 
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/964eb09d-cd5f-4da1-b1ca-cac3e9b5bb69n%40googlegroups.com.

[go-nuts] Web development with Go

[Paulo Júnior]

Hi all.

I hope you are well.

What are the main use cases for traditional web applications (I mean 
non-SPA) development with Go? In other words, in a world of Single Page 
Applications (SPA) and its frameworks (such as Angular, React, Vue, so on) 
where does Go have space?

Best regards.
Paulo.

-- 
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/2c2e9bd4-0c48-46d9-bd5c-a4ba74bb24c9n%40googlegroups.com.

[go-nuts] Is Go good choice for porting graph based app?

[Kamil Ziemian]

Hello,

I was handed proof-of-concept app written in Python. It seems 
underdeveloped, buggy and running it first time is a pain, because of 
dependencies. Basically it need to read some graphs stored in JSON files 
and manipulated them accordingly and write them to JSON files again.

It seems that porting it now to more suitable language is worth a gain at 
this stage and I wonder if Go is a good choice? I read and watch many Ian 
Lance Taylor presentations about generics, so I know that only that generic 
graph (tree) data structure is something that can be a pain,  but in this 
case it would be were small issue. It seems that we have only few data 
types to be stored in graph, mostly strings and ints.

I'm not true gopher, so I don't know if Go is proper choice for this task. 
I don't believe that Python is any better, but maybe I should check another 
language.

Also, if someone know better thing to sore graphs than JSON, I would 
appreciate it any suggestion.

I don't write anymore about this app, since I don't know if company allows 
for it.

Best regards,
Kamil

-- 
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/1a879e65-98c1-49be-bee9-c114f1d4ef1fn%40googlegroups.com.

[go-nuts] Re: Optimizing GoAWK with a bytecode compiler and virtual machine

[Kamil Ziemian]

I will try to follow development of GoAWK.

czwartek, 3 lutego 2022 o 22:38:46 UTC+1 ben...@gmail.com napisał(a):

> Recently I switched (so to speak) my GoAWK interpreter from using a 
> tree-walking interpreter to a bytecode compiler with a virtual machine, and 
> got a noticeable performance boost. Write-up here if you're interested: 
> https://benhoyt.com/writings/goawk-compiler-vm/
>
> TLDR: It's significantly more code, but also 10-20% faster. It'll get even 
> faster when Go implements "switch" using jump tables (looking forward to 
> https://go-review.googlesource.com/c/go/+/357330/).
>
> -Ben
>
>

-- 
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/0e22549d-7d48-487d-b1bf-e5d6b4c8d100n%40googlegroups.com.

[go-nuts] Optimizing GoAWK with a bytecode compiler and virtual machine

[ben...@gmail.com]

Recently I switched (so to speak) my GoAWK interpreter from using a 
tree-walking interpreter to a bytecode compiler with a virtual machine, and 
got a noticeable performance boost. Write-up here if you're interested: 
https://benhoyt.com/writings/goawk-compiler-vm/

TLDR: It's significantly more code, but also 10-20% faster. It'll get even 
faster when Go implements "switch" using jump tables (looking forward to 
https://go-review.googlesource.com/c/go/+/357330/).

-Ben

-- 
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/d010af1b-3d15-40a5-be37-bbb1b3603c82n%40googlegroups.com.

Re: [go-nuts] Register-based ABI benchmarks

[Ian Lance Taylor]

On Thu, Feb 3, 2022 at 7:21 AM Didier Spezia  wrote:
>
> It seems Aarch64 benefits more from the register-based ABI than x86_64.
> I don''t see really why. Does anyone have a clue?

My view is that the x86 architecture has fewer registers and has had a
massive decades-long investment in performance, so stack operations
are highly optimized in hardware, including things like forwarding
values stored in the stack by the caller to the retrieval from the
stack by the callee without waiting even for the memory cache.  The
ARM architecture has more registers and has historically focused more
on power savings than on raw performance, so it has less optimization
on stack handling and benefits more from a smarter compiler.

In my experience testing compiler optimizations can be frustrating on
x86 because the hardware is just so good.  Almost every other
processor architecture shows bigger benefits from compiler
optimizations.

Ian

-- 
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/CAOyqgcVBg%2BWkrT636M-VuBjnaSOjUiAd_Einso_%3DBWFWMKRttA%40mail.gmail.com.

Re: [go-nuts] Register-based ABI benchmarks

[Robert Engels]

Usually Arm cpus have a lot more registers to pass values in. 

> On Feb 3, 2022, at 9:21 AM, Didier Spezia  wrote:
> 
> We are using our own benchmark to evaluate the performance of different CPU 
> models of cloud providers.
> https://github.com/AmadeusITGroup/cpubench1A
> 
> One point we have realized is the results of such benchmark can be biased 
> depending on the version of the Go compiler. 
> 
> For instance, the register-based ABI has a measurable positive impact on 
> performance, but it does not come with the same version of Go depending on 
> the CPU architecture. When we run different versions of Go against the same 
> code base for recent Intel and ARM CPUs, we get: 
> https://github.com/AmadeusITGroup/cpubench1A/issues/8
> 
> It is about +10% throughput for x86_86 (from go 1.16.13 -> 1.17.6) and +17% 
> for Aarch64 (from go 1.17.6 -> 1.18beta1). Yay!
> 
> It seems Aarch64 benefits more from the register-based ABI than x86_64.
> I don''t see really why. Does anyone have a clue?
> Thanks.
> 
> Best regards,
> Didier.
> -- 
> 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/0dae635a-768a-4cf4-ae05-84e294ca8745n%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/FDD03561-166B-436B-9475-B0E653FA5F3C%40ix.netcom.com.

[go-nuts] Register-based ABI benchmarks

[Didier Spezia]

We are using our own benchmark to evaluate the performance of different CPU 
models of cloud providers.
https://github.com/AmadeusITGroup/cpubench1A

One point we have realized is the results of such benchmark can be biased 
depending on the version of the Go compiler. 

For instance, the register-based ABI has a measurable positive impact on 
performance, but it does not come with the same version of Go depending on 
the CPU architecture. When we run different versions of Go against the same 
code base for recent Intel and ARM CPUs, we get: 
https://github.com/AmadeusITGroup/cpubench1A/issues/8

It is about +10% throughput for x86_86 (from go 1.16.13 -> 1.17.6) and +17% 
for Aarch64 (from go 1.17.6 -> 1.18beta1). Yay!

It seems Aarch64 benefits more from the register-based ABI than x86_64.
I don''t see really why. Does anyone have a clue?
Thanks.

Best regards,
Didier.

-- 
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/0dae635a-768a-4cf4-ae05-84e294ca8745n%40googlegroups.com.

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[Amnon BC]

> From the tests that I have performed, I can see that a Ticker pretty
accurately fires at every 1ms interval.

It will depend on the load on your machine. As the load on the machine
increases, so with the jitter in the tick time.

On Thu, Feb 3, 2022 at 1:19 AM Robert Engels  wrote:

> I am unclear why you need to use an N of M. I would make sure the hardest
> case is handled and you can use a variety of techniques to partition the
> work.
>
> On Feb 2, 2022, at 6:58 PM, envee  wrote:
>
> And I forgot to mention that approach I mentioned talks about waking up N
> goroutines at a time. The way I plan to do is to select a range of N
> goroutines from my list of goroutines and only allow those goroutines to
> send HTTP requests.
> I could use this approach to select the N goroutines or even use a
> Semaphore. I presume using a Semaphore, will allow a good amount of random
> N goroutines out of M goroutines to execute.
>
> On Thursday, 3 February 2022 at 10:26:28 UTC+11 envee wrote:
>
>> Thanks Robert, Uli and Ian for your suggestions.
>>
>> I think what I will probably do is use a Ticker with a duration of 1ms.
>> At every 1ms, I will "wake-up" N number of goroutines to trigger HTTP
>> requests.
>> That number N = (request rate per second / 1000)  = requests per ms.
>> So, if I need to ensure a rate of 1 requests per second, I believe it
>> should be possible for the Ticker to return after every 1ms and then fire
>> about 10 requests at every such interval.
>> From the tests that I have performed, I can see that a Ticker pretty
>> accurately fires at every 1ms interval.
>> I think it's only when the Ticker duration falls below 1ms, that I see
>> issues.
>>
>> If my desired rate is less than 1000 per second, then I will create a
>> Ticker to return every 1000/request rate milliseconds, which will be a
>> number greater than 1ms.
>>
>> This approach is closely based on Robert's suggestion about using a
>> higher duration for Ticker time and waking up a small subset of goroutines.
>>
>> I think it should be ok for a client to be accurate at the level of
>> granularity of 1ms.
>>
>>
>> On Thursday, 3 February 2022 at 01:14:20 UTC+11 ren...@ix.netcom.com
>> wrote:
>>
>>> Because 2 is a magnitude larger than 2000.
>>>
>>> > On Feb 1, 2022, at 1:44 PM, Uli Kunitz  wrote:
>>> >
>>>
>> --
> 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/209b18aa-1317-4d72-80a1-222f10a26013n%40googlegroups.com
> 
> .
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/3GUnjdoWjqU/unsubscribe.
> To unsubscribe from this group and all its topics, 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/F912EE7E-4F80-4C16-ABC1-943572FD576C%40ix.netcom.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/CALg-z3VpSw1dJwbn4YDd98qJsfj_NtSDJUrsA3p2xk%2BzQMChuQ%40mail.gmail.com.