Try   HackMD

無線及寬頻網路week4 1102951

請說明jitter在網路中的含意為何?

measure_jitter.awk的程式碼片段

jitter = ((recvtime(j)-sendtime(j))-(recvtime(i)-sendtime(i)))/(j-i)

由measure_jitter.awk所繪製出的圖形
image
jitter,中文直譯為抖動,由程式碼以及圖形不難看出,他計算的是兩個連續封包之間的延遲差異,再利用多個封包繪製成一張圖,而這張圖就是在指定時間內封包傳輸延遲的變動性,因此jitter的含意應為封包傳輸延遲的變動性

請說明measure-jitter.awk是如何將cbr的jitter算出來

由上面程式碼可得知,cbr的jitter計算方式為(前一個封包的接收時間-發送時間)-(目前封包的接收時間-發送時間)/(前一個封包編號-目前封包編號),如果為正,則表目前封包的延遲較前一封包低,反之亦然,若為0則表延遲不變

請修改measure-jitter.awk,顯示原實驗過程中的tcp jitter圖形

修改位置:將CBR的flow_id == 2改為TCP的flow_id == 1(由out.tr得知)

修改程式碼片段如下:

if ( flow_id == 1 && action != "d" ) { if ( action == "r" ) { end_time[packet_id] = time; } } else { end_time[packet_id] = -1; } }

修改後生成之TCP jitter圖形

image

請修改原始exp3.tcl,取消ftp/tcp的流量,將取消前後的cbr的jitter畫在同一張圖,觀察兩線有何不同,嘗試並解釋其原因

修改後程式碼如下

set ns [new Simulator] # w 藍 P Ƭy w q P C A o O n NAM Ϊ $ns color 1 Blue $ns color 2 Red # } Ҥ@ NAM O set nf [open out.nam w] $ns namtrace-all $nf # } Ҥ@ Ӽ L { O ɡA ΨӰO ʥ] ǰe L { set nd [open out.tr w] $ns trace-all $nd # w q @ ӵ { proc finish {} { global ns nf nd $ns flush-trace close $nf close $nd # H I 檺 覡 h NAM exec nam out.nam & exit 0 } # Ͷǿ ` I set s1 [$ns node] set s2 [$ns node] # ͸ Ѿ ` I set r [$ns node] # ͸ Ʊ ` I set d [$ns node] #s1-r 㦳2Mbps W e,10ms ǻ ɶ ,DropTail C ޲z 覡 #s2-r 㦳2Mbps W e,10ms ǻ ɶ ,DropTail C ޲z 覡 #r-d 㦳1.7Mbps W e,20ms ǻ ɶ ,DropTail C ޲z 覡 $ns duplex-link $s1 $r 2Mb 10ms DropTail $ns duplex-link $s2 $r 2Mb 10ms DropTail $ns duplex-link $r $d 1.7Mb 20ms DropTail # ] wr d Queue Limit 10 ӫʥ] j p $ns queue-limit $r $d 10 # ] w ` I m A o O n NAM Ϊ $ns duplex-link-op $s1 $r orient right-down $ns duplex-link-op $s2 $r orient right-up $ns duplex-link-op $r $d orient right # [ r d queue ܤơA o O n NAM Ϊ $ns duplex-link-op $r $d queuePos 0.5 # إߤ@ TCP s u #set tcp [new Agent/TCP] #$ns attach-agent $s1 $tcp #set sink [new Agent/TCPSink] #$ns attach-agent $d $sink #$ns connect $tcp $sink # bNAM ATCP s u | H Ŧ #$tcp set fid_ 1 # bTCP s u W إ FTP ε{ #set ftp [new Application/FTP] #$ftp attach-agent $tcp #$ftp set type_ FTP # إߤ@ UDP s u set udp [new Agent/UDP] $ns attach-agent $s2 $udp set null [new Agent/Null] $ns attach-agent $d $null $ns connect $udp $null # bNAM AUDP s u | H $udp set fid_ 2 # bUDP s u W إ CBR ε{ set cbr [new Application/Traffic/CBR] $cbr attach-agent $udp $cbr set type_ CBR # ] w ǰe ʥ] j p 1000 byte $cbr set packet_size_ 1000 # ] w ǰe t v 1Mbps $cbr set rate_ 1mb $cbr set random_ false # ] wFTP MCBR ƶǰe } l M ɶ $ns at 0.1 "$cbr start" #$ns at 1.0 "$ftp start" #$ns at 4.0 "$ftp stop" $ns at 4.5 "$cbr stop" # TCP s u( @ w ݭn g U { X ӹ ڵ s u) #$ns at 4.5 "$ns detach-agent $s1 $tcp ; $ns detach-agent $d $sink" # b Ҥ A5 h I sfinish ӵ ( o ˭n ` N Ҥ # 5 ä @ w ڼ ɶ $ns at 5.0 "finish" # $ns run

取消ftp/tcp的流量前後之CBR的jitter圖形

image

觀察兩線有何不同,嘗試並解釋其原因

可以看到,原先的CBR jitter圖形在時間點一秒時產生波動(為TCP傳輸啟動時間),直至約莫4秒時才結束波動(為TCP傳輸結束時間),可以得知在中繼點傳送至目地端時,因為TCP的封包與CBR封包在中繼點的Queue中堆積,因而產生了延遲,另外可以觀察到,在此波動期間,延遲頻率是有逐漸增加的趨勢,而後延遲消失一小段時間,這是因為TCP的slow start政策,一開始傳較少的封包,因而延遲頻率較低,到後面TCP傳越來越多封包,因而在Queue中堆積因而開始產生延遲,到最後因Queue裝不下了,開始丟包,因此TCP減少封包的傳送,延遲因而降低,循環往復直至TCP傳輸結束

請修改原始exp3.tcl,將其中的queue由10改為100,請先預測cbr封包loss數量會增多或減少,並說明你的原因?接著,進行實驗,比較你的結果是否相符?並嘗試說明其原因。

修改位置:將queue-limit從10提高為100

修改程式碼片段如下:

$ns queue-limit $r $d 10

預測

當然會變好,畢竟queue所能容納的封包數量增加了

將queue由10改為100的封包丟失情形

queue = 10情況:
number of packets sent:550 lost:0
queue = 100情況:
number of packets sent:550 lost:8

結果

符合預期,因為queue所能容納的封包數量增加了