mirror?

mirror?

[Tomasz Grobelny]

As http://www.erg.abdn.ac.uk/ seems to be down at least since yesterday I'd 
like to ask whether any mirror of dccp git tree and/or dccp patches to 
mainline kernel is available. TIA,
-- 
Regards,
Tomasz Grobelny

Re: mirror?

[Ian McDonald]

On 12/25/07, Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> wrote:
> As http://www.erg.abdn.ac.uk/ seems to be down at least since yesterday I'd
> like to ask whether any mirror of dccp git tree and/or dccp patches to
> mainline kernel is available. TIA,
> --
> Regards,
> Tomasz Grobelny

Here is the announcement of the outage:

Both the dccp and the ccid4 trees have been brought up-to-date and uploaded.

Due to necessary building work, we have to power down almost all servers in
the department from

       Friday  21st December 2007    until
       Sunday   6th January  2008


-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz

Re: mirror?

[Arnaldo Carvalho de Melo]

Em Tue, Dec 25, 2007 at 08:23:05AM +1300, Ian McDonald escreveu:
> On 12/25/07, Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> wrote:
> > As http://www.erg.abdn.ac.uk/ seems to be down at least since yesterday I'd
> > like to ask whether any mirror of dccp git tree and/or dccp patches to
> > mainline kernel is available. TIA,
> > --
> > Regards,
> > Tomasz Grobelny
> 
> Here is the announcement of the outage:
> 
> Both the dccp and the ccid4 trees have been brought up-to-date and uploaded.
> 
> Due to necessary building work, we have to power down almost all servers in
> the department from
> 
>        Friday  21st December 2007    until
>        Sunday   6th January  2008

I have a clone and just made the whole series available as a single
patch at:

http://oops.ghostprotocols.net:81/acme/dccp/gerrit-2.6/gerrit-pending-review.patch.bz2

The broken out patch series is also at:

http://oops.ghostprotocols.net:81/acme/dccp/gerrit-2.6/

You have to clone from DaveM's net-2.6.25 and then apply the series, for
your convenience:

git clone git://.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.25
cd net-2.6.25
wget http://oops.ghostprotocols.net:81/acme/dccp/gerrit-2.6/gerrit-pending-review.patch.bz2
bzcat gerrit-pending-review.patch.bz2 | patch -p1

I plan to review the feature negotiation patch series that is the bulk
of what I still haven't reviewed in Gerrit's pending tree while its
still 2007.

Regards,

- Arnaldo

Re: mirror?

[Gerrit Renker]

Quoting Tomasz Grobelny:
| As http://www.erg.abdn.ac.uk/ seems to be down at least since yesterday I'd 
| like to ask whether any mirror of dccp git tree and/or dccp patches to 
| mainline kernel is available. TIA,
| -- 
Sorry about the outage, our building was renovated over the holidays. I
am just revising the patches,

   	git://eden-feed.erg.abdn.ac.uk/dccp_exp		{dccp,ccid4}

should be online in an hour or so. The web server on 	

	http://www.erg.abdn.ac.uk/users/gerrit/dccp/

is already back online.	

[DCCP] [Patch 1/1] [BUG-FIX]: Fix problem with small RTTs in CCID-3

[Gerrit Renker]

Arnaldo,

please consider the attached patch which fixes the reported problems with small
RTTs in CCID-3. Clamping the RTT is not a good idea, since CCID-3 in many places
computes its throughput in the form "xxx/RTT" - so that increasing the RTT by a
factor of 10 will decrease the maximum achievable throughput by a factor of 10.

The patch is at the bottom of the test tree. The bug has also been fixed
in the CCID-4 subtree (a note has been added to patch #19 there).

----------------------------> Patch / BUG-FIX <---------------------------------
[CCID-3]: Fix "t_ipi explosion" bug

The identification of this bug is thanks to Cheng Wei and Tomasz Grobelny.

To avoid divide-by-zero, the implementation previously ignored RTTs smaller
than 4 microseconds when performing integer division RTT/4. 

When the RTT reached a value less than 4 microseconds (as observed on loopback),
this prevented the Window Counter CCVal value from advancing. As a result, the
receiver stopped sending feedback. This in turn caused non-ending expiries of
the nofeedback timer at the sender, so that the sending rate was progressively
reduced until reaching the bottom of one packet per 64 seconds.

The patch fixes this bug by handling integer division more intelligently. Due to
consistent use of dccp_sample_rtt(), divide-by-zero-RTT is avoided.

The patch was tested to successfully eliminate the "t_ipi explosion" problem
for loopback RTTs in the order of 1 microsecond - the sending behaviour now
became stable and predictable.

Since 1 microsecond is at the same time the minimum RTT resolution, the same
stable behaviour can be expected for other (small) RTTs.

Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
 net/dccp/ccids/ccid3.c |   13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -193,22 +193,17 @@ static inline void ccid3_hc_tx_update_s(
 
 /*
  *	Update Window Counter using the algorithm from [RFC 4342, 8.1].
- *	The algorithm is not applicable if RTT < 4 microseconds.
+ *	As elsewhere, RTT > 0 is assumed by using dccp_sample_rtt().
  */
 static inline void ccid3_hc_tx_update_win_count(struct ccid3_hc_tx_sock *hctx,
 						ktime_t now)
 {
-	u32 quarter_rtts;
-
-	if (unlikely(hctx->ccid3hctx_rtt < 4))	/* avoid divide-by-zero */
-		return;
-
-	quarter_rtts = ktime_us_delta(now, hctx->ccid3hctx_t_last_win_count);
-	quarter_rtts /= hctx->ccid3hctx_rtt / 4;
+	u32 delta = ktime_us_delta(now, hctx->ccid3hctx_t_last_win_count),
+	    quarter_rtts = (4 * delta) / hctx->ccid3hctx_rtt;
 
 	if (quarter_rtts > 0) {
 		hctx->ccid3hctx_t_last_win_count = now;
-		hctx->ccid3hctx_last_win_count	+= min_t(u32, quarter_rtts, 5);
+		hctx->ccid3hctx_last_win_count	+= min(quarter_rtts, 5U);
 		hctx->ccid3hctx_last_win_count	&= 0xF;		/* mod 16 */
 	}
 }

[DCCP] [Patch 1/1] [BUG-FIX]: Fix problem with small RTTs in CCID-3

[Gerrit Renker]

Arnaldo,

please consider the attached patch which fixes the reported problems with small
RTTs in CCID-3. Clamping the RTT is not a good idea, since CCID-3 in many places
computes its throughput in the form "xxx/RTT" - so that increasing the RTT by a
factor of 10 will decrease the maximum achievable throughput by a factor of 10.

The patch is at the bottom of the test tree. The bug has also been fixed
in the CCID-4 subtree (a note has been added to patch #19 there).

----------------------------> Patch / BUG-FIX <---------------------------------
[CCID-3]: Fix "t_ipi explosion" bug

The identification of this bug is thanks to Cheng Wei and Tomasz Grobelny.

To avoid divide-by-zero, the implementation previously ignored RTTs smaller
than 4 microseconds when performing integer division RTT/4. 

When the RTT reached a value less than 4 microseconds (as observed on loopback),
this prevented the Window Counter CCVal value from advancing. As a result, the
receiver stopped sending feedback. This in turn caused non-ending expiries of
the nofeedback timer at the sender, so that the sending rate was progressively
reduced until reaching the bottom of one packet per 64 seconds.

The patch fixes this bug by handling integer division more intelligently. Due to
consistent use of dccp_sample_rtt(), divide-by-zero-RTT is avoided.

The patch was tested to successfully eliminate the "t_ipi explosion" problem
for loopback RTTs in the order of 1 microsecond - the sending behaviour now
became stable and predictable.

Since 1 microsecond is at the same time the minimum RTT resolution, the same
stable behaviour can be expected for other (small) RTTs.

Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
 net/dccp/ccids/ccid3.c |   13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -193,22 +193,17 @@ static inline void ccid3_hc_tx_update_s(
 
 /*
  *	Update Window Counter using the algorithm from [RFC 4342, 8.1].
- *	The algorithm is not applicable if RTT < 4 microseconds.
+ *	As elsewhere, RTT > 0 is assumed by using dccp_sample_rtt().
  */
 static inline void ccid3_hc_tx_update_win_count(struct ccid3_hc_tx_sock *hctx,
 						ktime_t now)
 {
-	u32 quarter_rtts;
-
-	if (unlikely(hctx->ccid3hctx_rtt < 4))	/* avoid divide-by-zero */
-		return;
-
-	quarter_rtts = ktime_us_delta(now, hctx->ccid3hctx_t_last_win_count);
-	quarter_rtts /= hctx->ccid3hctx_rtt / 4;
+	u32 delta = ktime_us_delta(now, hctx->ccid3hctx_t_last_win_count),
+	    quarter_rtts = (4 * delta) / hctx->ccid3hctx_rtt;
 
 	if (quarter_rtts > 0) {
 		hctx->ccid3hctx_t_last_win_count = now;
-		hctx->ccid3hctx_last_win_count	+= min_t(u32, quarter_rtts, 5);
+		hctx->ccid3hctx_last_win_count	+= min(quarter_rtts, 5U);
 		hctx->ccid3hctx_last_win_count	&= 0xF;		/* mod 16 */
 	}
 }

dccp bugs (Was: Re: panic on 2.6.24rc5)

[Tomasz Grobelny]

Dnia Friday 07 of March 2008, Gerrit Renker napisa³:
> | > errno=EPERM. That was my mistake, the `1' is generated by the device
> | > output routine, which generates NET_XMIT_DROP when the Qdisc decides
> | > not to send the packet (linux/netdevice.h).
> |
> | And so I guess that this NET_XMIT_DROP should be ignored by dccp code?
>
> In the test tree it is now (almost) ignored. Since the time you reported
> this problem I have changed the DCCP_BUG to a DCCP_WARN, so that the
> drop will still be logged, but there will be fewer such warnings in the
> log now (in DCCP_WARN, printk is rate-limited).
>
I'm not sure it should print the warning. Ok, it's nice to know that the 
packet was dropped but:
a) in real world there would be no such information,
b) it's not something unusual for DCCP to lose packet without warning.
Maybe it should only warn if debugging option is enabled?

> This is interesting -- so you are running DCCP under virtualisation?
Yes.

> Arnaldo used to do this with QEMU, I tried this recently also but am no
> fan of virtual networks. Yes, if the crash persisted, any information
> would help.
>
The panic happens no more.

> | >  * to avoid this, there is a kernel configuration option of CCID-3
> | >    to set an upper bound for this.
> |
> | How do I set it?
>
> In the menu under
>  Networking -> Network Options -> The DCCP Protocol (EXPERIMENTAL)
>  -> DCCP CCIDs Configuration (EXPERIMENTAL) -> CCID3
>  -> (100) Use higher bound for nofeedback timer
> Ah - just remembered -- the default is 100 milliseconds, so this will
> probably have caught the problems with the low RTT.
>
100ms? Then it doesn't work as expected because adding just 1ms delay with 
netem fixed the problem.
If you meant 100us then it still doesn't work. Changing the parameter to 1000 
delays the bug - I have to send more packets for it to happen.

> | > Please let us know if that diagnosis matches the case.
> |
> | How can I test it? The best I came up with was adding delay to the
> | interface (tc qdisc add dev lo root netem delay 1ms) and test again. And
> | it works ok now, no slowing down.
>
> So from what you wrote I read
>  * without additional delay the described problem occurs and CCID-3
>    gets into 1-packet-per-64-seconds mode
>  * when you add 1millisecond delay to the interface then it works ok.
>
That's exactly what I meant. After adding this 1ms delay I was not able to 
reproduce the bug. This does not mean it would not happen after long enough 
testing.

> You can plot the CCID-3 RTTs using dccp_probe, scripts are on
> http://www.erg.abdn.ac.uk/users/gerrit/dccp/testing_dccp/
>
> (at the bottom of the page).
See http://student.uci.agh.edu.pl/~grobelny/linux/outfile for raw dccp_probe 
data.
-- 
Regards,
Tomasz Grobelny

Re: dccp bugs (Was: Re: panic on 2.6.24rc5)

[Gerrit Renker]

[-- Attachment #1: Type: text/plain, Size: 4343 bytes --]

| > | And so I guess that this NET_XMIT_DROP should be ignored by dccp code?
| >
| > In the test tree it is now (almost) ignored. Since the time you reported
| > this problem I have changed the DCCP_BUG to a DCCP_WARN, so that the
| > drop will still be logged, but there will be fewer such warnings in the
| > log now (in DCCP_WARN, printk is rate-limited).
| >
| I'm not sure it should print the warning. Ok, it's nice to know that the 
| packet was dropped but:
| a) in real world there would be no such information,
| b) it's not something unusual for DCCP to lose packet without warning.
| Maybe it should only warn if debugging option is enabled?
| 
Ok that is a good point. What I will do is to change the DCCP_WARN() for
this error message to a dccp_pr_debug(), so that the message will only 
get printed for debugging purposes.


| > | >  * to avoid this, there is a kernel configuration option of CCID-3
| > | >    to set an upper bound for this.
| > |
| > | How do I set it?
| >
| > In the menu under
| >  Networking -> Network Options -> The DCCP Protocol (EXPERIMENTAL)
| >  -> DCCP CCIDs Configuration (EXPERIMENTAL) -> CCID3
| >  -> (100) Use higher bound for nofeedback timer
| > Ah - just remembered -- the default is 100 milliseconds, so this will
| > probably have caught the problems with the low RTT.
| >
| 100ms? Then it doesn't work as expected because adding just 1ms delay with 
| netem fixed the problem.
| If you meant 100us then it still doesn't work. Changing the parameter to 1000 
| delays the bug - I have to send more packets for it to happen.
| 
It is not as easy as that. This value determines a lower bound, in order
to cope with very low RTTs (i.e. less than 1 millisecond). What this
value changes is when the nofeedback timer is triggered. This is
normally max(4*RTT, 2*s/X), so a minimum of 4 RTT. But when RTTs are
low, it can happen that the nofeedback timer is triggered several times
between sending two frames (e.g. a VoIP inter-frame interval of 20ms). 
The configuration value sets a minimum lower bound of
	timeout = max(CONFIG_RTO_MIN, max(4*RTT, 2*s/X))
to cope with the problem of low RTTs.	

You are calling this a bug -- I think it is quite likely that CCID-3 is simply
not meant for the way you are using it. Please see below.


| > So from what you wrote I read
| >  * without additional delay the described problem occurs and CCID-3
| >    gets into 1-packet-per-64-seconds mode
| >  * when you add 1millisecond delay to the interface then it works ok.
| >
| That's exactly what I meant. After adding this 1ms delay I was not able to 
| reproduce the bug. This does not mean it would not happen after long enough 
| testing.
| 
Thanks for providing the dccp_probe data. I have had a look at it and it
is a bit as expected. The value of the RTT is:

   min: 3usec,  avg: 48.0 usec,  max: 4.513 msec;  with stddev of 324.68.
   
The loss was all the time 0, the receiver reported something like 1.8 kbps
(230 bytes per second).

The start-up behaviour is that there is a spike in the RTT where it
reaches its maximum right at the beginning (4.5 msec); this soon fades
out after the first 5 seconds, after which it reaches the average of 48
microseconds. This RTT is about 5..10 times less than a standard PC RTT
(250..500 microseconds).

Now I have a question: adding 1 ms delay at the interface avoided the
hang-up, but what do you mean by "long enough"? Is this 60 seconds?

I have attached the plot of the t_ipi which indeed climbs to
astronomical values after the initial period (when the RTT was low).

But since the average RTT is 48 microseconds in the `outfile', I am
assuming that the outfile was produced when the delay was not added to
the interface?

There is a long-standing problem (at least 1 year) with regard to CCID-3
over high-speed networks (and lo interface is in fact a high-speed
interface): high link speeds are outside the control region of CCID-3.

The peak limit of controllable speed is about 12 Mbps. Everything higher
that will cause problems. I have not tested, but you may be able to 
also silence this behaviour by using a netem token-bucket filter with
e.g. a maximum bitrate of <= 10 Mbps.


So I think the least thing we need to do is put a warning into the DCCP
Wiki that people should add interface delay when using CCID-3 for 
testing over loopback.

[-- Attachment #2: t_ipi.png --]
[-- Type: image/png, Size: 3952 bytes --]

Re: dccp bugs (Was: Re: panic on 2.6.24rc5)

[Tomasz Grobelny]

Dnia Monday 10 of March 2008, Gerrit Renker napisa³:
> Now I have a question: adding 1 ms delay at the interface avoided the
> hang-up, but what do you mean by "long enough"? Is this 60 seconds?
>
I tested it for something like 100 seconds and didn't encounter any problems.

> But since the average RTT is 48 microseconds in the `outfile', I am
> assuming that the outfile was produced when the delay was not added to
> the interface?
>
Yes, that's what I thought you asked me for...

> There is a long-standing problem (at least 1 year) with regard to CCID-3
> over high-speed networks (and lo interface is in fact a high-speed
> interface): high link speeds are outside the control region of CCID-3.
>
> The peak limit of controllable speed is about 12 Mbps. Everything higher
> that will cause problems. I have not tested, but you may be able to
> also silence this behaviour by using a netem token-bucket filter with
> e.g. a maximum bitrate of <= 10 Mbps.
>
I somehow doubt it because setting up tbf with limit greater than the actual 
traffic should have no influence at all. But let's check it...
sudo tc qdisc add dev lo root handle 1:0 tbf rate 30kbit burst 30kbit latency 
500ms

Still the speed drops down to 1 packet per 64 seconds.

> So I think the least thing we need to do is put a warning into the DCCP
> Wiki that people should add interface delay when using CCID-3 for
> testing over loopback.
Maybe CCID-3 could somehow disable itself when it detects it is not necessary?
-- 
Regards,
Tomasz Grobelny

Re: dccp bugs (Was: Re: panic on 2.6.24rc5)

[Ian McDonald]

2008/3/11 Tomasz Grobelny <tomasz@grobelny.oswiecenia.net>:
> Maybe CCID-3 could somehow disable itself when it detects it is not necessary?

That is an issue for the protocol designers, not the implementers...

I have had discussions around whether CCID3 is stable or not at high
speeds. I tend to think that it is and that we have a couple of bugs
lurking around. I got about 75% of the way through proving this but I
ran out of time.... So feel free to dive into kernel code.

Please note that I said 75% - my thoughts might be totally wrong as
didn't quite get to the bottom of it. If you go back about six months
to a year in the archives you might discover the discussion beteen
Gerrit and myself.

Ian
-- 
Web: http://wand.net.nz/~iam4/
Blog: http://iansblog.jandi.co.nz

Re: dccp bugs (Was: Re: panic on 2.6.24rc5)

[Gerrit Renker]

Hi Tomasz,

after quite some testing and calculations, my understanding of the
strange behaviour of CCID-3 over loopback is that it is due to the
combination of
 * an application-limited sender (ie. sending rate X_send < s/RTT);
 * very low RTT as compared to inter-packet gap;
 * frequent expiry of the nofeedback timer;
 * the particular interpretation of "idle periods" in rfc3448bis-00.

Hence as you pointed out, the Token Bucket Filter solution will indeed
not cure the problem. Artificially inflating the link RTT, on the other
hand, causes the computation of X to stabilise towards s/RTT.	

I have written up the causes etc. on 
http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ccid3/ccid3_over_loopback/

This was not easy to do and so I appreciate comments if there are any
errors or misinterpretations.

Gerrit

Quoting Tomasz Grobelny:
| Dnia Monday 10 of March 2008, Gerrit Renker napisa?:
| > Now I have a question: adding 1 ms delay at the interface avoided the
| > hang-up, but what do you mean by "long enough"? Is this 60 seconds?
| >
| I tested it for something like 100 seconds and didn't encounter any problems.
| 
| > But since the average RTT is 48 microseconds in the `outfile', I am
| > assuming that the outfile was produced when the delay was not added to
| > the interface?
| >
| Yes, that's what I thought you asked me for...
| 
| > There is a long-standing problem (at least 1 year) with regard to CCID-3
| > over high-speed networks (and lo interface is in fact a high-speed
| > interface): high link speeds are outside the control region of CCID-3.
| >
| > The peak limit of controllable speed is about 12 Mbps. Everything higher
| > that will cause problems. I have not tested, but you may be able to
| > also silence this behaviour by using a netem token-bucket filter with
| > e.g. a maximum bitrate of <= 10 Mbps.
| >
| I somehow doubt it because setting up tbf with limit greater than the actual 
| traffic should have no influence at all. But let's check it...
| sudo tc qdisc add dev lo root handle 1:0 tbf rate 30kbit burst 30kbit latency 
| 500ms
| 
| Still the speed drops down to 1 packet per 64 seconds.
| 
| > So I think the least thing we need to do is put a warning into the DCCP
| > Wiki that people should add interface delay when using CCID-3 for
| > testing over loopback.
| Maybe CCID-3 could somehow disable itself when it detects it is not necessary?
| -- 
| Regards,
| Tomasz Grobelny
| 
| 

-- 

Re: dccp bugs (Was: Re: panic on 2.6.24rc5)

[Gerrit Renker]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

Can you do me a favour and give the attached patch a try, on your virtual
environment: this is a simpler solution.

I have tested it on loopback and found that some of the instabilities
disappear when clamping the RTT to a minimum value.

Fixing this is important even if it is "only" loopback: the problem will
re-appear on other high-speed interfaces.

[-- Attachment #2: RTT-clamping patch (should apply on test tree as well as mainline) --]
[-- Type: text/x-diff, Size: 1154 bytes --]

[DCCP]: Ignory tiny RTTs

This lets DCCP ignore small RTT samples, by clamping all tiny values to 
a minimum of 100 microseconds.

The impetus for this patch was instabilities which were observed in conjunction
with small RTTs in the CCID-3 module.

The chosen minimum of 100 microseconds is open to suggestion - it would be
possible to chose a higher value, on the other hand it seems not worth making
the single value a Kconfig option.

Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
 net/dccp/input.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -710,15 +710,12 @@ u32 dccp_sample_rtt(struct sock *sk, lon
 	/* dccpor_elapsed_time is either zeroed out or set and > 0 */
 	delta -= dccp_sk(sk)->dccps_options_received.dccpor_elapsed_time * 10;
 
-	if (unlikely(delta <= 0)) {
-		DCCP_WARN("unusable RTT sample %ld, using min\n", delta);
+	if (unlikely(delta < DCCP_SANE_RTT_MIN))
 		return DCCP_SANE_RTT_MIN;
-	}
 	if (unlikely(delta > DCCP_SANE_RTT_MAX)) {
 		DCCP_WARN("RTT sample %ld too large, using max\n", delta);
 		return DCCP_SANE_RTT_MAX;
 	}
-
 	return delta;
 }
 

Re: dccp bugs (Was: Re: panic on 2.6.24rc5)

[Gerrit Renker]

With thanks to Cheng Wei, the bug reported by Tomasz on loopback
has now been resolved. The reason is that
 * the RFC4342 window counter algorithm (which uses RTT/4) does not work
   for RTTs < 4 microseconds with the current resolution of 1 microsecond
   in the Linux implementation (divide-by-zero);
 * as a result, the window counter does not change when RTT < 4 usec;
 * which causes the nofeedback timer to halve the sending rate until
   reaching s/t_mbi (1 packet in 64 seconds).

There were some errors in the analysis document on 

http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ccid3/ccid3_over_loopback/

(specifically section 3). These have been corrected, and a new version
has been uploaded.

With regard to the RTT-clamping patch: I have heard no report back from
Tomasz, but with the revised analysis I am sure that the bug will
disappear when clamping the RTT to values > 4 microseconds.

Although therefore clamping at 10 microseconds would be sufficient, I
still think that a greater value will be better. After all, the packet
scheduling is on the order of milliseconds.

Will post patch etc. early next week.

Gerrit

Re: dccp bugs (Was: Re: panic on 2.6.24rc5)

[Tomasz Grobelny]

Dnia Friday 14 of March 2008, Gerrit Renker napisa³:
> With regard to the RTT-clamping patch: I have heard no report back from
> Tomasz, but with the revised analysis I am sure that the bug will
> disappear when clamping the RTT to values > 4 microseconds.
Sorry for the delay, I was ill. Both your patches (applied separately) seem to 
fix the problem in my environment.
-- 
Regards,
Tomasz Grobelny

Mirror!!

[XMundo - Soporte Tecnico]

o the person responsible for managing the mirrors.

I have been sending messages for almost a month to the following emails:

coreteam@netfilter.org
webmaster@netfilter.org
netfilter-mirrors@lists.netfilter.org
solt@dns.toxicfilms.tv
laforge@netfilter.org

And I receive no answer to the request I'm making. 

Could you read netfilter-mirrors and make the change I'm asking you for?

Thanks for considering my message.

Regards.

Cristian Merz

Re: Mirror!!

[Maciej Soltysiak]

> I have been sending messages for almost a month to the following emails:
I've seen that.

> coreteam@netfilter.org
> webmaster@netfilter.org
> netfilter-mirrors@lists.netfilter.org
> solt@dns.toxicfilms.tv
> laforge@netfilter.org
>
> And I receive no answer to the request I'm making.
You see the problem is that there is one omnipotent do-lots-of-things
person: Harald Welte. He is doing a lot of things around the project
as the leader and it is possible that he did not find the time to log on
to the nameserver to correct the zone because he's munching code,
updating websites, holding conferences, doing his tasks at work, etc.
I (solt@dns.toxicfilms.tv) am only a participating user. I think
it'd be best just to keep mailing laforge@netfilter.org till you get
through.
(I hope that's fine with Harald)

Regards,
Maciej

Re: Mirror!!

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

On Thu, Feb 19, 2004 at 10:36:51AM -0300, XMundo - Soporte Tecnico wrote:
> o the person responsible for managing the mirrors.
> 
> I have been sending messages for almost a month to the following emails:
> 
> coreteam@netfilter.org
> webmaster@netfilter.org
> laforge@netfilter.org

mh, I don't remember seeing anything prominent in those two folders.
Maybe the subject made it look like spam ;(

> netfilter-mirrors@lists.netfilter.org

A typo in my mail-sync configuration file resulted in no mails from that
folder being transferred to my local imap repository.  I am now reading
all pending email in that folder.

> Could you read netfilter-mirrors and make the change I'm asking you for?

I'll respond to you seperately.

Sorry for any inconvenience.

> Regards.
> Cristian Merz

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mirror!!

[Andre Correa]

I know this is not the "right" place to ask but does that "call for 
volunteers" made on january got something going on? I've volunteered 
myself to maintain the links section but never got an answer and can't 
see anything new around...

Will there be another call later?

tks

Andre


Harald Welte wrote:
> On Thu, Feb 19, 2004 at 10:36:51AM -0300, XMundo - Soporte Tecnico wrote:
> 
>>o the person responsible for managing the mirrors.
>>
>>I have been sending messages for almost a month to the following emails:
>>
>>coreteam@netfilter.org
>>webmaster@netfilter.org
>>laforge@netfilter.org
> 
> 
> mh, I don't remember seeing anything prominent in those two folders.
> Maybe the subject made it look like spam ;(
> 
> 
>>netfilter-mirrors@lists.netfilter.org
> 
> 
> A typo in my mail-sync configuration file resulted in no mails from that
> folder being transferred to my local imap repository.  I am now reading
> all pending email in that folder.
> 
> 
>>Could you read netfilter-mirrors and make the change I'm asking you for?
> 
> 
> I'll respond to you seperately.
> 
> Sorry for any inconvenience.
> 
> 
>>Regards.
>>Cristian Merz
> 
>