Hi Eddie,
many thanks for the references and comments; please see inline.
- Gerrit
| * I think service codes should be part of the sockaddr for DCCP. The
decision
| to make them a setsockopt() I think has made things harder. From 9/9/05:
|
|I agree with Arnaldo et al. here. The
Hi Ian,
| Thanks for mentioning dccp@ietf.org, have copied message there. If there
are no
| strong objections, will send patch on Monday.
|
| - Gerrit
|
| I agree about the service code personally but we shouldn't accept into
| Linux something that deliberately breaks the RFC. We need
codes can be set
via socket options as before.
This patch has been tested using various client/server configurations
(including listening on multiple service codes) and patches against
Torvalds' tree.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
Documentation/networking/dccp.txt |7
. Thank you for checking.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
Documentation/networking/dccp.txt |8 +---
include/linux/dccp.h |6 +-
net/dccp/ipv4.c |3 ---
net/dccp/proto.c | 11 +--
4 files changed, 7
| This creates two new socket options DCCP_SOCKOPT_TX_PACKET_SIZE
| and DCCP_SOCKOPT_RX_PACKET_SIZE. DCCP_SOCKOPT_PACKET_SIZE doesn't
| work and packet size should be set independently on two half
| connections.
I disagree with this solution: it solves one problem by introducing two
new ones:
| This removes DCCP_SOCKOPT_PACKET_SIZE for two reasons:
| * the current code doesn't work
| * tx and rx should be different (introduced in former patch)
Agree that DCCP_SOCKOPT_PACKET_SIZE is redundant, patch looks good and
has been tested.
Acked-by: Gerrit Renker [EMAIL PROTECTED]
| Signed
Quoting Ian McDonald:
| Set initial packet size to defaults as existing code doesn't work
| as set_sockopt occurs after initialisation so dccps_packet_size
| is of no use really.
Please see comments to patch 5/7; rather than setting a default,
ccid3hc{rx,tx}_s should be derived from
I think that the PACKET_SIZE socket option is redundant, since
it can be derived from
* the buflen argument of dccp_sendmsg()
* the size of received packets
independent of whether the CCID is for fixed packet sizes or not.
Virtually all known CCIDs have fixed packet sizes; for such CCIDs
there
|1/ TX Buffering: set size of TX ring buffer via socket option.
|
| The size of the TX buffer is interesting in applications which want to do
their
| own queue management. That is, real-time applications that would prefer
| dropping certain packets and re-order other packets based on
This part just shifts the code in ipv4.c in order
to resolve dependencies among the static functions.
It applies on the previous patch (don't use it standalone).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
ipv4.c | 368 -
1
is unfolded in-place
and the bh_nested_lock indicator is used instead of bh_lock.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
ipv4.c | 22 +++---
ipv6.c | 27 ---
2 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/net/dccp/ipv4.c b
It seems that I am not the only one having headaches about which patches
are applied and which not. I spent a major part yesterday trying to get
the set of patches consistent with regard to Dave's/Arnaldo's latest tree.
What I have been doing over time is collecting all patches that were posted
Hi Ian
Thanks for the tip, I know your web repository and will certainly look at
stgit (I am doing something like that at the moment).
| I would like to see bug fixes in 2.6.19 too if they are obvious fixes
| e.g. the one I sent today. I won't get into the debate about other
| cosmetic
| In my opinion this should go into 2.6.19 as bug and causes logs to be
| filled.
ACK - this is useful and I have found it to apply without problem. Minor
quibble below.
| @@ -58,6 +58,9 @@ #define DCCP_RESOURCE_PROBE_INTERVAL ((u
|
| #define DCCP_RTO_MAX ((unsigned)(120 * HZ)) /*
As promised earlier, this is the set of patches which I have been
keeping up-to-date; they divide into:
* patches sent to this list that have not been merged
[I claim that this is exhaustive, i.e. all other patches
have been merged - notify me if there is one missing]
This is a re-send from
http://www.mail-archive.com/dccp@vger.kernel.org/msg00553.html
It is the same patch as before, but I have built in Arnaldo's suggestions
pointed out in that posting.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED
[DCCP]: Fix DCCP Probe typo
Fixes a typo in Kconfig, patch is by Ian McDonald and is
re-sent from http://www.mail-archive.com/dccp@vger.kernel.org/msg00579.html
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
net
[DCCP]: Add FIXME for tw_deschedule()
This just adds a FIXME for a function which is not implemented (maybe it
should be removed altogether, no code at all references it).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED
situations which is
consistent with the already existing macro net_xmit_errno, saving
on duplicated code.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
include/linux/netdevice.h |4
include/net/ipip.h
1063 was obsoleted by RFC 1191
* draft-ietf-tcpimpl-pmtud-0x.txt was published as an Informational
RFC, RFC 2923 on 2000-09-22.
All references verified; patches against stable and Torvald's tree
Signed-off-by: Gerrit Renker [EMAIL PROTECTED
()
--removed second argument (never used)
--set the default sequence window there (generic code, is not AF-dependent)
--removed FIXME regarding filling-in options: it seems that all sensible
options are already filled in; so this note seems unnecessary.
Signed-off-by: Gerrit Renker
://www.mail-archive.com/dccp@vger.kernel.org/msg00401.html
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
net/dccp/ackvec.c | 115 ++---
net/dccp/ackvec.h | 22
the code consistent (same handling in both functions).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
net/dccp/ipv4.c | 21 ++---
net/dccp/ipv6.c | 30 +-
2 files changed
the problem by using bh_nested_lock instead of bh_lock, which
is
justified since there really only is one nesting level.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
net/dccp/ipv4.c | 22 +-
net/dccp
it by resetting timeo. Put constant into header as well.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
--
net/dccp/dccp.h |2 ++
net/dccp/output.c |8 +---
2 files changed, 7 insertions(+), 3 deletions
-by: Gerrit Renker [EMAIL PROTECTED]
--
net/dccp/ipv6.c | 386 +++-
1 file changed, 191 insertions(+), 195 deletions
. 6.4
* annotating which ones have been implemented so far
* implemented rudimentary sanity checking in feat.c (FIXMEs)
* some minor fixes
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
include/linux/dccp.h |6 +++-
net/dccp/feat.c | 74
-archive.com/dccp@vger.kernel.org/msg00372.html ).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/Kconfig | 11 +++
net/dccp/ccids/ccid3.c | 16
2 files changed, 19 insertions(+), 8 deletions(-)
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids
for a generic solution to both,
since the key problem in both is in releasing the control socket.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ipv4.c |5 +
net/dccp/ipv6.c |2 ++
2 files changed, 7 insertions(+)
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -1065,6
Arnaldo Carvalho de Melo wrote:
| Gerrit,
|
| I'm going over the_whole_lot patch queue from you, many thanks
| for doing this work! About 07a_putative_nested_lock_in_rcv.diff, I
| haven't studied the bh_lock_sock_nested, lockdep stuff, but can't we
| just use bh_lock_sock_nested in
| | but can't we just use bh_lock_sock_nested in sk_receive_skb?
| I am not sure about that one - I don't know all the functions calling
| sk_receive_skb (cscope says ppoe.c / dn_nsp_in.c use this too).
|
| In the TCP/DCCP case it is clear (due to the cloning while one is held
under
|
[DCCP]: Remove forward declarations in timer.c
This removes 3 forward declarations by reordering 2 functions.
No code change at all.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
---
net/dccp/timer.c | 110 ++-
1 file changed, 53
While working on the promised EWMA patch for CCID 3 packet sizes, I stumbled
over two things
and can make no sense of a bit of CCID 3 Receive code:
1) ccid3_hc_rx_sock maintains a real-timer RTT counter ccid3hcrx_rtt
which is an alias for a TFRC structure defined in
| Anyway I'll have a look at it as I can but feel free to make patches.
| If you're removing chunks of code I'd prefer it commented out in the
| meantime rather than removed.
Thanks - I was hoping for your answer. To me it seemed that the bidirectional
processing (node is both receiver and
Hi Arnaldo
| Well, I'd rather prefer a WARN_ON type, probably rate limiting the
| printks, so that we can receive reports that something is fishy but
| don't panic the machine.
I have implemented such a macro and have changed the patch to use it.
If it is acceptable, I would like to propose
Quoting Arnaldo Carvalho de Melo:
| On 9/22/06, Gerrit Renker [EMAIL PROTECTED] wrote:
| Quoting Eddie Kohler:
| | Why burden the application programmer to handcode an estimation of
the average each
| | time? I can not see a justification for this, certainly not for CCIDs
which
Hi Arnaldo,
| Thanks, applied.
many thanks for applying this; it was sooner as expected and I think it would
be good to tidy this up and make it consistent throughout the code. Since I
initiated this,
I feel a bit obliged to improve this.
In particular, I have thought about the following
Quoting Ian McDonald:
| I'm still working on it but anybody else can feel free to help!
It is great to see that this is picked up. It is one of the items which I had
put onto the ToDo list as well,
the thread starting this began on
Quoting Ian McDonald:
| Gerrit has volunteered to fix up otherwise I will look at next week.
Thanks, I will post the aligned version later and add it to the updated change
sets on
http://www.erg.abdn.ac.uk/users/gerrit/dccp/patch-backlog/
(thanks to Arnaldos ongoing work, this is whittled
This includes mostly Ian's tx_qlen patch, the promised tidy-up of the WARN/BUG
message scheme, and some trivial things.
Patch 1: This is Ian's tx_qlen updated tx_qlen patch.
I have removed the #define again (and was the one who suggested it);
it seemed not to be a good idea
[DCCP]: DCCP_WARN() wrapper
This introduces a rate-limited DCCP_WARN() wrapper for
non-critical DCCP warning messages.
For CCID 3/TFRC it also adds warning messages whenever the RTT
is estimated at 0.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 67
[CCID 3]: Add annotations for socket structures
This adds documentation to the CCID 3 rx/tx socket fields.
Plus some minor re-formatting.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.h | 90 +
1 file changed, 55
Arnaldo,
| Why not use these valuable detailed derivations in the commit
| messages? I'm very much in favour of having them in the git logs,
| please let me know if you won't mind me doing that, no need to
| resubmit, I'd just remove the [] part
please do feel free to include or exclude as
into one which is shorter and
resembles the one in RFC 3448 (t_mbi)
* simplifies some of the min_t/max_t cases where both `x', `y' have the same
type
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 66 +
net/dccp
| [CCID 3]: Simplify control flow in the calculation of t_ipi
snip
|In addition, a problematic comment in ccid3_calc_new_t_ipi() was removed:
| * the first part of the comment (initial t_ipi = 1 second) is correct
| * the second part of the comment is not correct wrt. [RFC 3448,
| I'm looking at these and signing them off when obviously correct.
| Others I'm acking to say they look ok.
Thank you very much for checking these.
I have added all your Signed-off/Acked-by lines where provided.
| I'll do some regression testing hopefully later in the week but I
| don't
| [DCCP]: Simplify dccp_rcv_state_process
|
| This patch does not change the algorithm, it just simplifies control flow
a bit.
|
| The main changes are:
|* cleanup after dccp_rcv_request_sent_state_process is now done within
that function,
| not in dccp_rcv_state_process
|
| | I violently agree with Gerrit on this one, no one is preventing anyone
| ^^
| ^^
Ouch - I was sure I had read `violently disagree'. Weierha ...
| | from doing experimental work, the infrastructure is there and if
| |
| Eddie can suggest whatever he likes and I welcome it. That doesn't
| mean it will get included though as it depends on coders. You don't
| like his approach which is fine - it means that you won't code it. I
| like the sounds of it but very time constrained so probably won't
| unless it
Quoting Arnaldo Carvalho de Melo:
| most things merged, except for the packet size and
| TRFC equation patches, that I thought a day or two would be nice for
| further discussion.
I have tidied up what remained and uploaded the up-to-date remaining patches on
to
by ccid_hc_tx_send_packet are caught in dccp_write_xmit
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccid.h|8 ++---
net/dccp/ccids/ccid2.c |4 +-
net/dccp/ccids/ccid3.c | 78 ++---
3 files changed, 42 insertions(+), 48 deletions
-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -246,7 +246,7 @@ static void ccid3_hc_tx_no_feedback_time
Quoting Ian McDonald:
| The code here predates me but I think the reason for it might be to do
| with RFC4342 (remember to read 3448 in conjunction with this).
|
| If the sender never receives a feedback packet from the receiver, and
| as a consequence never gets to set the allowed
Quoting Ian McDonald:
| On 11/29/06, Gerrit Renker [EMAIL PROTECTED] wrote:
| [DCCP]: Use `unsigned' for packet lengths
|
| I'm wondering whether this code is 64 bit safe??? I don't think it is.
| Arnaldo can probably advise.
|
| We changed int to u32 for length and I went and checked
Quoting Ian McDonald:
| I think I didn't explain my point well here. You can't change to u32
| but need to be unsigned int (not u64).
Don't get this: u32 is a 32-bit unsigned value and therefore looks sufficient -
and you
are proposing `unsigned int' to have easier conversion to skb-len,
-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -183,7 +183,7 @@ static void ccid3_hc_tx_no_feedback_time
{
struct sock *sk
| On 11/29/06, Gerrit Renker [EMAIL PROTECTED] wrote:
| Quoting Ian McDonald:
| | I think I didn't explain my point well here. You can't change to u32
| | but need to be unsigned int (not u64).
| Don't get this: u32 is a 32-bit unsigned value and therefore looks
sufficient - and you
Quoting Ian McDonald:
|In short: my suggestion is to keep an experimental patch for this and I
would even offer to
| keep one up-to-date and online, if in return we can simplify
the socket API. Does
| this sound like a more convincing argument?
|
| Fair enough,
Quoting Eddie Kohler:
| | Would really appreciate if you could at some time have a look at the
moving-average patch. Have communicated
| | with Eddie again about it, and using MSS would at the moment be much
more complicated.
| |
| | Will look at it tomorrow (along with
| Btw, I couldn't find anything to test DCCPv6 with (GNU netcat somehow
| lacks IPv6 support), so wrote some simple apps to do this:
I have finally managed to put my ttcp clone also online. It supports DCCPv6 and
has
some extra routines to parse service codes, as well as a more verbose
| ccid3_hc_tx_packet_recv: Illegal ACK received - no packet has been
| sent
It seems that the receiver does not get into the state NO_FBACK, since this
message is printed only in the state TFRC_SSTATE_NO_SENT, which indicates that
the state transmission TFRC_SSTATE_NO_SENT --
tested to compile and work.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/Kconfig | 22 ++
net/dccp/ccids/ccid3.c | 20 +++-
2 files changed, 33 insertions(+), 9 deletions(-)
--- a/net/dccp/ccids/Kconfig
+++ b/net/dccp/ccids/Kconfig
@@ -89,4
| BTW, I am using CCID3.
|
| Ok, now to the next troubleshooting test: can you please try using
| CCID2? That way we can isolate the problem, is it CCID3 specific?
| CCID2? Core? Something else?
Yes, please do send all kinds of debug information which you encounter to the
list;
this
, subtracting, and then testing the difference
with regard to 0.
This has been tested and shown to work.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -339,7
Ian McDonald wrote:
| Folks,
|
| I've started my testing and confirm what the other two have said on
| list. Using Acme net 2.6.20 tree as of about four hours ago basically
| I get no data transmitted. Works fine on my 2.6.19 modified tree.
|
| I'm using iperf as follows (using today's
Quoting Arnaldo Carvalho de Melo:
| Here is now the patch, I have had a hard time due to division of u64 by
| u32. I have also checked again - it is feasible to prune X_calc and
| X_recv back to u32. If you prefer that, I can change the patch.
|
| If it is possible, its better, minus 8
Quoting Mark Handley:
| I agree that running a very small no-feedback timer is a bad idea.
| But I think that 1 second is probably far too large. The purpose of
| the nofeedback timer is to slow DCCP down when there is serious
| network congestion. Waiting 1 second on a LAN would mean
Hi Arnaldo,
many thanks for the detailed feedback - that has taught me some things I did
not know.
I will reshape the patch with regards to comments. While at it, would like
to increase resolution up to units of 100ms, with a default value of 10
corresponding to the TCP RTO value - as per
Quoting Arnaldo Carvalho de Melo:
| We're agreeing Gerrit... you jumped to conclusions too fast because
| you didn't read what I said in the next paragraph, that I quote here:
|
|
| Clarification on this one, you had _fixed_ it in your previous patch,
| then removed
I have been doing bug hunting almost all day, two bug fixes are enclosed,
for the remainder I am willing to stick my head into the code next week
until the performance is up to a reasonable level and most of the known
bugs are ironed out.
I went through the earlier patches and tossed out some
of r_sample
* adds a a more debugging information regarding current send rates
* various trivial comment/documentation updates
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 89 -
1 file changed, 52 insertions(+), 37
half
The message gets printed since on a server the client half is currently not
sending data packets.
This is resolved for the moment by checking the DCCP-role first. In future
times (bidirectional DCCP connections), this test may have to be more
sophisticated.
Signed-off-by: Gerrit Renker [EMAIL
derived through reverse engineering and found to be
fully accurate (verified using test programs).
This patch does not change any code.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/tfrc_equation.c | 122 -
1 file changed, 67 insertions
then
p = (index+1) * TFRC_CALC_X_SPLIT/TFRC_CALC_X_ARRSIZE
These are exactly the changes that the patch makes; previously the code did
not conform to the way the lookup table was generated (this difference resulted
in a mean error of about 1.12%).
Signed-off-by: Gerrit Renker [EMAIL
-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/tfrc_equation.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
--- a/net/dccp/ccids/lib/tfrc_equation.c
+++ b/net/dccp/ccids/lib/tfrc_equation.c
@@ -588,22 +588,19 @@ u32 tfrc_calc_x(u16 s, u32 R, u32 p
that the table can not resolve practically occurring cases.
Already at p == TFRC_SMALLEST_P, the error is as high as 58.19%!
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 21 +
net/dccp/ccids/ccid3.h |2 --
2 files changed, 5 insertions(+), 18
resolution
* combines two previously adjacent if-blocks of nearly identical
structure into one
This patch does not change the algorithm as such.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/tfrc_equation.c | 27 ++-
1 file changed, 18
value appears equally likely) down to at most 9.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/tfrc_equation.c | 38 +++--
1 file changed, 24 insertions(+), 14 deletions(-)
--- a/net/dccp/ccids/lib/tfrc_equation.c
+++ b/net/dccp/ccids/lib
Quoting Mark Handley:
| On 12/1/06, Colin Perkins [EMAIL PROTECTED] wrote:
| I'd actually suggest something on the order of 16-20ms. The rationale
| would be to match the typical inter-frame interval for multimedia
| applications, so that the kernel will likely be processing a sent
|
Quoting Ian McDonald:
| On 12/2/06, Gerrit Renker [EMAIL PROTECTED] wrote:
|
| [DCCP]: Add protection against invalid parameters to TFRC routines
|
| + BUG_ON(p 100); /* p must not exceed 100% */
| + BUG_ON(p == 0); /* f(0) = 0, divide
Quoting Ian McDonald:
| On 12/2/06, Gerrit Renker [EMAIL PROTECTED] wrote:
| [DCCP]: Deprecate TFRC_SMALLEST_P
|
| Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
|
| Acked-by: Ian McDonald [EMAIL PROTECTED]
I would like to inform you that I have made a small change which
would
Quoting Ian McDonald:
| The
| reason I say this is good as in the back of my mind I am thinking of
| people looking for DoS vulnerabilities...
|
| However BUG_ON does work and forces the code to get tidied so the
| condition doesn't occur again. So whichever way I'm happy to go ahead
|
handles the EAGAIN case by restarting afresh to peek into
the write queue and send the packet.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/output.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -255,8 +255,11 @@ void
| So here are the stats using iperf:
| Test 2.6.19rc6+ian
| 2.6.20-acme20
| Direct connect 87 Mbits 36 Mbits
| Through a Linux router (1.2 ms rtt) 36 Mbit 200 kbits
| (yes that is
| I highly suggest the use of oprofile in case you aren't using it yet. To
| relieve CPU usage:
| * boot parameter: clock=tsc
| * the most expensive thing should be checksum calculating [~25%]
This is helpful, many thanks. I was using an older 2xP3 Xeon 700Mhz with 2GB
Ram and e100
card. I
| This one doesn't seem right to me because we get EAGAIN in theory only
| if packet delay is greater than timeo which is 30 seconds, or timeo is
| 0, or delay 0 (which shouldn't happen as msecs_to_jiffies returns
| unsigned). EAGAIN is only set by dccp_wait_for_ccid.
That is true, but this
Quoting Arnaldo Carvalho de Melo:
o:
| | Here is now the patch, I have had a hard time due to division of u64
by
| | u32. I have also checked again - it is feasible to prune X_calc and
| | X_recv back to u32. If you prefer that, I can change the patch.
| |
| | If it is possible,
I am now sorting out all experimental patches into a separate directory:
http://www.erg.abdn.ac.uk/users/gerrit/dccp/experimental_patches/
This is for patches which may be useful in some situations, but not in general
(e.g. the Unload Hack is still an unsafe method and can result in oops if
Nice work Ian!
| Signed-off-by: Ian McDonald [EMAIL PROTECTED]
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
| + unsigned long delay;
With regard to the delay, I think we are now fairly on the safe side. Although
schedule_timeout
takes `signed long', the value of delay can not be large
| - altering packet size makes no difference to packet rate (see
| http://wand.net.nz/~perry/max_download.php ) at present
I sometimes think that we could edge out more throughput this way - but this
is already going towards CCID 4, we don't need to implement more than what is
in the spec.
-
To
is also removed - it helps very
little in debugging and just clutters the logs.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
in the computation of larger initial windows: instead of
min(... max()) (cf. RFC 4342, 5.), the code had used max(... max()).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/dccp/ccids/ccid3.c
+++ b
arithmetic cut-off
The patch implements a revised strategy from
http://www.mail-archive.com/dccp@vger.kernel.org/msg01040.html
The only difference with regard to that strategy is that t_ipi is already
used in the calculation of the nofeedback timeout, which saves one division.
Signed-off-by: Gerrit
is safe since the TFRC reverse-lookup routine then returns p=100%.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 39 ++-
1 file changed, 22 insertions(+), 17 deletions(-)
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
message is added.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -444,9 +444,9 @@ static void ccid3_hc_tx_packet_recv(stru
This is a small patch set - and two more bugs busted.
Patch 1: Checks against too large p. This cropped up in a
discussion a few days ago. In all cases, p 100%
as necessary.
Patch 2: Two optimisations for recomputing the sending rate X.
Patch 3: Two bug fixes - both are my
| * I quite frequently got those messages from tfrc_calc_x, like
|
| tfrc_calc_x: Value of p (29) below resolution. Substituting 100
|
| This should not happen - I believe that these p measurements are bogus
| and we should check if the loss rate computation is ok.
|
| Is
and the remaining stub function inlined.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -551,14 +551,8 @@ static void ccid3_hc_tx_packet_recv
[CCID3]: TX history - remove unused field
This removes the `dccphtx_ccval' field since it is nowhere
used in the code and in fact not necessary for the accounting.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/ccid3.c |5 +++--
net/dccp/ccids/lib
:
The initialisation of the window counter is left in the state NO_SENT, as
before.
The algorithm will do nothing if either RTT is initialised to 0 (which is ok)
or if
the RTT value remains below 4 microseconds (which is almost pathological).
Signed-off-by: Gerrit Renker [EMAIL PROTECTED
1 - 100 of 702 matches
Mail list logo
