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:48]
soc:2010:cooldavid:project_plan:start [2010/07/20 00:03] (current)
Line 9: Line 9:
 ==== Outline ==== ==== Outline ====
-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). ​If any packet ​was dropped ​+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 21: 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 43: 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)