It is probably not the data in the cache - it is the code - whether yours or the kernel.
Did you try “hot threading” with polling in the C code? Did you see the same results? Typically a context switch on modern linux is 6 usecs - so I am doubting that is the source of your latency. > On Jul 29, 2022, at 8:11 PM, TH <tinsk...@gmail.com> wrote: > > In case of cache miss, I assume there's no way to tell CPU to keep the data > in the cache? The structs related to processing is all below cache line size. > (the test code is very crude one, not really much processing done) > > On the dedicated thread polling sockets... could I move away net and use > syscall & poll to implement low latency? But then again I'm seeing this > similar behaviour on my C code too. > > Thanks > > On Saturday, 30 July 2022 at 03:16:09 UTC+3 ren...@ix.netcom.com wrote: > Since the net IO is abstracted away from you, the answer is ’not usually’. > > The usual solution is dedicated threads that constantly poll the sockets, or > hardware support + real-time threads, etc. > > BUT, typically this is not what you are experiencing. More likely, the cpu > cache gets cold - so the operations can take 10x longer - especially on a > multi-use/user system - so it is actually your processing code that is taking > longer. > > You can probably use ‘perf’ on the process to monitor the cache misses. > > >> On Jul 29, 2022, at 7:08 PM, TH <tins...@gmail.com >> <applewebdata://93712E8B-CD6E-4DA8-9104-487850E34871>> wrote: >> > >> Hey, >> >> Bit confused on how stdlib net is implemented, but I'm noticing round trip >> >150µs latencies on idle connections (loopback). Round trip latency will >> drop to <20µs if sent packets constantly. >> >> I assume that this latency is caused by kernel / syscall wakeup to indicate >> that new data has arrived. Are there any methods to minimize this wakeup >> latency? >> >> Thanks >> >> > >> -- >> 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 >> <applewebdata://93712E8B-CD6E-4DA8-9104-487850E34871>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/87deab65-b441-42ce-b51b-663651ecfccbn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/87deab65-b441-42ce-b51b-663651ecfccbn%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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/a6d4d1ed-d1e9-4a60-a346-83b5eadd2d68n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/a6d4d1ed-d1e9-4a60-a346-83b5eadd2d68n%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/2FF7CBE0-9242-40A4-A815-A5FD96B12982%40ix.netcom.com.
