Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
soc:2010:cooldavid:project_plan:start [2010/05/28 05:48] cooldavid |
soc:2010:cooldavid:project_plan:start [2010/07/20 00:03] (current) cooldavid |
||
---|---|---|---|
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 list, having 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. | ||