You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The value we store in a count-min sketch is currently 128bit:
struct cm_value {
fpoint value;
__u64 ts;
};
I think we can compress this to 64 bits total: a __u32 for the estimated rate in pps and a __u32 for the timestamp. This means the timestamp would wrap every 4.2s but given our current WINDOW that isn't a problem. It just needs code to deal with it.
Doing this will halve the memory we need, plus on 64bit arches we can (probably) use a single load and store for struct cm_value which reduces the likelihood of observing a race condition.
The text was updated successfully, but these errors were encountered:
We don't really need 64 bit to represent a rate, 2^32 packets per
second should be enough for everyone. Once we manage to shrink the
timestamp to 32 bit we'll save a bunch of memory.
Updates #16
lmb
added a commit
that referenced
this issue
Feb 3, 2021
We don't really need 64 bit to represent a rate, 2^32 packets per
second should be enough for everyone. Once we manage to shrink the
timestamp to 32 bit we'll save a bunch of memory.
Updates #16
The value we store in a count-min sketch is currently 128bit:
I think we can compress this to 64 bits total: a
__u32
for the estimated rate in pps and a__u32
for the timestamp. This means the timestamp would wrap every 4.2s but given our currentWINDOW
that isn't a problem. It just needs code to deal with it.Doing this will halve the memory we need, plus on 64bit arches we can (probably) use a single load and store for
struct cm_value
which reduces the likelihood of observing a race condition.The text was updated successfully, but these errors were encountered: