> I don't know all those numbers yet. But: given that NTPsec only currently > has 2 threads and our allocations are typically occuring one second apart or > less per upstream or downstream, I can't even plausibly *imagine* a Raft > implementation having lower memory churn than we do.
That doesn't make sense. Where does your "one second apart" come from? Why is "currently has 2 threads" interesting? If I was interested in this area, I would be writing some hacks to measure things. One area to keep in mind is the MRU list. On a busy server, you might want a big one. I'm using 1/2 GB on my cloud servers. You might want a lot more on busy servers. Memory is ballpark of 20 GB/sec, or 50 ms/GB. I think that sets a minimum time for the scan phase. The current code is a hash table to find the slot and a doubly linked list sorted by time used. Slots are looked up by the hash table, removed from the list, then appended to the end. There may be some trick to tell the GC that it doesn't have to scan that area of memory. There may some features of Go that would make things cleaner if you did use GC. Or you could just say "Don't do that." If you have multiple server threads you may want a separate list per server. But don't forget that ntpq needs to scan the list. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
