Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:2010:cooldavid:project_plan:start [2010/05/28 05:39]
cooldavid
soc:2010:cooldavid:project_plan:start [2010/07/20 00:03] (current)
cooldavid
Line 5: Line 5:
 ==== Summary ==== ==== Summary ====
 In order to obtain better performance from JMicron Ethernet Card. Instead of using the UNDI driver, I would implement a better performance native driver for gPXE. The tg3 driver of gPXE project still using old etherboot API, I would buy a Broadcom NIC and try to port it into new gPXE API. In order to obtain better performance from JMicron Ethernet Card. Instead of using the UNDI driver, I would implement a better performance native driver for gPXE. The tg3 driver of gPXE project still using old etherboot API, I would buy a Broadcom NIC and try to port it into new gPXE API.
 +
 +Implement TCP receive queue to handle out-of-order packets, and SACK, window scaleing support. To have better performance on high latency network(WAN),​ or unstable networks(Wireless).
 +
 +==== Outline ====
 +Most of work for porting driver is to understand what original
 +driver does, and remove all un-need code from the Linux driver.
 +The JMicron driver should be much more easy for me since I've
 +already written the Linux driver. But the broadcom tg3 driver
 +might take me more time since I have to guess lots of things due
 +to lack of chip spec.
 +
 +Current gPXE limited the TCP window size at 4KB. Which makes sence
 +when the TCP stack dose not handle out-of-order packets, in order
 +to prevent large amount of useless packets on slow and unstable
 +network(Such as wireless). That is
 +  * The packet is dropped often.
 +  * The bandwidth is narrow.
 +  * The receiver
 +    * Dose not queue non-contigious packets
 +    * Advertived a large window.
 +  * Any packet dropped:
 +    * Sender have no idea about it.
 +    * Send all remaining data to receiver until window is filled.
 +    * Consume more bandwith in narrow bandwith, but useless.
 +    * Makes the network worse.
 +
 +But with receive queue and SACK implement, ideally the sender don't
 +have to send any data that was received by the receiver. It would be
 +much more better for above senariol with larger window size.
 +
 +For [[http://​en.wikipedia.org/​wiki/​Bandwidth-delay_product|long fat network]]
 +the window size is important also. In order to have large enough window size,
 +we need [[http://​tools.ietf.org/​html/​rfc1323#​page-8|window scale option]] to
 +breake the 64K window size limit.
 +
 +But the original gPXE's heap was fixed at 128K due to A20 limit, and
 +have to perserve the space for codes. We recently found that the
 +all-driver image has almost reached the 1MB limit. This should be the
 +issue we solve first.
 +
 +After solving the heap memory limit, I'll have some benchmark to see
 +what's the reasonable MAX TCP WINDOW SIZE, and advertice a reasonale
 +window size.
  
 ==== Milestones and Timeline ==== ==== Milestones and Timeline ====
Line 16: Line 59:
   * [[soc:​2010:​cooldavid:​journal:​week0|Week 0: TCP performance test and tunning]]   * [[soc:​2010:​cooldavid:​journal:​week0|Week 0: TCP performance test and tunning]]
   * [[soc:​2010:​cooldavid:​journal:​week1|Week 1: Update wiki, TCP tunning]]   * [[soc:​2010:​cooldavid:​journal:​week1|Week 1: Update wiki, TCP tunning]]
-  * [[soc:​2010:​cooldavid:​journal:​week2|Week 2: Discussing TCP and memory ​changes]] +  * [[soc:​2010:​cooldavid:​journal:​week2|Week 2: Update jme driver, Trace memory ​related codes]] 
-  * Week 3-6+  * [[soc:​2010:​cooldavid:​journal:​week3|Week 3: Trace memory related codes, misc things]] 
-    Have a solution ​for bigger heap size+  Week 4-7: Studying ​for PhD qualify exam. 
-    * Fine tune window size, heap size+  * [[soc:​2010:​cooldavid:​journal:​week8|Week 8]]: 
-    * Clean-up ​TCP receivw ​queue/​SACK/​Window scale patches. +    * Several TCP fixes 
-    * Submit it on gPXE-devel, and discuss it.+  * [[soc:​2010:​cooldavid:​journal:​week9|Week 9]]: 
 +    * TCP cleanup 
 +    * Trace gPXE boot initialize steps about memory environment setup. 
 +  * [[soc:​2010:​cooldavid:​journal:​week10|Week 10]]: 
 +    * Cleanup ​TCP receive ​queue/​SACK/​Window scale patches 
 +    * Submit it on the listhaving some test and feedback. 
 +  * [[soc:​2010:​cooldavid:​journal:​week11|Week 11]]: 
 +    * Testing TCP performance with different window size, network environment. 
 +    * Discuss the testing results and find a reasonable size. 
 +  * [[soc:​2010:​cooldavid:​journal:​week12|Week 12]]: 
 +    * Possible more TCP cleanup, tuning. 
 +    * gPXE scheduling and program flow documentation.
  
-=== Broadcom tg3 driver ​=== +=== After GSoC period ​=== 
-  * Week 7:\\ +  * Help on porting ​tg3 driver.
-    * Trace tg3 driver ​of both Linux and gPXE. +
-  * Week 8-10:\\ +
-    * Port latest tg3 driver from Linux to gPXE. +
-  * Week 11-12:\\ +
-    * Testing and Debuging.+
  
 ==== Extra stuff from original plan ==== ==== Extra stuff from original plan ====
Line 38: Line 87:
   * TCP PAWS(Protect Against Wrapped Sequence Nunbers) [RFC 1323]   * TCP PAWS(Protect Against Wrapped Sequence Nunbers) [RFC 1323]
   * Possible tunning TCP/HTTP xfer interface.   * Possible tunning TCP/HTTP xfer interface.
 +
 +==== Postponed stuff from original plan ====
 +  * tg3 driver for gPXE.
  

QR Code
QR Code soc:2010:cooldavid:project_plan:start (generated for current page)