5 Jul 2005 11:55
Re: MAXSAVEDBLOCKS in netinet/tcp_sack.c
Noritoshi Demizu <demizu <at> dd.iij4u.or.jp>
2005-07-05 09:55:27 GMT
2005-07-05 09:55:27 GMT
> In anycase, RED or fair-queueing tend to do a much better job > reducing the number of fragmented ranges. SACK running through a > RED router (which is most of the routers on the internet) is a good > combination. Thanks. If my purpose is to transfer data as fast as possible, it would be a good solution. But what I want to do now is to observe TCP behaviors in the slow start phase after retransmission timeouts. So, I think my environment is quite goodfor me. > If you have a lot of outgoing bandwidth and the servers are running > FreeBSD or DragonFly, you can turn on the inflight bandwidth limiting > sysctl (net.inet.tcp.inflight_enable). This only works on the machines > doing the actual initiation of the packets, it won't work on the > routers. It does a fairly good job reducing queue lengths. Sorry, actually, I always set net.inet.tcp.inflight_enable to zero both on DragonFlyBSD and FreeBSD in my experiences (I know it is zero on DragonFlyBSD by default, but I want to make it sure), because unfortunately it reduces throughput in my experiences in an unexpected way. Regards, Noritoshi Demizu
for me.
> If you have a lot of outgoing bandwidth and the servers are running
> FreeBSD or DragonFly, you can turn on the inflight bandwidth limiting
> sysctl (net.inet.tcp.inflight_enable). This only works on the machines
> doing the actual initiation of the packets, it won't work on the
> routers. It does a fairly good job reducing queue lengths.
Sorry, actually, I always set net.inet.tcp.inflight_enable to zero
both on DragonFlyBSD and FreeBSD in my experiences (I know it is zero
on DragonFlyBSD by default, but I want to make it sure), because
unfortunately it reduces throughput in my experiences in an unexpected
way.
Regards,
Noritoshi Demizu
RSS Feed