Download miễn phí Đề tài Đánh giá hiệu năng mạng (bài tham khảo 10)
Cơ chế hàng đợi FairQueue:
Trong hàng đợi FIFO có thể xảy ra vấn đề có hàng chờ mãi không được phục vụ và bị tràn gói tin đến. Để khắc phục nhược điểm này trong hàng đợi FairQueue các gói tin bên trong mỗi hàng đợi được truyền theo nguyên tắc FIFO, còn các hàng đợi khác nhau sẽ được truyền theo quy tắc vòng tròn (Round Robin).
http://s1.liketly.com/flash/edoc/jh2i1fkjb33wa7b577g9lou48iyvfkz6-swf-2014-01-05-de_tai_danh_gia_hieu_nang_mang_bai_tham_khao_10.Mg4bVb03ks.swf /tai-lieu/de-tai-ung-dung-tren-liketly-53769/Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Tóm tắt nội dung tài liệu:
BÁO CÁO THỰC HÀNH
Môn: Đánh giá Hiệu năng Mạng
GVHD: TS.Võ Thanh Tú
Nhóm 12 – Lớp K13TMT
Sinh viên:
Lý Triệu Hoàng
Đỗ Việt Triều
Nguyễn Viết Tài
Giới thiệu
Đánh giá hiệu năng Mạng là một trong những vấn đề quan trọng cho việc thiết kế và triển khai một hệ thống Mạng máy tính. Và việc đánh giá đó được thể hiện thông qua các chỉ số cơ bản: thời gian truyền tin, độ trễ trung bình, lưu lượng của đường truyền, tỉ suất lỗi…
Có nhiều phương pháp đánh giá hiệu năng của một hệ thống Mạng máy tính và phương pháp mô phỏng là một phương pháp khá tốt để đánh giá.
Với mục đích làm rõ các kiến thức đã được học về môn “Đánh giá hiệu năng Mạng” và tiếp cận với phần mềm mô phỏng NS2, phần mềm đồ họa TraceGraph; nhóm 12 thực hiện đánh giá hiệu năng của các hệ thống mạng cơ bản, và đưa ra các nhận xét khi đánh giá một hệ thống Mạng.
1. Mô hình 1
Hình 1: Mô hình
1.1 Trường hợp 1:
Mô hình gồm 6 node mạng và được kết nối như hình 1.
Dùng giao thức TCP để truyền gói tin từ node 1, node 2 đến node 6, dùng dịch vụ FTP. TCP Agent được gắn cho node 1, node 2; TCP Sink được gắn cho node 6 để nhận dữ liệu TCP gửi đến.
Dùng giao thức UDP để truyền gói tin từ node 3, node 4 đến node 6, dùng dịch vụ truyền gói tin là CBR. UDP Agent được gắn cho node 3, node 4; Agent Null được gắn cho node 6 để nhận dữ liệu UDP gửi đến.
Liên kết với nhau giữa các node trong mô hình là liên kết song công (Duplex Link), độ trễ 20ms. Hàng đợi sử dụng: DropTail.
Băng thông đường truyền giữa các node 1 và 5, 2 và 5, 3 và 5 là 10mbps, giữa node 4 và 5 là 100mbps, giữa 5 và 6 là 5mbps.
Thời gian truyền gói tin giữa các node
Thời gian bắt đầu(s)
Thời gian kết thúc(s)
Node 1 về node 6
0,1
3,1
Node 2 về node 6
0,2
3,2
Node 3 về node 6
0,3
3,3
Node 4 về node 6
0,4
3,4
Sau khi thiết kế mô hình, chạy mô hình với NAM ta được kết quả cụ thể sau:
Hình 2: Khi tất cả các node cùng tham gia truyền gói tin
Hình 3: Các gói tin bắt đầu rơi
Hình 4: Các gói tin TCP đã điều chỉnh khi phát hiện mạng tắc nghẽn
Nguyên lý của giao thức TCP trong điều khiển tắc nghẽn mạng:
Đối với mạng cố định, việc mất gói tin do lỗi đường truyền hiếm khi xảy ra. Mất gói tin đồng nghĩa với việc xảy ra tắt nghẽn ở các node (Router) trong mạng. Cơ chế điều khiển chống tắt nghẽn của TCP sẽ căn cứ vào điều kiện mất gói và kiểm tra time-out để xác định tắt nghẽn trong mạng.
TCP không có khả năng phân biệt giữa mất gói do đường truyền hay mất gói do tắt nghẽn, mỗi khi xảy ra hiện tượng trên TCP giảm tốc độ truyền.
Nhận xét: Ban đầu khi chỉ các gói TCP từ node 0 và 1(theo mô hình sau khi build) truyền về node 5 các gói TCP truyền ổn định; lúc các gói UDP xuất hiện từ node 2 và 3 truyền về 5, các gói tin dần rơi tại hàng đợi và các gói TCP giảm dần (Hình 4). Thời gian này trên đường truyền từ 4 về 5 hoàn toàn chỉ có các gói UDP, thỉnh thoảng các từ các node 0 và 1 phát ra các gói TCP nhưng đến hàng đợi đều bị rơi.
Dùng TraceGraph chạy file bt3.tr, ta thu được các kết quả:
Hình 5: Thống kê thông tin mô hình mô phỏng
Kết quả thu được trong thời gian 3.85s:
- Tổng số gói tin gửi: 3149 gói
- Số gói tin gửi thành công: 1887 gói
- Số gói tin rơi: 1262 gói
Thông lượng
Thông lượng
Thời gian(s)
Hình 6: Biểu đồ thông lượng của hệ thống
Nhận xét: Các gói tin ban đầu tăng dần trong khoảng giây 0 -> 1, sau đó dần ổn định và giảm dần do kết thúc thời gian truyền gói tin.
Độ trễ trung bình
Hình 7: Độ trễ trung bình
Tỉ lệ gói tin truyền thành công
Tỉ lệ gói truyền thành công = Số gói tin truyền thành công/Tổng số gói tin
= 1887/3149 = 0,599
1.2 Trường hợp 2:
Thay đổi băng thông đường truyền từ node 5 và 6 từ 5mbps lên 50mbps
50 mbps
Hình 8: Mô hình trường hợp 2
Hình 9: Độ trễ trung bình (trường hợp tăng tốc độ lên 50mbps)
So sánh độ trễ trung bình
Trường hợp
Độ trễ trung bình
Băng thông 5-6: 5 mbps
0,07273812295
Băng thông 5-6: 50 mbps
0,07268805397
Nhận xét: Độ trễ sẽ giảm khi ta tăng băng thông đường truyền do vậy độ trễ trung bình sau khi tăng thông lượng đường truyền nối node 5 và node 6 giảm đi nhưng không đáng kể.
1.3 Trường hợp 3:
Thay đổi Queue tại node 5 về 6 thành cơ chế RED
Cơ chế hàng đợi RED (Random Early Detection) – Dò sớm ngẫu nhiên – Khi xảy ra tăt nghẽn RED sẽ thông báo cho trạm nguồn về tắc nghẽn bằng cách cho rơi sớm gói tin, như vậy trạm nguồn nhận biết thông qua “time out” hay “duplicate ACK” và trạm nguồn giảm tốc độ phát với hi vọng không phải hủy bỏ nhiều gói tin sau đó. Xác suất rơi gói tin sớm phụ thuộc độ dài trung bình hàng đợi và hai ngưỡng minth, maxth . Vì vậy RED rất hữu dụng trong các mạng TCP tốc độ cao để tránh tắc nghẽn.
Sau khi dùng chương trình TraceGraph ta thu được kết quả:
Hình 10: Thông tin chi tiết trường hợp 3
Thông lượng gói tin rơi
Thời gian(s)
Hình 11: Thông lượng gói rơi
So sánh thông lượng gói tin rơi trong 2 trường hợp DropTail và RED
Thông lượng gói tin rơi
Thời gian(s)
Hình 12: Biểu đồ so sánh thông lượng gói tin rơi DropTail và RED
Nhận xét: Theo kết quả của biểu đồ hình 12 ta thấy hàng đợi RED tối ưu hơn hàng đợi DropTail, các gói tin rơi ít hơn và hiệu năng mạng tốt hơn do RED có cơ chế rơi gói tin sớm.
1.4 Trường hợp 4:
Thay đổi Queue tại node 5 về 6 thành cơ chế FairQueue
Cơ chế hàng đợi FairQueue:
Trong hàng đợi FIFO có thể xảy ra vấn đề có hàng chờ mãi không được phục vụ và bị tràn gói tin đến. Để khắc phục nhược điểm này trong hàng đợi FairQueue các gói tin bên trong mỗi hàng đợi được truyền theo nguyên tắc FIFO, còn các hàng đợi khác nhau sẽ được truyền theo quy tắc vòng tròn (Round Robin).
Sau khi thay đổi, ta thu được kết quả:
Hình 13: Thông tin chi tiết
Thông lượng gói tin rơi
Hình 14: Thông lượng gói rơi
Sau khi thay đổi 3 kiểu hàng đợi khác nhau (DropTail, RED, FairQueue), ta thu được kết quả: việc sử dụng hàng đợi dò sớm ngầu nhiên RED và hàng đợi cân bằng FairQueue làm chi hiệu năng mạng của hệ thông được nâng cao hơn (số gói tin rơi so với tổng số gói tin gửi có giảm hơn so với việc sử dụng hàng đợi DropTail).
Queue Packet
Tổng số
Rơi
DropTail
3149
1262
RED
3242
1281
FairQueue
4448
1975
1.5 Trường hợp 5:
Thay đổi TCP Agent thành TCP_Reno Agent
TCP_Reno Agent là một cải tiến của TCP_Tahoe, ở đây sau “phát lại nhanh” không phải là “bắt đầu chậm” mà là “hồi phục nhanh”, tức là các gói tin sẽ có cơ chế truyền nhanh hơn.
Ta thay đổi code OTcl trong file bt3.ns
# Create agents.
set agent(1) [new Agent/TCP/Reno]
$ns attach-agent $node(1) $agent(1)
$ns color 1 "#00000000ffff"
$agent(1) set fid_ 1
$agent(1) set packetSize_ 210
Sau khi biên dịch ta thu được kết quả:
Hình 15: Thông tin chi tiết
Hình 16: Các gói tin bắt đầu rơi
Hình 17: Khi các gói tin TCP Reno truyền ổn định
Hình 18: Thông lượng truyền
Kết quả thu được cho ta thấy việc sử dụng TCP_Reno Agent là hiệu quả hơn so với TCP Agent, hiệu năng của mạng được nâng cao hơn, lưu lượng gói tin trong đường truyền tăng lên.
Hình 19: Biểu đồ so sánh thông lượng TCP và TCP_Reno
So sánh về gói tin nhận và gửi của TCP và TCP_Reno
TCP Agent
TCP_Reno Agent
Gói tin gửi
3149
4018
Gói tin nhận
1887
2237
2. Mô hình 2
Hình...
