> I pushed this to master for now. I'll cherry-pick to 1.7 in a few days
> unless I hear of trouble reports. (I don't expect them but I'm on
> vacation so I won't have a chance to respond immediately if they
> happen.)
I can probably deal with any problems that happen due to this code.
Probably
On Wed, May 30, 2012 at 09:35:24PM -0700, Ethan Jackson wrote:
> > It's a pretty low value, but it's enough to allow us to estimate the top
> > sources of packets in any given channel, which is the goal.
>
> > 256 would make sense if we were goal were to log for later data-mining
> > type analysis
> It's a pretty low value, but it's enough to allow us to estimate the top
> sources of packets in any given channel, which is the goal.
> 256 would make sense if we were goal were to log for later data-mining
> type analysis. 8 seems more reasonable for the kind of "rule of thumb"
> manual analy
On Wed, May 30, 2012 at 07:28:49PM -0700, Ethan Jackson wrote:
> Looks good, only minor comments.
>
> > + * We use a variation on the "Space-Saving" algorithm in Metwally et al.,
> > + * "Efficient Computation of Frequent and Top-k Elements in Data Streams",
> > ACM
> > + * Transactions on Databa
Looks good, only minor comments.
> + * We use a variation on the "Space-Saving" algorithm in Metwally et al.,
> + * "Efficient Computation of Frequent and Top-k Elements in Data Streams",
> ACM
> + * Transactions on Database Systems 31:3 (2006). This algorithm yields
> + * perfectly accurate res
Until now, when a packet was dropped in the kernel-to-user buffers, we
logged the occurrence but nothing that would allow a person reading the
log after the fact to learn why it was dropped. This commit adds details
that identify the major sources of packets in the buffer, which should
help.
Sign
