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,
This patch replaces calls to do_gettimeofday at the receiver CCID 3
with skb timestamps. The skb timestamps are computed earlier in the
receive path, experimental measurements have shown that up to several
hundred microseconds can lie between the skb receive timestamp and the
timestamp taken
On 4/12/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Thu, 12 Apr 2007 18:14:54 -0300
This patch replaces calls to do_gettimeofday at the receiver CCID 3
with skb timestamps. The skb timestamps are computed earlier in the
receive path,
On 4/13/07, David Miller [EMAIL PROTECTED] wrote:
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Thu, 12 Apr 2007 18:14:54 -0300
This patch replaces calls to do_gettimeofday at the receiver CCID 3
with skb timestamps. The skb timestamps are computed earlier in the
receive path,
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 say LAN because a few
microseconds or even milliseconds difference on a WAN link makes
bugger all difference
14 matches
Mail list logo
