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 , I'm not the one to provide kernel internals
> . If you're familiar with the links then you already know which
> variables you can (probably) control that may be of .
>
> 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 more or less 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
>>>
>
>