頻寬與時延
傳統上，用於比較網絡性能的指標是頻寬。高頻寬就表示高性能。因此， DSL線路顯然優於數據機；二
然而，新的套用層出不窮，網路遊戲、基於IP的語音業務（VoIP）以及其他業務，不僅需要約100 kbps頻寬來上行傳輸大量業務，而且對時延極為敏感。
時延是數據包在兩個通信設備之間進行傳輸所需要的時間。時延越高就意味著這兩台設備交換信息所需要的時間越長。在參與網路遊戲時，玩家狀態瞬息萬變，如果時延太長，玩家可能會不知不覺死於非命。
理想的情況是，時延敏感型套用可以優先享用系統提供的網路接口。
問題
不知道時延敏感型套用的存在
一台標準PC的網路硬體和驅動程式（以及作業系統）並不知道時延的存在，也不能縮短時延。所有套用都通過完全相同的接口傳送和接收數據，不論是像FTP和網路瀏覽器這樣可以忍受時延的套用，還是諸如Skype和gizmo等VoIP套用，或者任何基於即時訊息（IM）的VoIP套用（如Google talk、Yahoo! Instant Messenger和MSN Messenger等即時訊息）。
不可能通過更新作業系統（OS）的套用協定接口（API）來實現通過每個插槽的相關參數，影回響用的時延。即使可以通過更新作業系統，提供此類API，套用開發商也必須更改套用代碼，以便利用這種新的或修改後的API，並且這些套用只能在新的作業系統下，才能實現最優性能。幸運的是，只要在網路驅動程式中添加一些智慧型功能，就可以明顯改善這種狀況，而不必勞神修改作業系統和套用。
在發射端（發射機，上行傳輸），可以改變PC處理業務的流程。但是，在接收端（接收器，下行傳輸），卻不能控制收到的業務，因為當數據包一次一個地傳到接收端時，PC必須接收這些數據包。同樣地，網路交換機和路由器可能發生丟包或者重新安排業務順序，並影回響用的性能，不管這些套用是不是時延敏感型。
傳輸大量數據加劇時延
關鍵在於，大多數時延敏感型套用傳送的數據包都非常小，而系統活動程度卻不盡相同：
在一個基本上處於空閒狀態的系統中，也就是說，系統當前只運行了少量套用甚或沒有運行其他網路套用，那么，系統將以最短的排隊延遲，在這些時延敏感型小型數據包準備就緒後，立即傳送。
如果系統同時還在運行其他套用，則只能按先來先出的順序，傳送時延敏感型數據包。更糟糕的是，兩個單獨數據包遭遇的時延可能大相逕庭。這是因為有的套用（如檔案傳輸和檔案共享）傾向於在傳出的數據包中包含儘可能多的數據，而這些數據包需要等待相對比較長的時間才能通過輸出連線埠，這會干擾系統傳送小型的時延敏感型數據包的處理能力。
傳輸時延的可變性被稱為“抖動”，對接收系統而言，數據包到達的時間極不穩定，變化劇烈，其原因不是網路傳輸能力，而是在數據包從PC連線埠傳出之前就形成的延遲！
為了更直觀地理解數據包可能導致的延遲，不妨考慮，一個最小的乙太網幀為64位元組，並且每個幀需要約20位元組定時開銷。在千兆比特乙太網速度下，每毫微秒傳送一個位，傳送一個幀就需要8×（64+20） = 672 毫微秒，即，三分之二微秒多一點。在另一個極端情況下，即最大的乙太網幀需要8×（1518+20）= 12,304毫微秒，是傳輸最小幀所需時間的18倍以上！
因此，僅傳送少量大型幀的套用會導致時延敏感型套用遭受相當長的時延。在一個單傳輸佇列系統中，一旦一個幀進入了傳輸佇列，就無法重新進行排序，以便優先傳輸小型幀。
解決方案
FirstPacket技術
傾向於傳送最大幀的套用也更能容忍網路傳輸時延。FirstPacket技術利用了這種耐受力，以優先傳輸時延敏感型業務。圖1演示了在一個典型的系統中，處於同一個傳輸佇列中的FTP數據包可能影響遊戲數據包的傳輸速率。
簡而言之，FirstPacket技術在乙太網驅動程式中創建了一個雙傳輸佇列系統，其中一個佇列為“快速通道”，而另一個佇列為“慢速通道”，用戶指定的套用發出的小型幀將通過快速通道進行傳輸。
根據用戶設定，可以僅通過快速通道傳輸某些套用的業務。慢速通道將儘快傳出佇列中的業務，以免連線逾時，不過其速度不會快到影響快速通道中的業務傳輸。不能簡單地將快速通道理解為“小型數據包專用通道”，因為並非所有傳送小型數據包的套用都是時延敏感型。即使對於時延敏感型套用，用戶也可以選擇只讓其中一部分套用實現更高性能，而讓其餘套用在慢速通道中各自打拚出路。
請記住，FirstPacket技術實現的快速通道並非具備更高頻寬，而是一個“有限時延通道”。PC不可能提高上行通道的傳輸速率——用戶的網際網路寬頻接口的上行頻寬是一個幾乎靜態的特性。不論用戶使用的是DSL線路還是電纜數據機，上行頻寬最高不過幾百kbps。網路驅動程式唯一能做的就是確保儘快將數據包傳出至上行通道。歸根結底，要靠用戶避免向系統傳送混雜的訊息；要想優先傳輸時延敏感型套用業務，用戶就不應同時傳送大量時延容限型業務。
優越性
業務管理
藉助FirstPacket技術，用戶可以通過一種新的方法來管理PC套用業務，更加有效地同時運行時延敏感型套用和時延容限型套用，並且使兩種類型套用的性能都達到可接受的程度。實際上，在需要處理多套用業務的系統中，如果不採用FirstPacket技術，時延敏感型套用的性能可能完全不可接受。
解決性能問題
FirstPacket技術的工作方式是在網路驅動程式中創建另一個傳輸佇列。這個傳輸佇列主要用於傳輸用戶指定的套用，一般而言，應該是時延敏感型套用（雖然用戶可以自由選擇任何套用）。
通過允許這些套用優先進入上行通道（雖然不一定保證優先傳輸，但抖動情況會明顯低於單傳輸佇列的系統），套用性能也將大幅提升。有了FirstPacket技術，過去無法參加的遊戲，現在可以盡情享受；VoIP通話也不會因為本地PC處理其他業務而掉線。（不能保證PC傳出業務之後，網路處理業務的性能！）
提升套用性能
FirstPacket技術有助於提升任何傾向於傳送小型數據包，並且要求有限端到端時延的套用的性能。任何網路遊戲，以及基於IP的語音業務、基於IP的視頻業務和任何互動式套用（網路會議，如WebEx）都能獲益良多。
FirstPacket技術的工作原理是，迫使時延容限型套用等待更長的傳送時間，從而加速傳輸時延敏感型套用業務。這是一種有益的折衷，因為用戶已經表明了他們更願意優先傳輸時延敏感型套用，而讓其餘的套用排隊等待。
性能
衡量FirstPacket技術有效性的方法之一就是測量在參與遊戲時，PC通過網路與遊戲伺服器進行“ping”的時間。為此，NVIDIA執行了一項測試。首先，在沒有任何其他網路業務的情況下，測量了遊戲的ping時間；再在通過FTP下載大型檔案的同時，測量了遊戲的ping時間；然後，再在啟用FirstPacket技術的情況下，測量了遊戲的ping時間。圖3顯示了測量結果。結果表明，取決於同時傳輸的其他業務的總量，FirstPacket技術最多可將網際網路遊戲的ping時間縮短50%。此外，同時傳輸的業務量越高，FirstPacket技術實現的時延縮短越顯著。
結束語
NVIDIA FirstPacket技術可以有效地為時延敏感型套用優先提供有限資源——上行頻寬，用戶指定的優先套用甚至感覺不到其他時延容限型套用的存在。同樣地，時延容限型套用也只會注意到自己已經被歸入“慢速”通道。
藉助FirstPacket技術，用戶可以更加靈活地利用計算機資源，順利地同時執行多項任務。
