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:39] cooldavid |
soc:2010:cooldavid:project_plan:start [2010/07/20 00:03] 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 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 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. | ||
