Thanks a lot for the review improving it. There is at least one more use of
this function,
and it is now much better to read. Glad about it.
| The moving average computation occurs so frequently in the CCID 3 code that
| it merits a macro of its own.
|
| Committer note: changed the patch
| I don't like macros that receive as a parameter something that will be
| changed, its more readable to have it as a inline function and return
| the new value, even if the resulting code uses more characters, so I'm
| applying the attached patch and will take care of the fallout, that is
|
Cool it Ian.
I think you are interpreting something into the email I sent which is not in
there. This is exactly the kind of talk I was asking for and I am glad that
Dave reviewed this.
Please read that email again.
I am asking for fair technical review here and rather than calling me names
Same comment. Please do read the documentation accompanying the patch.
Quoting David Miller:
| From: Ian McDonald [EMAIL PROTECTED]
| Date: Fri, 13 Apr 2007 09:50:30 +1200
|
| I didn't know this time stamping was expensive but I knew the way we
| were trying to optimise LAN is wrong. I
Sorry, I misread the email. Please see below.
| You want the scheduling delays and other issues that can
| delay DCCP input packet processing to get factored into
| the RTT, so that the sender will pace properly.
|
| Trying to get perfect timestamping and RTT measurements,
| and ignoring
From: Gerrit Renker [EMAIL PROTECTED]
Date: Fri, 13 Apr 2007 10:27:16 +0100
CCID3 uses the sampled RTT value as input into an equation so any
inaccuracies will multiply. I observed a difference of about 10.
This would indicate a bug in the equation if such small variances
cause it to explode
On 4/13/07, Gerrit Renker [EMAIL PROTECTED] wrote:
Cool it Ian.
I think you are interpreting something into the email I sent which is not in
there. This is exactly the kind of talk I was asking for and I am glad that
Dave reviewed this.
The mistake I made was that I didn't change the subject
Quoting David Miller:
| CCID3 uses the sampled RTT value as input into an equation so any
| inaccuracies will multiply. I observed a difference of about 10.
|
| This would indicate a bug in the equation if such small variances
| cause it to explode so easily.
|
| RTTs modulate
| And this creates an even deeper dependency on the global packet
| timestamping facility. Those are supposed to be enabled only
| in obscure circumstances because timestamping every packet is
| incredibly expensive.
... these patches will go into the bin as well.
-
To unsubscribe from this
Quoting Ian McDonald:
| Well I would have much rather discussed in private but a) you've told
| Eddie not to reply in public and the way stated seems to imply I
^--- u mean `private' ?
| shouldn't either b) you said that we were unreasonably holding up your
On 4/13/07, Gerrit Renker [EMAIL PROTECTED] wrote:
Quoting Ian McDonald:
| If for instance you read the documentation accompanying that patch, there
is a
| difference between 100 usec ... 1msec between skb_get_timestamp and taking
the timestamp
| in the CCID3 receiver. It all adds up.
| Do you remember when the `bidirectional' patch was reverted? - after that
the
| CCID3 sender slowed down again to 75..80 Mbits/sec on a 100Mbit link.
| This comes from the processing overhead, and was the original motivation
for
| this patch.
|
| How many connections? Up to now,
Quoting Arnaldo Carvalho de Melo:
| On 4/2/07, Gerrit Renker [EMAIL PROTECTED] wrote:
| | [DCCP]: Cheaper smaller timestamping
|
| | A couple of comments though:
| | - this is how I had the code originally in many cases and Arnaldo
| | changed - can't remember why.
| Arnaldo's
On 4/13/07, Gerrit Renker [EMAIL PROTECTED] wrote:
Quoting Arnaldo Carvalho de Melo:
| On 4/2/07, Gerrit Renker [EMAIL PROTECTED] wrote:
| | [DCCP]: Cheaper smaller timestamping
|
| | A couple of comments though:
| | - this is how I had the code originally in many cases and Arnaldo
|
Quoting Arnaldo Carvalho de Melo:
| On 3/21/07, Gerrit Renker [EMAIL PROTECTED] wrote:
| [DCCP]: Disable softirq when sending and notifying CCID
|
| This disables softirqs when performing the CCID-specific send operation
| in dccp_write_xmit, so that actual sending, and calling the CCID
Quoting Arnaldo Carvalho de Melo:
| I have tested on various i386 instances (where it is `long') and on
sparc64 (where it is `int', as
| in parisc). I was just calculating - there is indeed a chance to produce
overflow, since we add
| in timeval_add_usecs (since it is a signed type, the
On 4/13/07, Gerrit Renker [EMAIL PROTECTED] wrote:
Quoting Arnaldo Carvalho de Melo:
| On 3/21/07, Gerrit Renker [EMAIL PROTECTED] wrote:
| [DCCP]: Disable softirq when sending and notifying CCID
|
| This disables softirqs when performing the CCID-specific send operation
| in
On 4/13/07, Gerrit Renker [EMAIL PROTECTED] wrote:
Quoting Arnaldo Carvalho de Melo:
| I have tested on various i386 instances (where it is `long') and on
sparc64 (where it is `int', as
| in parisc). I was just calculating - there is indeed a chance to produce
overflow, since we add
| in
I am resubmitting this patch since David pulled it out
this morning and had issues with it - this is to show
that there is no more reliance on skb_get_timestamp.
There is a related issue, for which an update will also be provided.
-- Patch v2 --
[CCID 3]:
Your arguments consider only the specification. What you don't see, and Ian
also doesn't seem
to see, is that this implementation conforms to the ideas of TFRC only up to a
maximum speed
of s * HZ bytes per second; under benign conditions this is about 12..15
Mbits/sec.
Once you are past that
Quoting Arnaldo Carvalho de Melo:
| struct dccp_tx_hist_entry {
| struct list_head dccphtx_node; /* 0 16 */
| u64 dccphtx_seqno; /* 16 8 */
| struct timeval dccphtx_tstamp; /* 24 16 */
On 4/14/07, Gerrit Renker [EMAIL PROTECTED] wrote:
The comment by Dave brought me back to check what a change of
a factor of 10 does to the throughput in TFRC.
RFC 3448 gives in section 8 the following alternative format
of the throughput equation (which is directly responsible for
the alllowed
Quoting David Miller:
| From: Gerrit Renker [EMAIL PROTECTED]
| Date: Fri, 13 Apr 2007 13:03:02 +0100
|
| RFC 3448 gives in section 8 the following alternative format
| of the throughput equation (which is directly responsible for
| the alllowed sending rate X):
|
| s
Gerrit. I know the implementation is broken for high rates. But you are
saying that it is impossible to implement CCID3 congestion control at high
rates. I am not convinced. Among other things, CCID3's t_gran section gives
the implementation EXACTLY the flexibility required to smoothly
From: Ian McDonald [EMAIL PROTECTED]
Date: Sat, 14 Apr 2007 07:52:32 +1200
Which comes into play when we have loss. When we have no loss, or a
long period of non-loss we can send as fast as we want according to
the spec. This should normally be the case on LANs where the RTT makes
a far
From: Gerrit Renker [EMAIL PROTECTED]
Date: Fri, 13 Apr 2007 21:27:54 +0100
I wished someone could tell me that. Ian is right, the formula is used
after the first loss, but the idea is that the sender `overshoots' and then
reduces after the first loss due to overestimating the bandwidth.
So
On 4/14/07, David Miller [EMAIL PROTECTED] wrote:
From: Eddie Kohler [EMAIL PROTECTED]
Date: Fri, 13 Apr 2007 13:37:57 -0700
Gerrit. I know the implementation is broken for high rates. But you are
saying that it is impossible to implement CCID3 congestion control at high
rates. I am not
Hi David,
This might work, but I'd need to work it through.
The fact is that ALL TCP-like algorithms have rates that are inversely
proportional to the RTT. But in TCP and windowed protocols this happens
naturally due to ack clocking. In CCID3, there's no ack clocking. Acks
arrive much
I can't resist:
David Miller wrote:
I am really not sure that CCID3 can be implemented well without a lot of
real-time and system load requirements - if you have any suggestions or
know of similar problem areas, input would be very welcome.
I wonder what a DCCP implementation on old BSD would
Putting on my Sally hat:
David Miller wrote:
Eddie, this is an interesting idea, but would you be amicable to the
suggestion I made in another email? Basically if RTT is extremely
low, don't do any of this limiting.
What sense is there to doing any of this for very low RTTs? It is
a very
30 matches
Mail list logo
