Re: RFC: Latency reducing TCP modifications for thin-stream interactive applications

["Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>]

On Wed, 21 Jan 2009, kristrev@simula.no wrote:

> >> If I have understood the code correctly, what will then be the
> >> difference
> >> between our current solution and the one you suggest (except we can
> >> remove
> >> one of the bundling methods and when a packet is retransmitted)? If I
> >> have
> >> not understood the code correctly, feel free to yell :) (if it is a
> >> misunderstanding, it also explains all the checks for skb->cloned).
> >
> > It didn't mean clone an skb but copy the relevant data into new skb which
> > is then not put into write queue at all but given to lower layers only.
> 
> Thank you, now I understand what you meant and I agree that it is a better
> solution. However, when I think of it, copying might be too resource
> intensive and thus remove all gains from RDB. We have seen streams with 
> small packets and very low interarrival times, which would lead to a large
> number of copy-operations every second. I will implement it and compare
> performance.

The latencies caused by network related problems are hardly in the same 
order of magnitude than processing latencies due to simple alloc + copy of 
<= mss sized content, and if data is in frags you won't be copying even 
that much. For every avoided retransmission (with the associated rtt 
latency) you can copy a lot of data.

Ah, one more thing I already forgot earlier... Your solution is lacking 
means to deal with ambiguity problem which is a serious problem since
RTT measurements are valid only if there was not ambiguity.

-- 
 i.