TCP control block interdependence

Anyone who knows how to enable/disable control block interdependence in
linux? I was doing some experiments to see the effects of delay spikes
(upto 10sec) on TCP, and it seems if I run two downloads sequentially,
the first one will get all the timeouts I expect, but the second one
seem to be retransmission free, eventhough the delay I applied was like
10 sec...but if I run the two tests few minutes apart, both tests will
suffer a similar number of retransmissions...so I assume some kind of
tcp control block interdependence is at work...I tried to google for
information, and in one paper entitled "Congestion Control in Linux TCP"
by Pari Sarolahti, they mention in one sentence "Finally, the Linux
destination cache
provides functionality similar to the RFC 2140 that proposes
Control Block Interdependence between the TCP
connections." what is the "Linux destination Cache"?....I googled for a
while and I found some site
...http://www.cs.helsinki.fi/research/i...o-20020419.txt
where they claim to have a patch that will make it possible to control
the interdependence setting..but I am using some servers at the
university, and I dont think the admins will be willing to install
patches that are not stable....

Oumer Teyeb wrote:
> Anyone who knows how to enable/disable control block interdependence in
> linux? I was doing some experiments to see the effects of delay spikes
> (upto 10sec) on TCP, and it seems if I run two downloads sequentially,
> the first one will get all the timeouts I expect, but the second one
> seem to be retransmission free, eventhough the delay I applied was like
> 10 sec...but if I run the two tests few minutes apart, both tests will
> suffer a similar number of retransmissions...so I assume some kind of
> tcp control block interdependence is at work...I tried to google for
> information, and in one paper entitled "Congestion Control in Linux TCP"
> by Pari Sarolahti, they mention in one sentence "Finally, the Linux
> destination cache
> provides functionality similar to the RFC 2140 that proposes
> Control Block Interdependence between the TCP
> connections." what is the "Linux destination Cache"?....I googled for a
> while and I found some site
> ..http://www.cs.helsinki.fi/research/i...o-20020419.txt
> where they claim to have a patch that will make it possible to control
> the interdependence setting..but I am using some servers at the
> university, and I dont think the admins will be willing to install
> patches that are not stable....

It's not clear from your several posts just what sorts of problems you
are addressing. The tone suggests that you need better, more
consistent network performance.

End station tuning may help more or less help depending on the
circumstances. In larger networks this tuning usually reveals network
bottlenecks that must be addressed in the switches/routers and the
pathway layout.

Re: Linux tuning, you have to be aware of the changes in the kernel's
network stack during 2.6.X development. Old 2.4.X tricks are often
pointless ;-)

Here is a link list I posted a while back that may provide some useful
background and tuning tips:

TCP Variables
http://ipsysctl-tutorial.frozentux.net/

TCP Perf Links
http://www.psc.edu/networking/projects/tcptune/
http://www-didc.lbl.gov/TCP-tuning/TCP-tuning.html
http://www-didc.lbl.gov/TCP-tuning/linux.html
http://www.uninett.no/tcpperf/
http://www.infosyssec.net/infosyssec/netprot1.htm
http://ltp.sourceforge.net/tooltable.php
http://www.csm.ornl.gov/~dunigan/netperf/netlinks.html
http://www.web100.org/

Kernel Netwoking Notes: (as far back as 7/8/04)
NAPI performance
http://lwn.net/Articles/139208/
Pluggable congestion avoidance modules
http://lwn.net/Articles/128062/
TCP window scaling and broken routers
http://lwn.net/Articles/91976/

hth,
prg

Thanks for the fast response.
but I am aware of most of hte links you sent me and I thought my
question was clear. I will try again...

in RFC 2140, control block interdependence was proposed, that is
basically using the history of a tcp connection with a given host to set
initial tcp paramters. for example, if you have made a connection with
host A and it is shown that the average RTT is really big, next time you
start a TCP connection with host A, the RTO mayb be set to a larger
value instead of the usual 3sec, to make sure that unecessary timeouts
do not occur...

and in the Linux congestion control paper I mentioned they say that such
a functionality is somehow implemented but they dont say exactly
how...and I did some simpler experiments and it seems tehre is some kind
of dependancy but not sure what it is...and for the tests I am doing I
dont want any dependancy at all, because I am testing several other
things (not only TCP; but I have my own link layer protocol plugin which
I am tuning too), and the results will be biased if there is some
dependancy, so I want to disable it....
Hope my question is clear now...

> Oumer Teyeb wrote:
>
>>Anyone who knows how to enable/disable control block interdependence in
>>linux? I was doing some experiments to see the effects of delay spikes
>>(upto 10sec) on TCP, and it seems if I run two downloads sequentially,
>>the first one will get all the timeouts I expect, but the second one
>>seem to be retransmission free, eventhough the delay I applied was like
>>10 sec...but if I run the two tests few minutes apart, both tests will
>>suffer a similar number of retransmissions...so I assume some kind of
>>tcp control block interdependence is at work...I tried to google for
>>information, and in one paper entitled "Congestion Control in Linux TCP"
>>by Pari Sarolahti, they mention in one sentence "Finally, the Linux
>>destination cache
>>provides functionality similar to the RFC 2140 that proposes
>>Control Block Interdependence between the TCP
>>connections." what is the "Linux destination Cache"?....I googled for a
>>while and I found some site
>>..http://www.cs.helsinki.fi/research/i...o-20020419.txt
>>where they claim to have a patch that will make it possible to control
>>the interdependence setting..but I am using some servers at the
>>university, and I dont think the admins will be willing to install
>>patches that are not stable....
>
>
> It's not clear from your several posts just what sorts of problems you
> are addressing. The tone suggests that you need better, more
> consistent network performance.
>
> End station tuning may help more or less help depending on the
> circumstances. In larger networks this tuning usually reveals network
> bottlenecks that must be addressed in the switches/routers and the
> pathway layout.
>
> Re: Linux tuning, you have to be aware of the changes in the kernel's
> network stack during 2.6.X development. Old 2.4.X tricks are often
> pointless ;-)
>
> Here is a link list I posted a while back that may provide some useful
> background and tuning tips:
>
> TCP Variables
> http://ipsysctl-tutorial.frozentux.net/
>
> TCP Perf Links
> http://www.psc.edu/networking/projects/tcptune/
> http://www-didc.lbl.gov/TCP-tuning/TCP-tuning.html
> http://www-didc.lbl.gov/TCP-tuning/linux.html
> http://www.uninett.no/tcpperf/
> http://www.infosyssec.net/infosyssec/netprot1.htm
> http://ltp.sourceforge.net/tooltable.php
> http://www.csm.ornl.gov/~dunigan/netperf/netlinks.html
> http://www.web100.org/
>
> Kernel Netwoking Notes: (as far back as 7/8/04)
> NAPI performance
> http://lwn.net/Articles/139208/
> Pluggable congestion avoidance modules
> http://lwn.net/Articles/128062/
> TCP window scaling and broken routers
> http://lwn.net/Articles/91976/
>
> hth,
> prg
>

I was checking some stuff related to this, here is what I did

I did a file download using FTP of a 100K file, using a 384kbps
connection...and I introduce a delay of 10 sec, 2 seconds after teh
download started..

case 1)
I did four downloads immediatley after each other

case 2)
I did four downloads but this time, I wait ten mintues before the next
download


results)
Case 1) I have a lot of retransmissions in the first one (because of the
10sec gap)..but the rest dont seem to suffer from retransmission at all,
even during the 10sec gap...the rtt values confirm it ..i,e. in the
first case, the rtt curve shows the RTT values are mostly below 1
sec..while in the next three downloads, the RTTs are sometimes more than
10sec....showing that the RTO value used for the three cases is
something different than the first one
curves can be found at :tsg=time sequence graph
http://kom.auc.dk/~oumer/case1_1_tsg.ps
http://kom.auc.dk/~oumer/case1_1_rtt.ps
http://kom.auc.dk/~oumer/case1_2_tsg.ps
http://kom.auc.dk/~oumer/case1_2_rtt.ps
http://kom.auc.dk/~oumer/case1_3_tsg.ps
http://kom.auc.dk/~oumer/case1_3_rtt.ps
http://kom.auc.dk/~oumer/case1_4_tsg.ps
http://kom.auc.dk/~oumer/case1_4_rtt.ps

Case 2) There is almost no different between the four downloads
http://kom.auc.dk/~oumer/case2_1_tsg.ps
http://kom.auc.dk/~oumer/case2_1_rtt.ps
http://kom.auc.dk/~oumer/case2_2_tsg.ps
http://kom.auc.dk/~oumer/case2_2_rtt.ps
http://kom.auc.dk/~oumer/case2_3_tsg.ps
http://kom.auc.dk/~oumer/case2_3_rtt.ps
http://kom.auc.dk/~oumer/case2_4_tsg.ps
http://kom.auc.dk/~oumer/case2_4_rtt.ps


From these I conclude that there is some TCP congestion control and
retransmission parameter caching, that is also time dependant....
and I want to disable it...

Oumer Teyeb wrote:
> Thanks for the fast response.

Just an accident of timing on my break :-)

> but I am aware of most of hte links you sent me and I thought my
> question was clear. I will try again...

Your "questions" have been fairly clear. MUCH more so than 99% we see
around here. But the _purpose_ of your questions remains foggy.

> in RFC 2140, control block interdependence was proposed, that is
> basically using the history of a tcp connection with a given host to set
> initial tcp paramters. for example, if you have made a connection with
> host A and it is shown that the average RTT is really big, next time you
> start a TCP connection with host A, the RTO mayb be set to a larger
> value instead of the usual 3sec, to make sure that unecessary timeouts
> do not occur...

These are portions of the stack code that have been under nearly
continuous change for years and are seeing even more changes with 2.6.X
kernels. It's all about _auto_ tuning that an admin will have little
if _any_ control over. Tough to implement but that is the goal.

> and in the Linux congestion control paper I mentioned they say that such
> a functionality is somehow implemented but they dont say exactly
> how...

Anything not written in the the past 1-2 years is probably out of date
re: specifics and probably re: architecture also. Makes it hard to pin
down any "background" or "how-to" papers. The mailing lists are
usually where you have to go unless you get lucky with google. Eg. the
early stages of this stuff re: "destination cache" goes back a ways:
http://www.cs-ipv6.lancs.ac.uk/ipv6/...6-12/0109.html

> and I did some simpler experiments and it seems tehre is some kind
> of dependancy but not sure what it is...and for the tests I am doing I
> dont want any dependancy at all, because I am testing several other
> things (not only TCP; but I have my own link layer protocol plugin which
> I am tuning too), and the results will be biased if there is some
> dependancy, so I want to disable it....
> Hope my question is clear now...

Ah hah! And clear enough to suggest that you probably should be
writing to the kernel mailing list. I stay out of the networking code
as much as possible :-) Mine is just an admin's and lab instructor's
interest.

The 3-4 people around here that are familiar with the networking code
have not posted much (or any?) in the past month or so -- at least I've
not seen them.

What you can or cannot readily disable will depend on which kernel you
are using I'm pretty sure and how ready you are to compile/configure
you own kernel. Many of these automagic tuning adjustments are being
built into the "normal" kernel code and are targeted for a robust,
stable IPv4/IPv6 stack that is complete and non-tunable (in the usual
sense). IIRC, I've read somewhere recently that Linus would be happy
to get rid of the sysctrl interface and make many of the /proc/net
variables read only as an ulimate goal.

If I understand your prediciment, you require _more_ control and ready
ability to turn on/off different feartures in the stack implementation.
It is likely my imagination, but I _think_ I ran into a project that
provides a kernel (or plug-in) with a pretty complete runtime
adjustable stack meant for testing purposes. Would something like that
interest you? If so, I can try to stumble across it again.

Beyond such legwork help, I'm not the one to provide kernel internals
help. If you're familiar with the links then you already know which
variables you can (probably) control that may be of help.

Oops, have to run.

good luck,
prg

> > Oumer Teyeb wrote:
> >
> >>Anyone who knows how to enable/disable control block interdependence in
> >>linux? I was doing some experiments to see the effects of delay spikes
> >>(upto 10sec) on TCP, and it seems if I run two downloads sequentially,
> >>the first one will get all the timeouts I expect, but the second one
> >>seem to be retransmission free, eventhough the delay I applied was like
> >>10 sec...but if I run the two tests few minutes apart, both tests will
> >>suffer a similar number of retransmissions...so I assume some kind of
> >>tcp control block interdependence is at work...I tried to google for
> >>information, and in one paper entitled "Congestion Control in Linux TCP"
> >>by Pari Sarolahti, they mention in one sentence "Finally, the Linux
> >>destination cache
> >>provides functionality similar to the RFC 2140 that proposes
> >>Control Block Interdependence between the TCP
> >>connections." what is the "Linux destination Cache"?....I googled for a
> >>while and I found some site
> >>..http://www.cs.helsinki.fi/research/i...o-20020419.txt
> >>where they claim to have a patch that will make it possible to control
> >>the interdependence setting..but I am using some servers at the
> >>university, and I dont think the admins will be willing to install
> >>patches that are not stable....
> >
> >
> > It's not clear from your several posts just what sorts of problems you
> > are addressing. The tone suggests that you need better, more
> > consistent network performance.
> >
> > End station tuning may help more or less help depending on the
> > circumstances. In larger networks this tuning usually reveals network
> > bottlenecks that must be addressed in the switches/routers and the
> > pathway layout.
> >
> > Re: Linux tuning, you have to be aware of the changes in the kernel's
> > network stack during 2.6.X development. Old 2.4.X tricks are often
> > pointless ;-)
> >
> > Here is a link list I posted a while back that may provide some useful
> > background and tuning tips:
> >
> > TCP Variables
> > http://ipsysctl-tutorial.frozentux.net/
> >
> > TCP Perf Links
> > http://www.psc.edu/networking/projects/tcptune/
> > http://www-didc.lbl.gov/TCP-tuning/TCP-tuning.html
> > http://www-didc.lbl.gov/TCP-tuning/linux.html
> > http://www.uninett.no/tcpperf/
> > http://www.infosyssec.net/infosyssec/netprot1.htm
> > http://ltp.sourceforge.net/tooltable.php
> > http://www.csm.ornl.gov/~dunigan/netperf/netlinks.html
> > http://www.web100.org/
> >
> > Kernel Netwoking Notes: (as far back as 7/8/04)
> > NAPI performance
> > http://lwn.net/Articles/139208/
> > Pluggable congestion avoidance modules
> > http://lwn.net/Articles/128062/
> > TCP window scaling and broken routers
> > http://lwn.net/Articles/91976/
> >
> > hth,
> > prg
> >

Thanks once again for the reply!
I have sent the mail to the kernel mailing list, and also to the guy who
wrote the Linux TCP congestion control paper...hope I will get something
out of them...but I have posted sample results illustrating the problem
....you can take a look at them if you have the time...
prg wrote:
> Oumer Teyeb wrote:
>
>>Thanks for the fast response.
>
>
> Just an accident of timing on my break :-)
>
>
>>but I am aware of most of hte links you sent me and I thought my
>>question was clear. I will try again...
>
>
> Your "questions" have been fairly clear. MUCH more so than 99% we see
> around here. But the _purpose_ of your questions remains foggy.
>
>
>>in RFC 2140, control block interdependence was proposed, that is
>>basically using the history of a tcp connection with a given host to set
>>initial tcp paramters. for example, if you have made a connection with
>>host A and it is shown that the average RTT is really big, next time you
>>start a TCP connection with host A, the RTO mayb be set to a larger
>>value instead of the usual 3sec, to make sure that unecessary timeouts
>>do not occur...
>
>
> These are portions of the stack code that have been under nearly
> continuous change for years and are seeing even more changes with 2.6.X
> kernels. It's all about _auto_ tuning that an admin will have little
> if _any_ control over. Tough to implement but that is the goal.
>
>
>>and in the Linux congestion control paper I mentioned they say that such
>>a functionality is somehow implemented but they dont say exactly
>>how...
>
>
> Anything not written in the the past 1-2 years is probably out of date
> re: specifics and probably re: architecture also. Makes it hard to pin
> down any "background" or "how-to" papers. The mailing lists are
> usually where you have to go unless you get lucky with google. Eg. the
> early stages of this stuff re: "destination cache" goes back a ways:
> http://www.cs-ipv6.lancs.ac.uk/ipv6/...6-12/0109.html
>
>
>>and I did some simpler experiments and it seems tehre is some kind
>>of dependancy but not sure what it is...and for the tests I am doing I
>>dont want any dependancy at all, because I am testing several other
>>things (not only TCP; but I have my own link layer protocol plugin which
>>I am tuning too), and the results will be biased if there is some
>>dependancy, so I want to disable it....
>>Hope my question is clear now...
>
>
> Ah hah! And clear enough to suggest that you probably should be
> writing to the kernel mailing list. I stay out of the networking code
> as much as possible :-) Mine is just an admin's and lab instructor's
> interest.
>
> The 3-4 people around here that are familiar with the networking code
> have not posted much (or any?) in the past month or so -- at least I've
> not seen them.
>
> What you can or cannot readily disable will depend on which kernel you
> are using I'm pretty sure and how ready you are to compile/configure
> you own kernel. Many of these automagic tuning adjustments are being
> built into the "normal" kernel code and are targeted for a robust,
> stable IPv4/IPv6 stack that is complete and non-tunable (in the usual
> sense). IIRC, I've read somewhere recently that Linus would be happy
> to get rid of the sysctrl interface and make many of the /proc/net
> variables read only as an ulimate goal.
>
> If I understand your prediciment, you require _more_ control and ready
> ability to turn on/off different feartures in the stack implementation.
> It is likely my imagination, but I _think_ I ran into a project that
> provides a kernel (or plug-in) with a pretty complete runtime
> adjustable stack meant for testing purposes. Would something like that
> interest you? If so, I can try to stumble across it again.
>
> Beyond such legwork help, I'm not the one to provide kernel internals
> help. If you're familiar with the links then you already know which
> variables you can (probably) control that may be of help.
>
> Oops, have to run.
>
> good luck,
> prg
>
>
>>>Oumer Teyeb wrote:
>>>
>>>
>>>>Anyone who knows how to enable/disable control block interdependence in
>>>>linux? I was doing some experiments to see the effects of delay spikes
>>>>(upto 10sec) on TCP, and it seems if I run two downloads sequentially,
>>>>the first one will get all the timeouts I expect, but the second one
>>>>seem to be retransmission free, eventhough the delay I applied was like
>>>>10 sec...but if I run the two tests few minutes apart, both tests will
>>>>suffer a similar number of retransmissions...so I assume some kind of
>>>>tcp control block interdependence is at work...I tried to google for
>>>>information, and in one paper entitled "Congestion Control in Linux TCP"
>>>>by Pari Sarolahti, they mention in one sentence "Finally, the Linux
>>>>destination cache
>>>>provides functionality similar to the RFC 2140 that proposes
>>>>Control Block Interdependence between the TCP
>>>>connections." what is the "Linux destination Cache"?....I googled for a
>>>>while and I found some site
>>>>..http://www.cs.helsinki.fi/research/i...o-20020419.txt
>>>>where they claim to have a patch that will make it possible to control
>>>>the interdependence setting..but I am using some servers at the
>>>>university, and I dont think the admins will be willing to install
>>>>patches that are not stable....
>>>
>>>
>>>It's not clear from your several posts just what sorts of problems you
>>>are addressing. The tone suggests that you need better, more
>>>consistent network performance.
>>>
>>>End station tuning may help more or less help depending on the
>>>circumstances. In larger networks this tuning usually reveals network
>>>bottlenecks that must be addressed in the switches/routers and the
>>>pathway layout.
>>>
>>>Re: Linux tuning, you have to be aware of the changes in the kernel's
>>>network stack during 2.6.X development. Old 2.4.X tricks are often
>>>pointless ;-)
>>>
>>>Here is a link list I posted a while back that may provide some useful
>>>background and tuning tips:
>>>
>>>TCP Variables
>>>http://ipsysctl-tutorial.frozentux.net/
>>>
>>>TCP Perf Links
>>>http://www.psc.edu/networking/projects/tcptune/
>>>http://www-didc.lbl.gov/TCP-tuning/TCP-tuning.html
>>>http://www-didc.lbl.gov/TCP-tuning/linux.html
>>>http://www.uninett.no/tcpperf/
>>>http://www.infosyssec.net/infosyssec/netprot1.htm
>>>http://ltp.sourceforge.net/tooltable.php
>>>http://www.csm.ornl.gov/~dunigan/netperf/netlinks.html
>>>http://www.web100.org/
>>>
>>>Kernel Netwoking Notes: (as far back as 7/8/04)
>>>NAPI performance
>>>http://lwn.net/Articles/139208/
>>>Pluggable congestion avoidance modules
>>>http://lwn.net/Articles/128062/
>>>TCP window scaling and broken routers
>>>http://lwn.net/Articles/91976/
>>>
>>>hth,
>>>prg
>>>
>
>

Thanks once again for the reply!
I have sent the mail to the kernel mailing list, and also to the guy who
wrote the Linux TCP congestion control paper...hope I will get something
out of them...but I have posted sample results illustrating the problem
....you can take a look at them if you have the time...
prg wrote:

> Oumer Teyeb wrote:
>
>>Thanks for the fast response.
>
>
> Just an accident of timing on my break :-)
>
>
>>but I am aware of most of hte links you sent me and I thought my
>>question was clear. I will try again...
>
>
> Your "questions" have been fairly clear. MUCH more so than 99% we see
> around here. But the _purpose_ of your questions remains foggy.
>
>
>>in RFC 2140, control block interdependence was proposed, that is
>>basically using the history of a tcp connection with a given host to set
>>initial tcp paramters. for example, if you have made a connection with
>>host A and it is shown that the average RTT is really big, next time you
>>start a TCP connection with host A, the RTO mayb be set to a larger
>>value instead of the usual 3sec, to make sure that unecessary timeouts
>>do not occur...
>
>
> These are portions of the stack code that have been under nearly
> continuous change for years and are seeing even more changes with 2.6.X
> kernels. It's all about _auto_ tuning that an admin will have little
> if _any_ control over. Tough to implement but that is the goal.
>
>
>>and in the Linux congestion control paper I mentioned they say that such
>>a functionality is somehow implemented but they dont say exactly
>>how...
>
>
> Anything not written in the the past 1-2 years is probably out of date
> re: specifics and probably re: architecture also. Makes it hard to pin
> down any "background" or "how-to" papers. The mailing lists are
> usually where you have to go unless you get lucky with google. Eg. the
> early stages of this stuff re: "destination cache" goes back a ways:
> http://www.cs-ipv6.lancs.ac.uk/ipv6/...6-12/0109.html
>
>
>>and I did some simpler experiments and it seems tehre is some kind
>>of dependancy but not sure what it is...and for the tests I am doing I
>>dont want any dependancy at all, because I am testing several other
>>things (not only TCP; but I have my own link layer protocol plugin which
>>I am tuning too), and the results will be biased if there is some
>>dependancy, so I want to disable it....
>>Hope my question is clear now...
>
>
> Ah hah! And clear enough to suggest that you probably should be
> writing to the kernel mailing list. I stay out of the networking code
> as much as possible :-) Mine is just an admin's and lab instructor's
> interest.
>
> The 3-4 people around here that are familiar with the networking code
> have not posted much (or any?) in the past month or so -- at least I've
> not seen them.
>
> What you can or cannot readily disable will depend on which kernel you
> are using I'm pretty sure and how ready you are to compile/configure
> you own kernel. Many of these automagic tuning adjustments are being
> built into the "normal" kernel code and are targeted for a robust,
> stable IPv4/IPv6 stack that is complete and non-tunable (in the usual
> sense). IIRC, I've read somewhere recently that Linus would be happy
> to get rid of the sysctrl interface and make many of the /proc/net
> variables read only as an ulimate goal.
>
> If I understand your prediciment, you require _more_ control and ready
> ability to turn on/off different feartures in the stack implementation.
> It is likely my imagination, but I _think_ I ran into a project that
> provides a kernel (or plug-in) with a pretty complete runtime
> adjustable stack meant for testing purposes. Would something like that
> interest you? If so, I can try to stumble across it again.
>
> Beyond such legwork help, I'm not the one to provide kernel internals
> help. If you're familiar with the links then you already know which
> variables you can (probably) control that may be of help.
>
> Oops, have to run.
>
> good luck,
> prg
>
>
>>>Oumer Teyeb wrote:
>>>
>>>
>>>>Anyone who knows how to enable/disable control block interdependence in
>>>>linux? I was doing some experiments to see the effects of delay spikes
>>>>(upto 10sec) on TCP, and it seems if I run two downloads sequentially,
>>>>the first one will get all the timeouts I expect, but the second one
>>>>seem to be retransmission free, eventhough the delay I applied was like
>>>>10 sec...but if I run the two tests few minutes apart, both tests will
>>>>suffer a similar number of retransmissions...so I assume some kind of
>>>>tcp control block interdependence is at work...I tried to google for
>>>>information, and in one paper entitled "Congestion Control in Linux TCP"
>>>>by Pari Sarolahti, they mention in one sentence "Finally, the Linux
>>>>destination cache
>>>>provides functionality similar to the RFC 2140 that proposes
>>>>Control Block Interdependence between the TCP
>>>>connections." what is the "Linux destination Cache"?....I googled for a
>>>>while and I found some site
>>>>..http://www.cs.helsinki.fi/research/i...o-20020419.txt
>>>>where they claim to have a patch that will make it possible to control
>>>>the interdependence setting..but I am using some servers at the
>>>>university, and I dont think the admins will be willing to install
>>>>patches that are not stable....
>>>
>>>
>>>It's not clear from your several posts just what sorts of problems you
>>>are addressing. The tone suggests that you need better, more
>>>consistent network performance.
>>>
>>>End station tuning may help more or less help depending on the
>>>circumstances. In larger networks this tuning usually reveals network
>>>bottlenecks that must be addressed in the switches/routers and the
>>>pathway layout.
>>>
>>>Re: Linux tuning, you have to be aware of the changes in the kernel's
>>>network stack during 2.6.X development. Old 2.4.X tricks are often
>>>pointless ;-)
>>>
>>>Here is a link list I posted a while back that may provide some useful
>>>background and tuning tips:
>>>
>>>TCP Variables
>>>http://ipsysctl-tutorial.frozentux.net/
>>>
>>>TCP Perf Links
>>>http://www.psc.edu/networking/projects/tcptune/
>>>http://www-didc.lbl.gov/TCP-tuning/TCP-tuning.html
>>>http://www-didc.lbl.gov/TCP-tuning/linux.html
>>>http://www.uninett.no/tcpperf/
>>>http://www.infosyssec.net/infosyssec/netprot1.htm
>>>http://ltp.sourceforge.net/tooltable.php
>>>http://www.csm.ornl.gov/~dunigan/netperf/netlinks.html
>>>http://www.web100.org/
>>>
>>>Kernel Netwoking Notes: (as far back as 7/8/04)
>>>NAPI performance
>>>http://lwn.net/Articles/139208/
>>>Pluggable congestion avoidance modules
>>>http://lwn.net/Articles/128062/
>>>TCP window scaling and broken routers
>>>http://lwn.net/Articles/91976/
>>>
>>>hth,
>>>prg
>>>
>
>