Apply the qemu-slirp-performance.patch from Kenneth Duda available here:

<http://lists.nongnu.org/archive/html/qemu-devel/2006-04/msg00245.html>

This does improve slirp performance a lot, especially in FTP passive mode
transfers. i.e. now, they are equally as fast as non passive mode. I get
approx. 800 KB/sec in B2 and 500 KB/sec in SheepShaver (over a DSL line).
In native env, the max download data rate from my ISP is around 950 KB/sec.
This commit is contained in:
gbeauche 2006-04-13 22:15:02 +00:00
parent 0222915bc4
commit 5f3874c853
2 changed files with 7 additions and 22 deletions

View File

@ -108,8 +108,10 @@ struct tcphdr {
* With an IP MSS of 576, this is 536,
* but 512 is probably more convenient.
* This should be defined as MIN(512, IP_MSS - sizeof (struct tcpiphdr)).
*
* We make this 1460 because we only care about Ethernet in the qemu context.
*/
#define TCP_MSS 512
#define TCP_MSS 1460
#define TCP_MAXWIN 65535 /* largest value for (unscaled) window */

View File

@ -580,28 +580,11 @@ findso:
* congestion avoidance sender won't send more until
* he gets an ACK.
*
* Here are 3 interpretations of what should happen.
* The best (for me) is to delay-ack everything except
* if it's a one-byte packet containing an ESC
* (this means it's an arrow key (or similar) sent using
* Nagel, hence there will be no echo)
* The first of these is the original, the second is the
* middle ground between the other 2
* It is better to not delay acks at all to maximize
* TCP throughput. See RFC 2581.
*/
/* if (((unsigned)ti->ti_len < tp->t_maxseg)) {
*/
/* if (((unsigned)ti->ti_len < tp->t_maxseg &&
* (so->so_iptos & IPTOS_LOWDELAY) == 0) ||
* ((so->so_iptos & IPTOS_LOWDELAY) &&
* ((struct tcpiphdr_2 *)ti)->first_char == (char)27)) {
*/
if ((unsigned)ti->ti_len == 1 &&
((struct tcpiphdr_2 *)ti)->first_char == (char)27) {
tp->t_flags |= TF_ACKNOW;
tcp_output(tp);
} else {
tp->t_flags |= TF_DELACK;
}
tp->t_flags |= TF_ACKNOW;
tcp_output(tp);
return;
}
} /* header prediction */