Difference between revisions of "Cluster:LowLatency"
Jump to navigation
Jump to search
| Line 1: | Line 1: | ||
| + | ==Internal Links== | ||
| + | * [[Cluster:LLK_Poster_Structure|Poster Structure]] | ||
| + | * [[llk-packet-diagram|Packet Diagram]] | ||
| + | * [[Running Timer Code]] | ||
| + | * [[llk QA]] | ||
| + | |||
==Plan (updated August 28, 2005)== | ==Plan (updated August 28, 2005)== | ||
* Decide on two benchmarks, one micro (low-level) and one application, probably MD with GROMACS in a form that's latency bound on bazaar & Cairo. Set these up on bazaar and Cairo and start tests. | * Decide on two benchmarks, one micro (low-level) and one application, probably MD with GROMACS in a form that's latency bound on bazaar & Cairo. Set these up on bazaar and Cairo and start tests. | ||
| Line 7: | Line 13: | ||
* Show that latency is in the network stack, either by reference or by test (preferrably the former since it will take less time). | * Show that latency is in the network stack, either by reference or by test (preferrably the former since it will take less time). | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Notes== | ==Notes== | ||
Revision as of 12:28, 28 January 2006
Internal Links
Plan (updated August 28, 2005)
- Decide on two benchmarks, one micro (low-level) and one application, probably MD with GROMACS in a form that's latency bound on bazaar & Cairo. Set these up on bazaar and Cairo and start tests.
- Formal literature search and preliminary review.
- Test tcp_low_latency - does it work? If so, what does it do _exactly_
- Show that latency is in the network stack, either by reference or by test (preferrably the former since it will take less time).
Notes
- BibTeX references are in /cluster/project/llk/llk.bib
- Comparisons & Instrumentation
- Comparison of time between layers in network stack. Patch only for 2.6.9.
- Comparing while varying link delay times
- http://developer.osdl.org/shemminger/LK2004_TCP.pdf
- http://developer.osdl.org/shemminger/LWE2005_TCP.pdf
- Reno - Linux 2.4
- Westwood - Wireless
- Vegas
- Binary Increase Congestion Control (BIC) - Default for Linux 2.6
- Comparing while varying link delay times
- Lots of discussion
- http://www.ggf.org/Public_Comment_Docs/Documents/May-2005/draft-ggf-dtrg-survey-1.pdf
- HS-TCP
- Scalable TCP
- FAST TCP
- BIC & CUBIC
- Westwood
- .....
- Lots of discussion
- Misc
- Dynamic Right Sizing (DRS)
- Window Scaling RFC
- Modifying buffer sizes manually
- Kernel options
- Default Linux TCP/IP options field contains:
- Maximum Segment Size(MSS) http://rfc.activedomain.org/0500-0999/rfc0879.html
- Selective Acknowledgement(Sack) ftp://ftp.isi.edu/in-notes/rfc2018.txt
- Timestamping http://www.faqs.org/rfcs/rfc1323.html
- opensolaris code
- Low Latency Kernel Option
- net.ipv4.tcp_low_latency sysctl
- /proc/sys/net/ipv4/tcp_low_latency
- From /usr/src/linux/Documentation/networking/ip-sysctl.txt
- net.ipv4.tcp_low_latency sysctl
tcp_low_latency - BOOLEAN
If set, the TCP stack makes decisions that prefer lower
latency as opposed to higher throughput. By default, this
option is not set meaning that higher throughput is preferred.
An example of an application where this default should be
changed would be a Beowulf compute cluster.
Default: 0
Ideas
- Reduce error checking to improve performance
- Reduce number of memory copies, maybe by not being fully TCP/IP-compliant?
- Look into STP (scheduled transfer protocol)
- Check out the TCP_NODELAY sockopt:
if(setsockopt(sockfd, proto->p_proto, TCP_NODELAY, &one, sizeof(one)) < 0)
{
printf("NetPIPE: setsockopt: TCP_NODELAY failed! errno=%d\n", errno);
exit(556);
}
http://www.openldap.org/lists/openldap-devel/199907/msg00079.html
