'Lab.work'에 해당되는 글 40건

[Gems] Torus Topology

Lab.work 2010. 7. 4. 20:41
GEMS wiki says that PT_TO_PT and FILE_SPECIFIED topologies are recommended for CMP protocols.
Its probably fine for a rough model of a single CMP.  The auto-generated
TORUS_2D network will not create a hierarchy (for a Multiple-CMP) and will
not do anything special for the directory/memory controllers.

'Lab.work' 카테고리의 다른 글

Meeting 12월 29일  (0) 2009.12.29
11월 11일 Meeting  (0) 2009.11.11
Weekly Report (11/9)  (0) 2009.11.10
11월 4일 Meeting  (0) 2009.11.04
Weekly Report  (0) 2009.11.04
블로그 이미지

민둥

,

Meeting 12월 29일

Lab.work 2009. 12. 29. 15:42
Implementation

1) nINTER, nLOCAL 대신 Round-Robin으로 선택하게 하고
Rx, Ry의 같은 방향으로 가는 port에 대해서만 prioritized arbitration구현

2) Pipeline stage
모두다 no VA stage
Baseline router: I, SA, ST, LT
Turning packet: SA/STx/INT, STy/LT
X->X: SA/STx/LT (1 cycle)
Y->Y: SA/STy/LT (1 cycle)

3) Network-only simulator
ex)  a uniform random traffic

Evaluation

1)  n value를 6개 사용한것과 4개 사용한것 비교

2) Count number: How many times is nX > n_max used

3) CPI & Average network latency

4) Baseline router의 Input Buffer: 2, 4로 실험

5) Network-only simulator에서 
for the network-only, you dont' need VCs.. so 16x1 should be sufficient.


Pipeline (I/VA/SA/ST/LT 원래 그대로 실험)

@ BASELINE
/home/berebere/gems2/simics
buf가 2, 4일때 -> baseline_buf_4, baseline_buf_2

@ 4개 n value, Prioritized arbitration
/home/berebere/gems/simics
buf=2, inter_buf=4, n_max=4 일때 -> low_cost_max4

@ 6개 n value, Prioritized arbitration
/home/berebere/gems3/simics
buf=2, inter_buf=4, n_max=4 일때 -> low_cost_6n_max4

nX > n_max used 개수 비교
CPI, Average network latency 비교.

Flexible Pipeline

@ Baseline router: I, SA, ST, LT (flexible pipeline, 4 cycle)
/home/berebere/gems4/simics
buf가 2, 4일때 -> baseline_buf_4, baseline_buf_2
buf가 2이고 5stage (VA 포함) 일때 -> baseline_buf_2_5stage

Single Cycle Router

@ Baseline router
pipeline: I/VA, SA, ST, LT (4 cycle)
/home/berebere/gems5/simics
buf가 2, 4일때 -> baseline_buf_4, baseline_buf_2

@ 4개 n value, Prioritized arbitration
Turning packet: SA/STx/INT, STy/LT
X->X or Y->Y : SA/(STx or STy)/LT (1 cycle) 

Network only Simulator

@ Fixed-pipeline
Uniform Random traffic, 0.1~1.0까지 실험
buffer size = 16

@ Flexible-pipeline
Uniform Random traffic, 0.1~1.0까지 실험
buffer size = 16, pipeline_stage = 5

0.1   /home/berebere/gems_net_only/simics
0.2   /home/berebere/gems_net_only2/simics
0.3   /home/berebere/gems_net_only3/simics
0.4   /home/berebere/gems_net_only4/simics
0.5   /home/berebere/gems_net_only5/simics
0.6   /home/berebere/gems_net_only6/simics
0.7   /home/berebere/gems_net_only7/simics
0.8   /home/berebere/gems_net_only8/simics
0.9   /home/berebere/gems_net_only9/simics

'Lab.work' 카테고리의 다른 글

[Gems] Torus Topology  (0) 2010.07.04
11월 11일 Meeting  (0) 2009.11.11
Weekly Report (11/9)  (0) 2009.11.10
11월 4일 Meeting  (0) 2009.11.04
Weekly Report  (0) 2009.11.04
블로그 이미지

민둥

,

11월 11일 Meeting

Lab.work 2009. 11. 11. 21:22
다음주 월요일(11월 16일) 까지 해야할일!

@ Phoenix

1) Ideal(p2p)과 mesh에 대해서 src + dest traffic을 뽑아서 비교!
2) 많이 사용되는 node는 왜 많이 사용 되는 거지? 이유알아보기

@ CS710 ICN

1) 발표 준비
"Low-Cost Router Microarchitecture ", John Kim, to appear in MICRO 2009, New York, NY December 2009 

2) 논문의 내용을 Garnet을 사용하여서 재구현 하기 ★★★★★

@ Booksim

1) 3000 cycle 이후에 simulation 정지하도록 구현.
거기 까지의 패킷으로만 결과를 출력하기

'Lab.work' 카테고리의 다른 글

[Gems] Torus Topology  (0) 2010.07.04
Meeting 12월 29일  (0) 2009.12.29
Weekly Report (11/9)  (0) 2009.11.10
11월 4일 Meeting  (0) 2009.11.04
Weekly Report  (0) 2009.11.04
블로그 이미지

민둥

,

Weekly Report (11/9)

Lab.work 2009. 11. 10. 12:07
@ Phoenix

1) Ideal vs. Mesh
 
The CPI gap between ideal and mesh is not so big.
I’m afraid even if we optimize mapreduce on the mesh network, 
It may not represent much to the performance.

2) miss rate of each phase
 
I used 64K 4way L1 cache and 1M 4way L2 cache(shared) for each node.
Garnet does not show the actual miss hit/rate, so we should compare the misses per 1000 inst.

3) injection rate of each node with time.
The result files are attached.
[msg.png] represents the injection rate of coherence messages to the processing time.
[data.png] represents the injection rate of coherence data.

We can see the diagonal lines as expected,
But, at the same time, some nodes are heavily used than other.

@ Booksim

1) injection voq
There was a little problem at the last result.
I fixed the program and the new result is attached.
[3000cycle.xlsx]

Voq is 3~4 times better than no-voq when the injection rate is very high.

2) test on 64 nodes
I also tested 8x8 mesh, 64 ring, and 4ary 3 fly.
For fly topology, voq is 8~9 times better than no-voq.
for mesh and torus, the simulation cannot be done to the high injection rate,
we cannot see the difference between voq and no-voq.

3) A New Scalable and Cost-Effective Congestion Management Strategy for Lossless Multistage Interconnection Networks  (HPCA 05)
Now I am trying to re-implement the system in the paper.

Thanks.
minjeong

'Lab.work' 카테고리의 다른 글

Meeting 12월 29일  (0) 2009.12.29
11월 11일 Meeting  (0) 2009.11.11
11월 4일 Meeting  (0) 2009.11.04
Weekly Report  (0) 2009.11.04
10월 28일 Meeting  (0) 2009.10.28
블로그 이미지

민둥

,

11월 4일 Meeting

Lab.work 2009. 11. 4. 19:12
다음주 월요일까지 할일 List

@ Phoenix

1) 일단 Ideal과 Mesh의 performance 차이가 얼마나 나는지 알아보기.
즉, Network bottleneck이 얼마나 있는지 알아보기

2) 각 phase에서의 miss rate알아보기

3) 각 Node별, Message와 Data traffic이 시간에 따라 어떻게 변하는지 10,000 cycle 단위로 plot

@ Booksim

0) injection voq 구현 ㅠㅠ

1) A New Scalable and Cost-Effective Congestion Management Strategy for Lossless Multistage Interconnection Networks  (HPCA 05)
논문을 재구현 할수 있는가?

2) 64 node에서 test 
test1: 8x8 mesh, 64 ring, 4ary 3 fly (buf=16)

3) hotspot이 다른 node에 있을때는 얼마나 다를까?
16 node에서 5번 node에 hotspot일때는 0번 노드에 hotspot이 있을때 보다 congestion이 더 많음!

@ Other

1) 논문 읽기!
Achieving Predictable Performance Through Better Memory Controller Placement in Many-Core CMPs (ISCA 09)
2) Garnet 코드 완벽 공부!ㅠㅠ
GARNET: A Detailed On-Chip Network Model inside a Full-System Simulator

다음주 화요일 sigMP 전까지

@ 논문 읽기

1) Design and Evaluation of Hierarchical On-Chip Network Topologies for next generation CMPs (HPCA 2009)

How different is the topology from a CMESH topology?
How is the "global bus" different from a concentration implementation?
hybrid: concentration degree=8, wide bus 사용. router의 개수는 node의 개수 + 추가적인 hardware 필요
cmesh: concentration degree=4, router를 sharing 한다. router의 개수는 nodes/4 + cmesh에 맞는 router 사용.
그래서 각각의 delay가 다를 수 있다는거? locally 연결된 node간의 latency도 다르다.

Why is something like "XShare" needed? (i.e. what created the need for something like XShare?) When does FBFLY topology make sense?
channel slicing과 비슷한 개념으로 생각된다.
하나의 channel을 여러개가 공유하게 되므로 하나가 다 잡아먹고 있는것을 방지하기 위해서 사용하는 것인듯 하다.

What is the impact of "locality" on NoC performance?
What would be a worst-case traffic pattern for the proposed topology in this work?
local traffic은 거의 없이 global traffic이 많은 경우 (with high injection rate)

other issues
실제 application에서는 local traffic이 얼마나 생기는지 궁금.
cmesh와 비교할려면 8-degree cmesh와 비교해야 하는게 아닌가?

2) Express virtual channel Flow Control (ISCA 2007)

What is an "ideal" on-chip network latency?
network contention 없이 router hop count + channel latency만 고려한 latency.

Compared to a conventional 2D mesh network, what makes EVC more complex?
Do you think it is a good idea to implement flow control such as EVC to improve performance, or it is better to change to a different topology?
EVCs를 사용할 경우 router가 복잡해지고, static EVCs를 사용한다면 topology와 차이가 없고, 오히려 topology 형태가 더 좋은 performance를 낼 수 있다고 생각된다. dynamic EVCs를 사용하면 static의 문제점은 해결할 수 있을것으로 보이나, traffic에 따라 매우 다른 결과를 보일 것으로 판단된다.

Most NoC evaluation use "even number" network - for example, 16, 64 nodes, etc..  Why do you think the authors use a 7x7 network in their evaluation?
EVC network를 대칭으로 만들기 위해서 odd number를 사용.

What would be a worst-case traffic pattern using static EVCs?
What is the advantage/disadvantage of using dynamic EVCs?
neighbor node간의 traffic이 많은 경우에는 EVCs를 사용하는것이 conventional mesh 보다 더 안좋을 수 있음.

other issues
위에서 언급한 것처럼, 비슷한 topology 형태를 적용했을때 performance는 어떻게 될지 궁금.
torus topology가 아니기 때문에 양 끝의 node들을 bypass할수는 없다. 
node 수가 많아지게 되면, 즉 하나의 bypass channel 사이에 여러개의 node가 들어가게 되면 starvation문제가 더 심각해 질것으로 예상된다. 

'Lab.work' 카테고리의 다른 글

11월 11일 Meeting  (0) 2009.11.11
Weekly Report (11/9)  (0) 2009.11.10
Weekly Report  (0) 2009.11.04
10월 28일 Meeting  (0) 2009.10.28
Weekly Report (10/27)  (0) 2009.10.28
블로그 이미지

민둥

,

Weekly Report

Lab.work 2009. 11. 4. 19:05
@ phoenix

Network traffic patterns that I showed you last week are wrong, because my code had the garnet error.
I ran it again, and the number of message is much more than before, but the pattern is still similar.

I am also counting the packets every 1,000,000 cycle to get the average injection rate each cycle.
It may take 2 or more day to finish.

@ Booksim

I implemented the injection queue using voq.
And tested using bufsize=16 and # of vcs=16, packets were counted only between 3000~6000 cycle.
The packets are randomly selected from the injection queue, if the queue is not empty.
The result file is attached.

'Lab.work' 카테고리의 다른 글

Weekly Report (11/9)  (0) 2009.11.10
11월 4일 Meeting  (0) 2009.11.04
10월 28일 Meeting  (0) 2009.10.28
Weekly Report (10/27)  (0) 2009.10.28
Booksim VOQ 문제 해결  (0) 2009.10.27
블로그 이미지

민둥

,

10월 28일 Meeting

Lab.work 2009. 10. 28. 20:19
@ Phoenix

L2 cache size, Memory size
Data는 Memory에 어떤식으로 분배되어 있는지
그리고 Ruby에서 뽑을 수 있는 일반적인 stat들도 같이..

전체 message / cycle => average injection rate를
각 cycle마다 어떻게 변하는지 그래프를 그려보기

@ Booksim

infinite buf를 사용하는것은 문제가 있으므로
injection queue를 voq로 구현하면 문제가 해결!
구현해봅세봅세~~~

@ ICN Project

mesh에서 특정 request에 대한 delay를 0으로 주면 그 성능이 어떻게 되는가..
queuing delay를 0으로 바꿨는데 ideal보다 더 좋은 결과를 얻었음-_- 뭐지-_-

'Lab.work' 카테고리의 다른 글

11월 4일 Meeting  (0) 2009.11.04
Weekly Report  (0) 2009.11.04
Weekly Report (10/27)  (0) 2009.10.28
Booksim VOQ 문제 해결  (0) 2009.10.27
Booksim Accepted Throughput  (0) 2009.10.21
블로그 이미지

민둥

,

Weekly Report (10/27)

Lab.work 2009. 10. 28. 18:30
@ phoenix

Last Thursday, I made the phoenix presentation and we discussed about that.

And I printed out the network traffic of phoenix (wordcount) on 16 CMP mesh topology using garnet network.
In the attached graph (network_traffic.pdf), the horizontal axis represents the source nodes and the vertical axis represents the destinations. 
the result is the amount of traffic from beginning to end of the program, and it does not show specific pattern.

I think I should use magic breaks and find the traffic patterns of map/reduce/merge phase.

@ Booksim

As I mentioned earlier, voq result finally gets better as we expected.

I only counted the accepted packets between 3000 and 6000 cycle. and then, calculated the throughput. (warm-up takes 3000 cycles)
I also used the infinite buffer (1,000,000,000 buffer).
because if the buffer size is small, the first packet in the injection queue will be blocked and voq cannot process other packets.

(3000cycle_infinite_buf.xlsx)
I tested more using UR traffic and UR+50%hotspot traffic,
If more portion of packet goes to the hotspot node, voq performs much better than novoq, of course.
But when I use UR traffic without hotspot, voq is not always better.

Thanks.
minjeong

'Lab.work' 카테고리의 다른 글

Weekly Report  (0) 2009.11.04
10월 28일 Meeting  (0) 2009.10.28
Booksim VOQ 문제 해결  (0) 2009.10.27
Booksim Accepted Throughput  (0) 2009.10.21
Weekly Report (10/20)  (0) 2009.10.21
블로그 이미지

민둥

,

Booksim VOQ 문제 해결

Lab.work 2009. 10. 27. 00:16
Voq result finally gets better as we expected. 

I only counted the accepted packets between 3000 and 6000 cycle. 
 And then, calculated the throughput. (warm-up takes 3000 cycles) 

I also used the infinite buffer (1,000,000,000 buffer). 
because if the buffer size is small, 
the first packet in the injection queue will be blocked and voq cannot process other packets.

결국 제한된 cycle에서의 accepted packet,
무한 사이즈의 buffer를 사용했을때, 우리가 원하는 결과를 뽑아낼 수 있었음.

'Lab.work' 카테고리의 다른 글

10월 28일 Meeting  (0) 2009.10.28
Weekly Report (10/27)  (0) 2009.10.28
Booksim Accepted Throughput  (0) 2009.10.21
Weekly Report (10/20)  (0) 2009.10.21
Weekly Report (10/12)  (0) 2009.10.12
블로그 이미지

민둥

,

Booksim Accepted Throughput

Lab.work 2009. 10. 21. 17:34
[실험 설정]

Topology: 4x4 mesh, 16 ring, 16 fly
Traffic: Uniform Random, Uniform Random + 25% hotspot to dest 0
Packet size: 1 flit, 4 flit packet

[Average Throughput]

Throughput = # of packets / cycle
대부분의 topology에 대해서 average throughput은 Voq < No-Voq. Why?
packet size=1일때는 그래도 결과가 비슷한데, size=4일경우에는 No-VOQ가 좋음.

전체 # of packets은 Voq가 많은데, cycle도 Voq가 많음.
cycle 수는 max # of packets에 좌우되는가?
Voq와 No-Voq에서의 data 분포를 알아볼 필요가 있음.

[Packet Distribution to VCs]
injection rate이 커질때 max-min이나 stdev가 Voq > No-Voq
cycle은 max값에 의해 결정된다.

injection rate이 클때
MAXvoq - MINvoq > MAXnovoq - MINnovoq
STDEVvoq > STDEVnovoq

단, fly topology에 대해서는 그 차이가 매우 작은편이고 
그 이유에 대해서는 하나의 router가 각각 4개의 src/dest만 공유.
따라서 각 router별로 16개의 vc가 아닌 4개의 vc로 하면
결과가 많이 좋아질것으로 추측됨쓰!!!

4개의 vc를 사용하면 vc=16을 사용한 Voq보다 결과가 좋아지긴 하지만
No-Voq 보다 좋아지지는 않음.
vc의 개수가 줄어들면 최대값과 최소값의 차이, 즉 stdev가 줄어들고 따라서 성능이 좋아지는것으로 보임

[Injection rate과 Average Throughput의 관계]

신기한 점은 Injection rate가 작을때는 Voq결과가 No-Voq보다 좋은데
특정 시점을 기점으로 No-Voq 결과가 Voq보다 더 좋아진다.
이 시점 p를 지나면 Average Latency가 증가하면서 infinity로 가고, 
따라서 p 바로 다음이 Throughput이 되는것을 알수있음.
이 p 시간까지는 cycle도 거의 비슷한데, 이는 Voq와 No-Voq의 packet distribution에 별 차이가 없다는것을 의미.
p 시점을 지나면 Voq의 cycle이 엄청나게 늘어나면서 throughput이 안좋아지는데
이것은 packet들의 stdev가 커져서 그런거임...

여기서 논의할점:
p 시점이 지나서도 Voq가 굳이 더 좋은 결과를 내야할 필요가 있는가?
일단은 최대 thoughput까지 Voq가 결과가 좋으면 당연히 좋지만, 그럴만한 의미가 있는가가 중요.
그렇다면 어떻게 해야 좋아질까? 를 고민해야함..

그리고 Voq에서 packet 분포를 균일하게 할 방법이 있는가?
그렇게 되면 전반적인 Voq의 성능이 많이 향상될것으로 보임!

Idea: 
Voq를 그대로 사용하되, 하나의 vc에 packet이 일정양을 넘으면 다른 vc를 선택적으로 사용할 수 있게하면 어떨까?

'Lab.work' 카테고리의 다른 글

Weekly Report (10/27)  (0) 2009.10.28
Booksim VOQ 문제 해결  (0) 2009.10.27
Weekly Report (10/20)  (0) 2009.10.21
Weekly Report (10/12)  (0) 2009.10.12
Weekly report (10/5)  (0) 2009.10.12
블로그 이미지

민둥

,

공지사항

최근에 받은 트랙백

글 보관함

달력

«   2024/05   »
일 월 화 수 목 금 토
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

티스토리툴바