The traffic on the pool took a big jump recently. There were a couple of comments on the pool list, but nothing past "lots of traffic".
Understanding what's going on is the top of my list. A couple of interesting counters were lost in the recent (month or 2 ago) work on the packet processing. I think the mru list doesn't count mode 6 packets. Fixing that is probably important in being able to monitor DDoS activity or probes. How much of the old structure of ntpq did you preserve? Can you say anything about how the python version of ntpq works that isn't obvious from looking at the code? I'm looking for the big picture? The stuff that's obvious after you know it but hard to put together if you don't know what you are looking for because it is spread over many screens. How does the MRU stuff work? I think I saw some debugging printout indicating that it got back a clump of packets for each request. If it misses one, will it use the data up to the gap? Is there any documentation on the packet format? I saw some ".." in an ASCII packet dump. That was a CR/LF in the hex part. It looked like each slot was multiple lines. What marks the end of a slot and/or start of a new one? How does the retransmission logic work? I want to add a bunch of counters. Where should they go? What should I have asked? ----------- I got this from an old ntpq looking at a busy server. Ctrl-C will stop MRU retrieval and display partial results. 116 (0 updates) Giving up after 8 restarts from the beginning. With high-traffic NTP servers, this can occur if the MRU list is limited to less than about 16 seconds' of entries. See the 'mru' ntp.conf directive to adjust. I think that's trying to tell me that things are getting updated faster than they are getting retrieved. What will your new code do in that case? -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
