headers
kuznet | 2 Jan 2003 02:38
Picon

Re: snd_cwnd drawn and quartered

Hello!

> 	if (decr && tp->snd_cwnd > tp->snd_ssthresh/2)
> 		tp->snd_cwnd -= decr;
> 
> Unfortunately, snd_ssthresh has already been halved at this
> point, so the test actually does nothing.

It does the thing which it is supposed to do: prevents reducing cwnd below
1/4 of original one. This was proposed in one of rete-halving related drafts
with title sort of "...boundary checks...", I forgot exact title, can find
it if you are curious.

> 	if (decr && tp->snd_cwnd > tp->snd_ssthresh)

Maybe this is even correct, but I do not see why it can be essential.
cwnd falls too low not due to decrementing due to rate-halving,
but due to draining out in_flight when we are not able to keep pipe full.
Please, show. 

Alexey
Permalink | Reply | 13 comments |
headers
Werner Almesberger | 2 Jan 2003 07:08
Favicon

Re: snd_cwnd drawn and quartered

kuznet <at> ms2.inr.ac.ru wrote:
> It does the thing which it is supposed to do: prevents reducing cwnd below
> 1/4 of original one.

Okay, this it does. I guess the only case where this would make a
difference is if your network duplicates packets.

> This was proposed in one of rete-halving related drafts
> with title sort of "...boundary checks...", I forgot exact title, can find
> it if you are curious.

I searched around but didn't spot anything. A pointer would be
welcome, thanks !

> Maybe this is even correct, but I do not see why it can be essential.
> cwnd falls too low not due to decrementing due to rate-halving,
> but due to draining out in_flight when we are not able to keep pipe full.

Yes, but rate-halving is what causes in-flight to drop in the first
place (assuming we have enough fresh data to send, of course), no ?

> Please, show. 

I've put graphs of a simulation run (with and without the change) at
http://www.almesberger.net/misc/half.eps
http://www.almesberger.net/misc/quarter.eps

Y-axis is in segments, x-axis is in some arbitrary time unit, RTT is
one initial cwnd (100 packets), path is asymmetric with zero-delay
and loss-less backward channel. (While unusual, this shouldn't
(Continue reading)

Permalink | Reply | 12 comments |
headers
Werner Almesberger | 2 Jan 2003 09:31
Favicon

Re: snd_cwnd drawn and quartered

I wrote:
> Okay, this it does. I guess the only case where this would make a
> difference is if your network duplicates packets.

... and, of course, when losing retransmitted segments, oops.

- Werner

--

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa <at> almesberger.net /
/_http://www.almesberger.net/____________________________________________/
Permalink | Reply | 0 comments |
headers
Steffen Persvold | 2 Jan 2003 14:06

One-way Gigabit Ethernet TCP performance with Jumbo frames

Hi all,

Lately I've been testing out two Gigabit Ethernet adapters on Pentium 4 
Xeon platforms; onboard Intel 82544GC (e1000 driver) and onboard Broadcom 
BCM5701 (tg3 driver), and I'm experiencing some wierd behaviour on 
one-way tests (ping-ping). The machines I'm testing is connected back to 
back (i.e no switch) and are fairly fast systems (Dual Xeon 2.4 GHz, 1GB 
memory) configured to use Jumbo frames (9000 bytes).

With ping-pong traffic (the attached program run with -bo, or NetPipe 
default) the bandwidth performance is close to wire speed (123 MByte/sec) 
and the ping-pong/2 latency is ~30us with both GbE devices.

But, when running a one-way test (where one machine only sends, and the 
other only receives, i.e ping-ping) there is a serious dip in the 
performance curve at ~768 bytes and the bandwidth levels out at approx 
60 MByte/sec (about half of peak) regadless of application and GbE device. 

However, if the benchmark applications are started at 2048 bytes (and not 
0 which is default), or the MTU is set to standard 1500 bytes, there is no 
such "dip" in the performance curve.

Is there a new "silly window" syndrome going on here ? Both applications 
use TCP_NODELAY.

I'll appreciate any feedback, and I'm happy to assist in the debugging 
process testing out patches etc.

PS
(Continue reading)

Permalink | Reply | 0 comments |
headers
ramarayalu vattikuti | 2 Jan 2003 17:55
Picon
Favicon

Need u r help

Hi,

This is RamaRayalu Vattikuti .

Now i am doing my M.Tech project work on device
drivers.

operating system is linux.

my project :

      1.with PCI-DPM card we can provide the
communication between two processing elements in a
parallel processing system.

       2.the same thing can be done with ethernet card
also.

   here i had given this problem to solve.

   can we develop a virtual device so that it invokes
the two devices i mentioned above.

if u know any  idea please mail me soon.

 thanks&regards

 rayalu

__________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Werner Almesberger | 2 Jan 2003 22:26
Favicon

Re: snd_cwnd drawn and quartered

I wrote:
> I searched around but didn't spot anything. A pointer would be
> welcome, thanks !

I think I found it. Is it "The Rate-Halving Algorithm for TCP Congestion
Control", section 5.14, "Application of Bounding Paremeters" (sic!) ?
http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt

- Werner

--

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa <at> almesberger.net /
/_http://www.almesberger.net/____________________________________________/
Permalink | Reply | 0 comments |
headers
Leonard mckinley | 2 Jan 2003 22:43
Picon
Favicon

Jumbograms

Do any IPv6 implementations compatible with the Linux kernel
support Jumbograms? 

For example: on a UDP IPv6 socket, this:

  sendto ( s, buf, 65537, 0, addr, addr_len )

wouldn't fail.

Thanks,

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Permalink | Reply | 0 comments |
headers
Gao XiaoPeng | 3 Jan 2003 09:56
Picon

(unknown)

hello,

one of my friends wants to discuss a netfilter problem with
you! thx!

-------------------------------------------------------------
hi,
    I am a student, I think that skb has all the information 
that is needed for sending and receiving.So I get the skb 
pointer at NF_IP_POST_ROUTING, put it in a chain  organized 
by myself (I use a spinlock_t  lock to control the access of 
the chain, I named it mylock), and return NF_STOLEN. 
  I make a  tq_timer task to start ip_finish_output2(I export 
it from kernel),ip_finish_output2 use the skb from my chain.I 
can make ftp run ok for almost 1 hour, but then the system will 
carsh with this information:

        ds:0018    es:0018    ss:0018
        process swapper(pid:0, stackpage = c0265000)
        stack: c01a07ea c173a088 ...........
        call trace:[<c01a07ea>]    [<c01a156d>]......
        code: 0f 0b 89 7c 24 04 b8 03 00 00 00......
        <0>kernel panic: Aiee, killing interrupt handler!
        In interrupt handler - not syncing!

     I want to know why I count run for some time but could not 
go on for a long time . Does it possible to transmit data by the 
way and how to do?thanks very much!

best regard
(Continue reading)

Permalink | Reply | 1 comment |
headers
ZHAO Wei | 3 Jan 2003 11:11

Re:

>     I am a student, I think that skb has all the information 
> that is needed for sending and receiving.So I get the skb 
> pointer at NF_IP_POST_ROUTING, put it in a chain  organized 
> by myself (I use a spinlock_t  lock to control the access of 
> the chain, I named it mylock), and return NF_STOLEN. 
>   I make a  tq_timer task to start ip_finish_output2(I export 
> it from kernel),ip_finish_output2 use the skb from my chain.I 
> can make ftp run ok for almost 1 hour, but then the system will 
> carsh with this information:
>  
>         ds:0018    es:0018    ss:0018
>         process swapper(pid:0, stackpage = c0265000)
>         stack: c01a07ea c173a088 ...........
>         call trace:[<c01a07ea>]    [<c01a156d>]......
>         code: 0f 0b 89 7c 24 04 b8 03 00 00 00......
>         <0>kernel panic: Aiee, killing interrupt handler!
>         In interrupt handler - not syncing!

You could try ksymoops to get some more info from the above. You
will get a call trace and that will reveal.
Permalink | Reply | 0 comments |
headers
Robert Olsson | 3 Jan 2003 14:25
Picon
Picon

One-way Gigabit Ethernet TCP performance with Jumbo frames


Steffen Persvold writes:
 > Hi all,
 > 
 > Lately I've been testing out two Gigabit Ethernet adapters on Pentium 4 
 > Xeon platforms; onboard Intel 82544GC (e1000 driver) and onboard Broadcom 
 > BCM5701 (tg3 driver), and I'm experiencing some wierd behaviour on 
 > one-way tests (ping-ping). The machines I'm testing is connected back to 
 > back (i.e no switch) and are fairly fast systems (Dual Xeon 2.4 GHz, 1GB 
 > memory) configured to use Jumbo frames (9000 bytes).

 > But, when running a one-way test (where one machine only sends, and the 
 > other only receives, i.e ping-ping) there is a serious dip in the 
 > performance curve at ~768 bytes and the bandwidth levels out at approx 
 > 60 MByte/sec (about half of peak) regadless of application and GbE device. 

 I've seen similar problems... and most of the times this seems due to 
 incorrect tuned mitigation. Think of what happens if you don't have TX-
 interrupts enough to clean your TX-ring. Which means your app. can not
 fill it at full speed -- and as long you have RX traffic it contributes 
 with interrupts so the problem is not visile. 

 If you test IP-forwarding with RX soly on one interface and TX soly on the
 other and routing between them. You'll see drops at the qdisc in such case.

 Cheers.
						--ro
Permalink | Reply | 0 comments |

Gmane