網路io調度模式哪個性能好

❶ 2、請說明I/O編程模式和MM編程模式的主要區別和各自的特點

cpu內核調度模式！ deadline指的不不超越
內核bfq 、cfq、 noop、 dealine的任務調度區別：

任務調度有兩種相對的極端，一種是重視並提高前台任務性能，
相對的就是前後台任務均衡調度，這五種調度策略跟兩個極端關系是這樣：
提高前台任務性能-noop-sio-deadline-cfq-bfq
noop最強調前台性能，bfq最強調前後台性能的均衡，
這里的五個調度策略其實是i/o的調度策略！
noop是最簡單的i/o調度策略，本質上就是先來先服務，意思就是哪個進程先請求i/o系統就先為哪個進程服務，有最好的連續存取性能（具體原因下面講），
bfq會均衡考慮各進程i/o請求的任務量，適當調整完成i/o請求的順序（也就是說服務順序和請求順序不一樣），保進程在最短時間內能得到i/o響應（但不保證每
次響應都能完成），也就是有最好的隨機存取，延時低。
noop不考慮i/o請求的任務量（通俗點說就是不考慮讀寫的文件是大還是小），按照i/o請求的順序依次進行服務。這種策略在pc上的執行過程中主要有兩個問題，
第一個是i/o請求任務量很大（要讀寫的某個文件很大）造成其他i/o請求長期得不到響應，第二個是相鄰兩次的i/o請求涉及的文件在磁碟上的物理位置較遠造成處理這i/o請求時磁頭需要頻繁移動導致性能嚴重降低。
第一個應該很好理解，i/o任務量不管大小依次排隊，當處理到一個很大的任務時，系統將一直處理下去，後面的請求就得不到響應了，
第二個問題舉個例子，有4個相鄰的i/o請求分別涉及1、2、3、4這四個文件，
而1、2、3、4分別位於磁碟的內圈、外圈、內圈、外圈，也是說處理這4個請求時磁碟上的磁頭必須先移到內圈，
然後移到外圈，接著移到內圈再移到外圈，如此反復導致大量的時間用於移動磁頭造成性能降低。
反過來看手機，一般手機上的i/o任務都不會很大，很少有需要連續讀幾百M甚至更大文件的情況，即便要讀通常也是正在玩游戲需要讀數據文件（我相信手機上不會有一邊上網聊qq，手機後台還有個程序需要連續讀幾百M文件的情況），這時用戶通常希望系統盡快把文件讀完從而繼續玩游戲。
由於noop在處理大任務時會使後續的i/o請求得不到響應，因此具有較好的連續性能，這個特點正好滿足了上面這種用戶的求。
關於上面說的第二個問題，由於手機上用的是快閃記憶體晶元，也就不存在磁頭移動的問題，像其他策略那樣考慮磁頭的移動問題對於採用快閃記憶體晶元的存儲介質完全是浪費，所以對於隨機性能很好的快閃記憶體晶元來說noop是最好的i/o調度策略。
下面看bfq，bfq指的是budgetfair queuing，從名字上就能看出來這個策略對於各i/o請求是公平的（fair），不會有上面說的noop的第一種問題。
這里指的公平就是盡量使各進程的i/o請求都能得到盡快響應不會長期擱置，但因為系統資源有限，所以只能保證盡快響應但不保證可以盡快完成。
不難看出bfq適合多進程同時發出多i/o請求的狀況，因為它不會像noop那樣無視後續的i/o請求。直觀的看就是手機程序開的很多時系統還能對各進程有不錯的響應速度，
這就是為什麼bfq適合多進程，可以均衡協調前後台任務性能的原因。bfq實際上是cfq的改進！

❷ noop,deadline,cfq，你們覺得對於sensation來說哪個I/O調度好點謝謝了！

noop 和 cfq應該都可以

❸ 以下哪種io調度演算法 吞吐量最高

肯定是都可以的，FCFS這種方式不太合適，因為如果有一個程序IO時間長的話就使得其他程序都會「死」掉，輪轉和優先順序結合起來較好

❹ 安卓io調度模式哪個好

• 安卓io調度含義

  即輸入輸出。I/O Schelers不光提供了磁碟讀寫操作的策略，同時還關繫到不同應用之間讀寫請求的優先順序、存儲系統帶寬共享以及請求及時響應等。

• 優秀的安卓io調度Deadline

1. Deadline(截止時間調度程序)：顧名思義，用過期時間來排序io操作順序，保證先出現的io請求有最短的延遲時間。

2. 相對於寫操作，給讀操作更優先的級別，確保了在一個截止時間內服務請求，這個截止時間是可調整的，而默認讀期限短於寫期限，這樣就防止了寫操作因為不能被讀取而餓死的現象，是比較好的一個調度模式。

❺ IO調度策略是什麼，這幾個是什麼意思，該選哪個好

你好，具體的請看下面
I/O調度模式：
I/O 即inpu/oupu的縮寫，關於數據的讀寫操作，不同進程請求 數據的優先順序等等。io調度模式比較復雜，我沒有具體測試，這里僅對ray上出現的幾個模式做說明，部分參考xda、androidforums、 wik1pedia、linuxarchive資料）
sio
雖然基於deadline，但是它和noop一樣，不會對io操作進行排序，所以有著noop那樣快速的存取速度，但並沒有過多優化io操作。如果不喜歡noop完全不參與調度，也可以選擇這個。
noop
這個調度模式會把所有的數據請求直接合並到一個簡單的隊列里。不適合有機械結構的存儲器，因為沒有優化順序，會增加額外的尋道時間。屬於最簡單的一個調度模式，無視io操作優先順序和復雜性，執行完一個再執行一個，如果讀寫操作繁多的話，就會造成效率降低。
deadline
顧名思義，用過期時間來排序io操作順序，保證先出現的io請求有最短的延遲時間，相對於寫操作，給讀操作更優先的級別。是比較好的一個調度模式。
cfq
完全公平隊列，是anicipaory模式的替代品，沒有過多的做預測性調度，而是根據給定的進程io優先順序，直接來分配操作的順序。這個模式在linux上表現良好，但也許並不是最適合android的io調度模式，太強調均衡，而降低了連續讀寫數據的性能。
vr
具有和deadline相似的操作排序機制，有著最高的峰值讀寫速度，但是性能比較不穩定，也就是說可能跑出最高的分數，但是也會出現最低值。
Row
顧名思義ROW=Read over we，最大限制減少IO響應時間，並且重排執行操作，直接進行讀寫操作，給予IO最高優先值。在移動設備中，它將不會在桌面上有 盡可能多的並行線程。通常它是一個單一的線程或最多2個同時工作的線程讀寫。有利於閱讀的請求通過寫入讀取的延遲大大降低。比deadline好用，但是 如果線程過多有可能會帶來瞬間卡頓）
選擇你以適合你的就ok；望採納！

❻ 手機的CPU調節器和I/O調度器分別是什麼意思

powersave省電模式但反應慢 interactive這個是自由升降模式，可以用。

performance高性能模式但費電，如果選擇那個ondemand又省電又有性能。I/O選擇cfq，正常模式。setcpu開機後，調整CPU頻率，該頻率可以超頻CPU主頻的提高，或降低，可節省。

Android的CPU的頻率並不是一成不變的，會因應程式所需而調整頻率，通常會視乎CPU Loading% 而升/降頻，在特定時間再檢查是否升/降。I/O即input/output的縮寫關於數據的讀寫操作不同進程請求數據的優先順序等等。

(6)網路io調度模式哪個性能好擴展閱讀：

CPU的頻率並不是一成不變的，會根據機器的需要而調整頻率，這就需要有一個規則去規范，要不就亂套了，設置這個規則就是CPU調速器。CPU調速器的設置影響兩個指數：使用舒適度和耗電，也就是響應速度、流暢度、穩定性和費不費電。

手機CPU調節器CPU-Z是一款非常厲害的CPU管理工具，這款軟體在PC平台上早就非常受歡迎了，後來作者製作了安卓版的CPU-Z，在Android手機上就可以體驗了，和pc的功能一樣，CPU-Z 也是可以查看的參數非常豐富，CPU 核心、GPU、電池、感測器、發熱等相關信息。

❼ IO模型及select，poll，epoll和kqueue的區別

（一）首先，介紹幾種常見的I/O模型及其區別，如下：
blocking I/O
nonblocking I/O
I/O multiplexing (select and poll)
signal driven I/O (SIGIO)
asynchronous I/O (the POSIX aio_functions)—————非同步IO模型最大的特點是 完成後發回通知。
阻塞與否，取決於實現IO交換的方式。
非同步阻塞是基於select，select函數本身的實現方式是阻塞的，而採用select函數有個好處就是它可以同時監聽多個文件句柄.
非同步非阻塞直接在完成後通知，用戶進程只需要發起一個IO操作然後立即返回，等IO操作真正的完成以後，應用程序會得到IO操作完成的通知，此時用戶進程只需要對數據進行處理就好了，不需要進行實際的IO讀寫操作，因為真正的IO讀取或者寫入操作已經由內核完成了。

1 blocking I/O
這個不用多解釋吧，阻塞套接字。下圖是它調用過程的圖示：

重點解釋下上圖，下面例子都會講到。首先application調用 recvfrom()轉入kernel，注意kernel有2個過程，wait for data和 data from kernel to user。直到最後 complete後，recvfrom()才返回。此過程一直是阻塞的。

2 nonblocking I/O：
與blocking I/O對立的，非阻塞套接字，調用過程圖如下：

可以看見，如果直接操作它，那就是個輪詢。。直到內核緩沖區有數據。

3 I/O multiplexing (select and poll)
最常見的I/O復用模型，select。

select先阻塞，有活動套接字才返回。與blocking I/O相比，select會有兩次系統調用，但是select能處理多個套接字。

4 signal driven I/O (SIGIO)
只有UNIX系統支持，感興趣的課查閱相關資料

與I/O multiplexing (select and poll)相比，它的優勢是，免去了select的阻塞與輪詢，當有活躍套接字時，由注冊的handler處理。

5 asynchronous I/O (the POSIX aio_functions)
很少有*nix系統支持，windows的IOCP則是此模型

完全非同步的I/O復用機制，因為縱觀上面其它四種模型，至少都會在由kernel data to appliction時阻塞。而該模型是當完成後才通知application，可見是純非同步的。好像只有windows的完成埠是這個模型，效率也很出色。
6 下面是以上五種模型的比較

可以看出，越往後，阻塞越少，理論上效率也是最優。
=====================分割線==================================
5種模型的比較比較清晰了，剩下的就是把select,epoll,iocp,kqueue按號入座那就OK了。
select和iocp分別對應第3種與第5種模型，那麼epoll與kqueue呢？其實也於select屬於同一種模型，只是更高級一些，可以看作有了第4種模型的某些特性，如callback機制。
為什麼epoll,kqueue比select高級？
答案是，他們無輪詢。因為他們用callback取代了。想想看，當套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調度,不管哪個Socket是活躍的,都遍歷一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll與kqueue做的。
windows or *nix （IOCP or kqueue/epoll）？

誠然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系統，但是由於其系統本身的局限性，大型伺服器還是在UNIX下。而且正如上面所述，kqueue/epoll 與 IOCP相比，就是多了一層從內核數據到應用層的阻塞，從而不能算作asynchronous I/O類。但是，這層小小的阻塞無足輕重，kqueue與epoll已經做得很優秀了。
提供一致的介面，IO Design Patterns
實際上，不管是哪種模型，都可以抽象一層出來，提供一致的介面，廣為人知的有ACE,Libevent（基於reactor模式）這些，他們都是跨平台的，而且他們自動選擇最優的I/O復用機制，用戶只需調用介面即可。說到這里又得說說2個設計模式，Reactor and Proactor。見：Reactor模式--VS--Proactor模式。Libevent是Reactor模型，ACE提供Proactor模型。實際都是對各種I/O復用機制的封裝。
Java nio包是什麼I/O機制？
現在可以確定，目前的java本質是select()模型，可以檢查/jre/bin/nio.dll得知。至於java伺服器為什麼效率還不錯。。我也不得而知，可能是設計得比較好吧。。-_-。
=====================分割線==================================
總結一些重點：
只有IOCP是asynchronous I/O，其他機制或多或少都會有一點阻塞。
select低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善
epoll, kqueue、select是Reacor模式，IOCP是Proactor模式。
java nio包是select模型。。
（二）epoll 與select的區別

1. 使用多進程或者多線程，但是這種方法會造成程序的復雜，而且對與進程與線程的創建維護也需要很多的開銷。（Apache伺服器是用的子進程的方式，優點可以隔離用戶） （同步阻塞IO）

2.一種較好的方式為I/O多路轉接（I/O multiplexing）（貌似也翻譯多路復用），先構造一張有關描述符的列表（epoll中為隊列），然後調用一個函數，直到這些描述符中的一個准備好時才返回，返回時告訴進程哪些I/O就緒。select和epoll這兩個機制都是多路I/O機制的解決方案，select為POSIX標准中的，而epoll為Linux所特有的。

區別（epoll相對select優點）主要有三：
1.select的句柄數目受限，在linux/posix_types.h頭文件有這樣的聲明：#define __FD_SETSIZE 1024 表示select最多同時監聽1024個fd。而epoll沒有，它的限制是最大的打開文件句柄數目。

2.epoll的最大好處是不會隨著FD的數目增長而降低效率，在selec中採用輪詢處理，其中的數據結構類似一個數組的數據結構，而epoll是維護一個隊列，直接看隊列是不是空就可以了。epoll只會對"活躍"的socket進行操作---這是因為在內核實現中epoll是根據每個fd上面的callback函數實現的。那麼，只有"活躍"的socket才會主動的去調用 callback函數（把這個句柄加入隊列），其他idle狀態句柄則不會，在這點上，epoll實現了一個"偽"AIO。但是如果絕大部分的I/O都是「活躍的」，每個I/O埠使用率很高的話，epoll效率不一定比select高（可能是要維護隊列復雜）。

3.使用mmap加速內核與用戶空間的消息傳遞。無論是select,poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝就很重要，在這點上，epoll是通過內核於用戶空間mmap同一塊內存實現的。

關於epoll工作模式ET，LT

epoll有兩種工作方式
ET：Edge Triggered，邊緣觸發。僅當狀態發生變化時才會通知，epoll_wait返回。換句話，就是對於一個事件，只通知一次。且只支持非阻塞的socket。
LT：Level Triggered，電平觸發（默認工作方式）。類似select/poll,只要還有沒有處理的事件就會一直通知，以LT方式調用epoll介面的時候，它就相當於一個速度比較快的poll.支持阻塞和不阻塞的socket。

三 Linux並發網路編程模型

1 Apache 模型，簡稱 PPC （ Process Per Connection ，）:為每個連接分配一個進程。主機分配給每個連接的時間和空間上代價較大，並且隨著連接的增多，大量進程間切換開銷也增長了。很難應對大量的客戶並發連接。
2 TPC 模型（ Thread Per Connection ）：每個連接一個線程。和PCC類似。
3 select 模型：I/O多路復用技術。
.1 每個連接對應一個描述。select模型受限於 FD_SETSIZE即進程最大打開的描述符數linux2.6.35為1024,實際上linux每個進程所能打開描數字的個數僅受限於內存大小，然而在設計select的系統調用時，卻是參考FD_SETSIZE的值。可通過重新編譯內核更改此值，但不能根治此問題，對於百萬級的用戶連接請求 即便增加相應 進程數， 仍顯得杯水車薪呀。
.2select每次都會掃描一個文件描述符的集合，這個集合的大小是作為select第一個參數傳入的值。但是每個進程所能打開文件描述符若是增加了 ，掃描的效率也將減小。
.3內核到用戶空間，採用內存復制傳遞文件描述上發生的信息。
4 poll 模型：I/O多路復用技術。poll模型將不會受限於FD_SETSIZE，因為內核所掃描的文件 描述符集合的大小是由用戶指定的，即poll的第二個參數。但仍有掃描效率和內存拷貝問題。
5 pselect模型：I/O多路復用技術。同select。
6 epoll模型：
.1)無文件描述字大小限制僅與內存大小相關
.2)epoll返回時已經明確的知道哪個socket fd發生了什麼事件，不用像select那樣再一個個比對。
.3)內核到用戶空間採用共享內存方式，傳遞消息。
四 ：FAQ
1、單個epoll並不能解決所有問題，特別是你的每個操作都比較費時的時候，因為epoll是串列處理的。 所以你有還是必要建立線程池來發揮更大的效能。
2、如果fd被注冊到兩個epoll中時，如果有時間發生則兩個epoll都會觸發事件。
3、如果注冊到epoll中的fd被關閉，則其會自動被清除出epoll監聽列表。
4、如果多個事件同時觸發epoll，則多個事件會被聯合在一起返回。
5、epoll_wait會一直監聽epollhup事件發生，所以其不需要添加到events中。
6、為了避免大數據量io時，et模式下只處理一個fd,其他fd被餓死的情況發生。linux建議可以在fd聯繫到的結構中增加ready位，然後epoll_wait觸發事件之後僅將其置位為ready模式，然後在下邊輪詢ready fd列表。

❽ CPU設置怎麼設置最好，調節器，IO調度器

按需調節cpu頻率,不操作手機的時候控制在最低頻率,滑屏或進入應用後會迅速提升至最高頻率,當空閑時迅速降低頻率,性能較穩定,但因頻率變化幅度過大,省電方面只有一般的水平。
是一種在電池和性能之間趨向平衡的默認模式,但是對於智能手機來說,ondemand在性能表現方面略有欠缺。

❾ 安卓io調度器，哪個模式最好。

第二和第四第二個好一點速度更快，第四個系統默認好像是！