Upload
mckile
View
35
Download
0
Embed Size (px)
DESCRIPTION
BRICK: A Novel Exact Active Statistics Counter Architecture. Author: Nan Hua , Bill Lin, Jun (Jim) Xu , Haiquan (Chuck) Zhao Publisher: ANCS’08 Presenter: Yun-Yan Chang Date:2011/02/23. Outline. Introduction Design of BRICK Basic idea Rank indexing Handling increment - PowerPoint PPT Presentation
Citation preview
1
BRICK: A Novel Exact Active Statistics Counter ArchitectureAuthor: Nan Hua, Bill Lin, Jun (Jim) Xu, Haiquan (Chuck) ZhaoPublisher: ANCS’08Presenter: Yun-Yan ChangDate:2011/02/23
2
Introduction Design of BRICK
◦ Basic idea◦ Rank indexing◦ Handling increment◦ Handling overflow
Performance evaluation Conclusion
Outline
3
Present a novel active statistics counter architecture called BRICK (Bucketized Bank Indexed Counter).
BRICK◦ Store variable width counters entirely in SRAM
while supporting fast access.◦ Exploit statistical multiplexing technique.
Group a fixed number of randomly selected counters into a bucket by an indexing scheme.
Introduction
4
◦ Figure 1 shows the effect of statistical multiplexing Each horizontal layer of bricks corresponds to a
bucket The length of bricks corresponds to the real counter
widths.
Introduction
Figure 1: BRICK wall (conceptual baseline scheme)
5
Randomly bundle N counters into h buckets, B1, B2, ..., Bh, where each bucket holds k counters and N = hk.
Basic idea
Figure2: (b) Bucket structure
6
When access the yth counter, apply the index y to permuted index i by a permutation function π : {1...N} →{1. . .N}.
The corresponding counter Ci can then be found in the lth bucket Bl , where l = .
Basic idea
Figure2:(a) index permutation
ki
7
Each bucket contains p sub-counter arrays A1, A2, ..., Ap to store the 1st, 2nd, ..., pth sub-counters.
◦ Assume the worst-case counter width is divided into p parts, which refer to as “sub-counters".
Basic idea
Figure 3: (a) Within a bucket, segmentation of variable-width counters into sub-counter arrays.
8
For each counter, use indexing scheme to identify locations of sub-counters across the different sub-counter arrays.
Rank indexing
Figure3: (b) Compact representation of variable-width counters.
9
Algorithm for get the value of ith counter.
Rank indexing
※ rank(Ij, a): return the number of 1 in bit-string Ij, count form Ij[1] to Ij[a].
10
Increment algorithm
Handle increment
※ varshift(s, j, c): bit-string s, start from jth bit, shift right c times.
11
Handle increment
32
※ varshift(s, j, c): bit-string s, start from jth bit, shift right c times.
12
Extend data structure with full-size buckets F1, F2, ... , FJ , each bucket Ft is organized as k full-size counters.
◦ When a bucket overflow occurs for some Bl , the next available full-size bucket Ft is allocated to store its k counters, where t is just +1 of the last allocated full-size bucket.
◦ Use a flag fl to set to indicate the overflowed buckets.
◦ The index of the full-size bucket Ft is stored in a field labeled t, which is associated with Bl .
Handle overflow
13
Memory costs and lower bounds
Sl :memory cost of each bucket S : total memory cost
◦ Lower bound of memory
Performance evaluation
NMlg (1) MCi
Ni 1 (2)
Ci: denote counter and counter valueM: sum of counter valuesN: number of counters
14
Numerical results with various configurations
The number of entries decreases exponentially as we go to the higher sub-counter arrays. (main compression)
Performance evaluation
15
Numerical results with various configurations
The amount of extra storage only decreases slightly with additional levels in the BRICK implementation.
Performance evaluation
16
Performance evaluation
17
Results for real Internet trace USC: around 18.9 million packets, 1.1 million flows. UNC: around 32.6 million packets, 1.24 million flows.
Performance evaluation
Worst-case counter width
Total storage requirementUSC UNC
Naïve 25 bits/counter 3.85 MB 4.40 MBBRICK 10 bits/counter 1.39 MB 1.63 MB
18
BRICK is SRAM-efficient yet allows for fast counter lookup and increment.
Index filed only requires small number of extra bits per bucket.
Conclusion