Improving Mobile Station Energy Efficiency in IEEE 802.16e WMAN by Burst Scheduling

前言 : 節省電源的基本觀念為集中式傳送(burst transmissions)，而集中式的傳送能達到最小的電源消耗，且也有符合802.16e所規範的QoS.

Longest Virtual Burst First (LVBF)的作法 :

Step 1 : 將所有的MS分成2種角色，一個是primary MS，另一個是secondary MS。Primary MS只有唯一一個，而secondary MS則會有許多個。

而被BS選出來的primay MS便保持在awake狀態，其餘的secondary MS則進入休眠狀態。

Step 2 : 當MS被BS分配成為Primary MS時，則該MS便能享有最大最多的資源(頻寬 or time slot)，此時它就可以毫無忌憚地傳送接受資料，一直到系統所規定的傳輸資料上限為止，接著就進入休眠狀態。

Step 3 : 當Primay MS已達到傳送上限，則BS再從目前的這一群secondary MS，選出一個MS成為primary MS來進行集中式的資料傳輸作業。

在primary MS於awake狀態進行資料傳送的過程當中，其餘的secondary MS由於QoS的關係，必需在這段過程中，由sleep → awake，做一些資料傳送的動作，以滿足其minimum data rate的要求，這樣才不會違反QoS。

而上述這3個步驟在進行中的時後，必需要遵守3個原則。

scheduling rule 1 : 一但MS進入awake狀態，scheduler就必需盡可能分配愈多的time slot給該MS。

scheduling rule 2 : scheduler必預選擇品質較好的通道給MS使用，以避免傳送時發生錯誤而需重傳。

scheduling rule 3 : 除非是為了滿足QoS的要求，否則若MS一但進入睡眠狀態，都不應被喚醒。

結論 :

1. 當MS的數量比較少時，LVBF在效能上會比Round Robin來得好，因為MS可以有較長的時間傳送資料，且也可減少狀態轉換次數。

將Vista、Windows Server 2008的開機磁區複製到另一顆HD後，郤無法開機?

案例 :

將伺服器上原本已有安裝Windows Server 2008的HD，用Ghost 複製到另一顆HD上，

然後將原本的HD卸除，改以這顆新複製的HD來開機，但在開機後郤出現如下所示的錯誤訊息...

============================================================

Windows 無法啟動。 最近的硬體或軟體變更可能原因。 若要修正問題：

1.插入您的 Windows 安裝光碟並重新啟動您的電腦。

2.選擇您的語言設定，然後按一下 [下一步]。

3.按一下修復您的電腦。

如果您沒有這片光碟請連絡您的系統管理員] 或 [電腦製造商以取得協助。

檔案: \Windows\system32\winload.exe

狀態: 0xc00000001

資訊: 無法載入選取的項目，因為應用程式遺失或損毀。

============================================================

詳情請參考 http://h50178.www5.hp.com/support/GU404PA/solve/82920.html ，以下為全文複製。

原因 :

在 Vista 之前的 NT 版本中，開機檔案 (ntldr、Ntdetect.com 和 boot.ini) 全部位於開機磁碟作用中主要分割區的 root 中。

在 Vista 中，這三個檔案已被 bootmgr、Boot Configuration Data (BCD) 和 winload.exe 取代，

但只有 bootmgr 和 BCD 仍在系統分割區的 root 中，

而 winload.exe 現在則常駐在 Boot 分割區的 Windows/system32 資料夾內。 BCD 檔案已取代 boot.ini檔案。

舊版的 WinNT 使用 boot.ini 檔案尋找硬碟和分割區的位置。

結合 boot.ini 資料和電腦的 BIOS 資料後，ntldr 會判斷用來開機的 Windows/system32 是在哪一個硬碟和分割區內。

Vista 已變更開機程序： 硬碟獨有的磁碟簽章 (從 MBR) 儲存在 BCD 中。

將影像檔 (Rdeploy、Ghost 等) 回復到另一個硬碟後，簽章也會隨之變更。

Bootmgr 會掃描所有硬碟以尋找此簽章，如果找不到，開機程序便會停止並顯示「unable to access \windows\winload.exe」。

解決辦法 :

* 在製作影像檔之前：

如果 Vista 位於開機磁碟的主要分割區中，便會使用 BCDedit 命令來「一般化」安裝作業，

以建立影像檔 (因此會從目前所用的分割區開機，而不檢查磁碟簽章)。

此方法與 Microsoft sysprep 公用程式所使用的方法相同。 按一下滑鼠右鍵開啟命令提示字元，

選擇「以系統管理員身分執行」後，再鍵入下列命令：

bcdedit /set {current} osdevice boot bcdedit /set {current} device boot bcdedit /set {bootmgr} device boot

*在複製之後：

有數種可能的程序，下文摘自 http://support.microsoft.com/kb/927391 。

方法 1： 使用「啟動修復」選項來修復 BCD 存放區

1. 將 Windows Vista (or Windows Server 2008)安裝光碟放入光碟機，再啟動電腦。
2. 於光碟開機提示時按下任一按鍵。
3. 選取語言、時間、貨幣和鍵盤或其他輸入方法後，再按一下「下一步」。
4. 按一下「修復您的電腦」。
5. 依序按下欲修復的作業系統和「下一步」。 6. 按一下「系統修復選項」對話方塊中的「啟動修復」。
6. 重新啟動電腦。

方法 2： 使用 Bootrec.exe 工具重建 BCD 存放區。如果前一個方法無法解決問題，

便可使用 Windows Recovery Environment 中的 Bootrec.exe 工具來重建 BCD 存放區。

1. 將 Windows Vista (or Windows Server 2008) 安裝光碟放入光碟機，再啟動電腦。
2. 於提示時按下任一按鍵。
3. 選取語言、時間、貨幣和鍵盤或其他輸入方法後，再按一下「下一步」。
4. 按一下「修復您的電腦」。
5. 依序按下欲修復的作業系統和「下一步」。
6. 按一下「系統修復選項」對話方塊中的「命令提示字元」。
7. 鍵入 Bootrec /RebuildBcd 後按下 Enter。

如果原本機器上有安裝Hyper-V，在更換HD後，會連帶造成Hyper-V無法正常運作，

出現Hypervisor未啟動的錯誤訊息，此時只要進入命令提示字元，

輸入" BCDEdit /set hypervisorlaunchtype auto "的指令，再重新開機就能解決。

Adaptive Sleep Mode Algorithm in IEEE 802.16e

主旨及問題 :

由於傳統的Type 1，在睡眠時間到達maximum sleep window interval之後，如果依然還是沒有資料要傳輸，

那麼就會持續使用maximum sleep window interval作為其睡眠時間的依據，

但此時接著就會產生2個問題。

1. 傳輸延遲 : 當接下來如果有data在睡眠時產生，MSS需等到睡眠時間結束後才能甦醒，

待進入Listen window而得知有資料要傳輸，最後才跳離sleep mode回到normal mode.

2. 不必要的電源損耗 : 如果MSS睡到一半的時後，突然有資料產生要傳送，

此時MSS若不等到maximum sleep window interval結束，

而是只再睡一小段時間(假設 此一小段的時間 小於 maximum sleep window interval )，

那麼與原本要睡完一整個maximum sleep window interval時間相比，

此時MSS就會有不必要的電源損秏產生。

P.S : 此篇論文的假設前提，是架構在連MSS進入睡眠時，都會有電源消耗的情況之下，

而並非一般普遍所認為的，在進行睡眠時不會消耗電源的情況。

作法 :

若MSS的睡眠時間，已到達maximum sleep window interval，接下來不再是睡maximum sleep window interval這個時間，

而是改睡AVG這個時間長度，AVG = (initial sleep windows size + maximum sleep window size)/2，

除此之外，AVG亦會以2的指數倍成長，最大不得超過AVGmax這個時間長度(由user自行訂定)。

而當MSS的睡眠時間長度又到達AVGmax後，下一個睡眠時間長度又將再回到AVG。

換言之 : initial sleep window size 小於等於 AVG 小於 AVGmax 小於等於 maximum sleep window size

MSS一整個睡眠時間長度變換過程如下 :

Normal mode → initial sleep window size → initial sleep window size x 2 → initial sleep window size x 4 → initial sleep window size x 8 → ..... → maximum sleep window size → AVG → AVG x 2 → AVG x 4 → AVG x 8 → ..... → AVGmax → AVG → AVG x 2 → AVG x 4 → AVG x 8 → ..... → AVGmax → .....

結論 :

因為MSS的睡眠時間在第一次到達maximum sleep window interval之後，接下來就會改睡AVG (or AVGmax)這個時間，

又AVG & AVGmax皆小於maximum sleep window interval，所以即使接下來有資料要傳送，

那麼與原本要睡完一整個maximum sleep window interval相比，可以減少傳輸延遲及不必要的電源消耗。

IPSS: Integrated Power Saving Scheduling Algorithm for IEEE 802.16 PMP Networks

英文 : IPSS: Integrated Power Saving Scheduling Algorithm for IEEE 802.16 PMP Networks

中文 : 應用於IEEE 802.16網路之整合性節能演算法

主旨 :

1. 此篇提出的目的，並非在改進之前某一個排程演算法的缺點，而是在於提出一個新的實作方法。

其最主要的作法，就是先將服務劃分為即時性服務與非即時性服務。再依此對這2個群組重新做排程的動作，預先分配頻寬，避免在單一frame裡有過多的MSS存取網路。

2. 在BS的UL/DL scheduler與PSC Controller之間，加入一個IPSS模組，利用此模組控制UL/DL scheduler與PSC Controller，

使得MSS即使在睡眠模式的運作之下，連線服務品質仍能被滿足，另一方面藉由控制PSC Controller，驅使MSS根據IPSS排程結果進行睡眠模式的運作。

作法 :

1. 先提出 sub-cycle & scheduling cycle的概念，以及對服務做分類..

Q : 那又為何要使用sub-cycle & scheduling cycle ?

A : sub-cycle其實也就是計算出在不違反delay constraint的原則之下，最多能夠延遲多久才能資料送出的這個值。

而scheduling cycle是要給非即時性服務所使用的值，沒有什麼嚴格限制的要求，也因為如此，所以其中的β值，才可以自行任意訂定。

2. 有了sub-cycle & scheduling cycle的值之後，才能夠計算出該預留多少頻寬分配給group 1 & group 2.

3. 計算該預先保留分配多少頻寬給MSS，以及該MSS要在哪一個Frame( or 時刻)醒過來.

4. 每間隔一個scheduling cycle的時間，IPSS會將這些分散在β個sub-cycle的頻寬資源做重新分配給下一個group 2的MSS使用。

同理，每間隔一個sub-cycle的時間，IPSS將group 1的頻寬資源做重新分配給下一個group 1的MSS使用。

導師同學發問時間...

Q : 為何針對Figure 4.2(a) & Figure 4.2(b)的實驗結果圖，採IPSS作法，能得到將近100%的average sleeping ratio ? 而MMPS+WFQ的作法，以及without Mgnt+WFQ的作法，其average sleeping ratio，郤不會那麼漂亮，而且還會隨著MSS數量的增加，而有下降的驅勢?

A : IPSS的作法，最主要是充份利用delay constraint。當收到封包後，就盡量往後面一直拖一直拖，拖到不能再拖，delay constraint快到了之後，擠到最後一刻才把資料送出去，所以可以有充足的睡眠時間。

而MMPS & 傳統的802.16，並不會拿delay constraint做為其考量的依據，如果有收到封包後就馬上傳送，傳送完又要再等一段時間來進入休眠模式，所以average sleeping ratio才不會那麼高。

而如果MSS的數量又逐漸增多，MSS之間能彼此配合一起共同睡眠的時間又會相對地變少，到最後可能幾乎就無法再進入休眠狀態。

如何實作SQL Server 2005 2008 DB Mirroring (上集) ?

前言 : 要完成SQL Server DB Mirroring，並能fail over，至少需要三台機器。

這三台機器的角色分別是Principal(主體)、Mirror(鏡像) & Witness(見證)。

Principal 主體 : 資料庫預設存放的機器

Mirror 鏡像 : 當需要做fail over時，資料庫會從主體移轉至鏡像。

Witness 見證 : 見證伺服器用來監控主體是否能正常運作，當見證伺服器發現主體有問題，就會自動將資料庫切換至鏡像伺服器。

P.S :

1. 當fail over發生時，主體 & 鏡像 所屬的機器是會改變的。並非某台機器將綁死某個角色而不再變動。

2. 鏡像資料庫是無法被存取的，只有主體資料庫才能被存取，所以SQL Server的版權，只要買一套即可。

Step 1 : 建立DNS Server

Step 2 : 開始 → 執行→ 輸入 dcpromo ，建AD，建立新樹系。

Step 3 : 將其它PC加入該domain (例 : OASIS.corp)

Step 4 : 在AD內新建一帳號，取名為SQLService，為的就是要來啟動SQL服務 ; 又因為此帳號是用來啟動SQL服務，所以有管理SQL Server的最高權限(等同sa)。

假設已將SQL Server 2005 2008 安裝完畢。

Step 5 : SQL Server 組態管理員 → SQL Server 服務 → 開啟 SQL Server (MSSQLSERVER) ,將登入身份由Local system改成剛剛建立的SQLService(例 : OASIS\SQLService)

Step 6 : 確認 DNS的record是否正確

Step 7 : 確認 SQL Server 組態管理員 → SQL Server網路組態 → MSSQLSERVER的通訊協定 → TCP/IP 內的IP與port是否正確。

P.S : 在安裝SQL Server完畢且SQL Server曾運行一段時間之後，若本機電腦的IP曾更換過，則TCP/IP內所記載的IP與port，有可能與現行狀態不符合。雖然此種情況不會影響到SQL Server的正常運作，但有時在做一些特殊設定時，會參考到此TCP/IP內的設定值，但因為TCP/IP內的設定值，與現在本機電腦真正在使用的IP不同，所以此時就會發生無法順利完成設定的情況，就得來此做檢查。

Step 8 : 開始建立主體、鏡像 & 主體 伺服器，在設定過程當中，端點名稱可隨意取，但是不要用中文。

arg max 的解釋

y=f(x) , x為input , 將x丟入f函式後就能得到y這個值。

z = max f(x) : x的值可能有很多種，將x丟入f後，那麼也會相對地產生許多y值，那麼在這眾多的y值當中，會有一個最大的y值，而 z 就是指這個最大的y值。

w = arg max f(x) : 將x丟入f後，會產生最大的y值(也就是z)，而w就是能讓f產生最大y值的參數x值。

例 :

x={1 , 2 , 3) , f(1) = 20 , f(2)=50 , f(3) = 5 , 則 y={20 , 50 , 5} 所以 z = 50 , w = 2 .

MSN名句

樹多必有枯枝，人多必有白癡。

君子報仇，三年不晚。小人報仇，一天到晚。

醫生叫我行光合作用別熬夜。

帥有個屁用！到頭來還不是被卒吃掉！

騎白馬的不一定是王子，可能是唐僧；帶翅膀的不一定是天使，也可能是「鳥人」。

就算是Believe中間還是有個lie 。

就算是 Friend 最後還是會有個 end

就算是 Fuck 起初也要有 Fu。

就算是 Lover 最後還是會 over。

就算是 forget 也要先get才行。

就算是個 puma 最後還是會變ma。

就算有個 wife 心裡也要假設if。

壓力始終來自於新台幣！

不是隨便一個地球人就可以學會火星話的。

樹不要皮，必死無疑。人不要臉，天下無敵。

『在塞納河畔哭泣』『在濁水溪旁哭夭』這兩者揪~~~~竟有什麼不同呢？

人生，不過比當歸長一點。

懷才就像懷孕，時間久了才能讓人看出來。

上帝給了我們七情六慾，我們卻把它們變成了色情和暴力。

承諾，就像「幹你娘」一樣，經常說，但是很難做到。

最浪漫的三個字不是「我愛你」，而是「在一起」。

男友在愚人節說了十次我愛你。

客戶是神，因為客戶不是人。

前程四緊就是：手頭緊、眉頭緊、衣服緊、時間緊。

青春就像衛生紙。看著挺多的，用著用著就不夠了。

女人的愛是用說的，男人的愛是用做的。

世上沒有任何的成功，能夠彌補家庭的失敗。

幸福離我們很近，但，我們都忘了靠近。

天底下沒有所謂複雜的事情，是人的思維和感情把它複雜化了。

人們在男/女朋友身上種草莓的行為…就像是小狗在電線杆尿尿佔地盤！

時間就像乳溝，擠一擠就有。

機會就像老二，握住就會變大。

能者多勞，疲勞的勞！

有教無類→　有交錢,就不分類!!!

問君能有幾副肝，恰似一串鞭炮爆不完。

硬碟的容量決定男人的力量。

男人過了五十歲只剩下一張嘴，過了六十歲就只有兩個地方會變硬…… 後頸部的筋脈和不會喊痛的肝。

老王說：「通常蒙上臉的人，都特別厲害。」你是說扁輻俠?蜘蛛人?還是Waterman...??

福利不是問題，問題是沒福利。錢不是問題，問題是沒錢。

今日事今日畢，過了今日就不必。

皮夾裡的發票永遠比鈔票多。

既然上了賊船，就要做個成功的海盜。

我不是隨便的人，但我隨便起來不是人

Power Saving Class Management for Energy Saving in IEEE 802.16e Wireless Networks

這一篇太難了，雖然都有看懂(?????)，但同學 & 老師提出問題時，我又被電得慘兮兮，似懂非懂，

所以這篇不知道該怎麼從何講起...

高雄市區拍攝大頭照的推薦店家

這一間不是什麼大相館，隱藏在小巷子當中，更是沒有什麼招牌， 上門的顧客，幾乎都是口耳相傳而來的。

第一次到墾丁...

打從我出生到現在，還沒到過墾丁...

只是看到有人說，屏東縣道185上的車子少路又好騎，而且也是去墾丁的替代道路，

不用在高雄市區 & 屏東市區和一堆車在那邊塞，心血來潮就這樣一個人自已衝了。

到了墾丁之後，發現...

嗯!! 年輕真好...沿途都是一堆年輕人騎車出遊。

原本是要背包包帶單眼及腳架一起去，但後來覺得騎車背包包有點麻煩，所以就沒帶了。

不過既然來了，總是要拍個照做紀念(好像台灣人都喜歡這樣.....╮(﹋﹏﹌)╭..)，證明我有來過，

不過沒帶相機，只能用手機拍一拍來交差。

NetMeeting的使用教學

安裝及設定 :

1. 




2. 



3. 



4. 



5. 



6. 



7. 



8. 
   
   
9. 



10. 



11. 




12. 



13. 由 報告者 呼叫 參與者 或 參與者 呼叫 報者 皆可...(10.97.30.199是參與者)
    



14. 被呼叫者的電腦會跳出此一對話框。
    



15. 此處假設報告者欲做簡報...開啟PowerPoint後，再點選NetMeeting的[工具]→[共用]
    



16. 可選擇僅共用單一程式，或是共用整個桌面。
    
    
    


17. 在參與者的電腦上，就可以看到遠端報告者所共用出來的畫面了。
    

Adaptive Power Saving Strategies for IEEE 802.16e Mobile oadband Wireless Access

主旨 : 在討論傳統IEEE 802.16e的三種休眠模式的前提下，
Initial-sleep window size , Final-sleep window size , Listening-window size , and power saving threshold size 這些參數與休眠機制皆有關，
找出何種因素會影響到休眠時間的長短，以及探討休眠時間與延遲之間的關係。

作法 :

1. 先推導出worst delay與initial-sleep window size有關，且電源消秏量也與initial-sleep window size有關，再利用CBR traffic流量的實驗來證明。


2. 再以FTP traffic來做實驗，所以packet delay不是重點，比較關心的是整個傳輸時間。然後又因為是FTP traffic，所以再引進RTT(Round Trip Time , 封包來回所需的時間)這項變數，探討在不同的RTT的情況下，initial-sleep window size與transmission time之間的關係。

結論 :

1. Threshold size越大 → MSS越無法進入休眠狀態。


2. Initial-sleep window size 與 average delay 成正比。


3. 為了限制最大的delay，initial-sleep window size <>RTT值 與 傳輸時間 成正比。


4. 在不同RTT值的情況下，有無啟動休眠模式與傳輸時間沒有什麼關係。


5. 在FTP traffic的實驗當中，當設定RTT值較大 or 有高傳輸速率的前提下，將initial-sleep window size及findal-sleep window size設定為queue empty time，可以啟動休眠模式，又能讓整個傳輸時間不致於延長太久。

問題 :

Q1. 為何在FTP traffic實驗要加入RTT(Round Trip Time = 封包來回所需的時間)此項控制變因， 對分析此問題有何幫助 ?

Answer : 個人認為...針對使用FTP做資料傳輸，著重點在於sender & receiver之間的傳輸速率是否夠快? 進而影響到整個所需的傳輸時間，而傳輸速率意謂著封包來回所需的時間，所以才會納入此項因素，探討在不同的RTT的情況下，initial-sleep window size與傳輸時間之間有無關係。

Q2. 在 Fig 2 (b) 的圖中，為何 initial-sleep window size = 300 的秏電量 大於 initial-sleep window size = 250 的秏電量 ?
initial-sleep window size = 400 的秏電量 大於 initial-sleep window size = 350 的秏電量 ?

Answer :

2者的threshold皆為50，封包在75,150,225,300,375,450 msec時抵達...

針對 initial-sleep window size = 250 來說...在50時進入休眠模式，而在300時醒過來，等了50後，在350又進入休眠模式。從第一次醒過來到進入第二次休眠模式，時間相差了 350-300 = 50。

針對 initial-sleep window size = 300 來說...在50時進入休眠模式，而在350時醒過來...

理論上，若在350~400這段時間，都沒有封包抵達的話，那麼在400時會進入休眠模式 ; 但是在375時郤有封包抵達，所以MSS就必需立刻進行資料傳輸，得等到425時才能進入第二次休眠模式。從第一次醒過來到進入第二次休眠模式，時間相差了 425-350 = 75。

根據以上的計算結果，可以證明initial-sleep window size = 300 的秏電量 大於 initial-sleep window size = 250 的秏電量。

而initial-sleep window size = 400 的秏電量 大於 initial-sleep window size = 350 的秏電量，也同理可證。