Hal Murray <halmur...@sonic.net>: > That sounds like the right ballpark. Again, if I were working in this area I > would be writing hack code to generate numbers. It's got to have a buffer > for > each item waiting in the channel. Does it do an alloc/free on each item or > does it avoid that by saving the buffer and reusing it? We have 3 sizes of > packets: no-auth (48 bytes), shared-key (68), and NTS (232). Can we tell it > how much to copy or will it copy worst-case? > > Processing a packet takes a few uSec for no-auth and ~10 usec for NTS. A > single 250ns is not important relative to 10 usec but will be significant > relative to a few usec if you do it several times per packet.
Premature optimization. We should do *nothing* other than writing the simplest, most idiomatic code possible unless our *measurements* of GC latency spikes show that they're reaching an uncomfortable frequency. This measurement is pretty trivial to do. See https://golang.org/pkg/runtime/debug/#ReadGCStats > I still haven't seen how you plan to get the data from the client side to the > server side without a lock. See sample code above. > > The server side does: > loop: > recv_request > get_info > fill in reply > send_reply > > I suppose you could do it if channels have a peek option. That will take a > lot > more code. You will need a main channel and a sub-channel per thread and > another thread to copy over. And then you have to handle the case where a > server thread is idle so it's not checking its new-data channel... Ugh. Yeah, there's got to be a simpler way than that. But it's just borrowing trouble to try to specify the way this far in advance. The Phase 1 goal has to be a dumb, literal, unthreaded translation that comes as close as possible to just transcribing trhe existing C into Go and exhibits sane sync behavior. If we never get further than that it will still be a win because no more buffer-overrun exploits. But we will. Dunno about you, but I expect phase 2 (stupid Go to properly idiomatic Go with fully exploited concurrency) to be a helluva lot of fun. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
