set_dcc_sliding_window
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
| — | set_dcc_sliding_window [2006/08/29 16:08] (current) – created - external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ======Synopsis: | ||
| + | [[set]] dcc_sliding_window [< | ||
| + | |||
| + | ======Description: | ||
| + | The [[DCC]] specification requires that data cannot be sent via a | ||
| + | [[DCC SEND]] connection until all previous data have been acknowledged | ||
| + | by the receiver. | ||
| + | (ie, anything faster than 28.8k), this can have serious consequences | ||
| + | on throughput because at least half of the time the connection is idle | ||
| + | waiting for an acknowledgement to be returned. | ||
| + | to the [[DCC]] specification requires that this value be set to 1 (and it is, | ||
| + | as the default), there are no technical impediments to sending more than | ||
| + | one packet of data at a time, and real world experience bears this out. | ||
| + | |||
| + | Significant gains in throughput can be achieved by setting this value to | ||
| + | two (2). Values of 3 or more get modest gains compared to the next lower | ||
| + | value. | ||
| + | never send a packet of data if sending that packet will block. | ||
| + | setting this value to an absurdly high value (such as 1,000) will yield | ||
| + | optimal throughput. | ||
set_dcc_sliding_window.txt · Last modified: 2006/08/29 16:08 by 127.0.0.1
