Almost 80% of UDP packets dropped

Almost 80% of UDP packets dropped

[kernel coder]

hi,
    I was trying to measure the UDP reception speed on my borad which
has MIPS 4kc processor with 133 MHZ speed.I was transfering 10mb file
from intel pentium 4 machine to MIPS board,but the recieved file was
only 900kB.

When i further investigated the problem ,i came to know that the user
application was not getting enough opportunities to get data from
socket queue which caused almost 80% of packets to be dropped as
socket queue had no free space.

When i increased the socket recieve buffer size,it resulted in
increase in no. of packets recieved .When i slow slowed down the
transmitter , it also caused more packets to be recieved.

But the above mentioned mechanism only decreased no. of lost
packets.But there was no way that i could increase UDP reception speed
because the user application was not getting enough opportunities to
read packets in burst of UDP packets.

I noticed that user application started recieveing packets after
Kernel had recieved all the UDP packets.

Please tell me how can i make sure that user application or udp client
running MIPS 4kc processor gets enough opportunities to dequeue
packets from socket buffer so that lost of packets could be reduced to
minimal and also the size of UDP recieved file in a specific interval
of time could be increased.

lhrkernelcoder

Re: Almost 80% of UDP packets dropped

[Brett Foster]

kernel coder wrote:

>hi,
>    I was trying to measure the UDP reception speed on my borad which
>has MIPS 4kc processor with 133 MHZ speed.I was transfering 10mb file
>from intel pentium 4 machine to MIPS board,but the recieved file was
>only 900kB.
>  
>
UDP was not designed with reliability in mind -- it really isn't meant 
for sending a 10 meg file without a packet loss.

>When i further investigated the problem ,i came to know that the user
>application was not getting enough opportunities to get data from
>socket queue which caused almost 80% of packets to be dropped as
>socket queue had no free space.
>  
>
(Among other sources) I'm pretty sure this behaviour was discussed in:
Unix Network Programming, Vol. 1: The Sockets Networking API, Third Edition
(Something like page 257.)

I don't know if there is anything else going on with the kernel but...

Brett

Re: Almost 80% of UDP packets dropped

[Kevin D. Kissell]

What value of HZ are you using?  If you're still at the 2.6 default of 1000,
try reducing it to 100 and see if things improve...

----- Original Message ----- 
From: "kernel coder" <lhrkernelcoder@gmail.com>
To: <linux-mips@linux-mips.org>
Sent: Saturday, January 07, 2006 8:02 AM
Subject: Almost 80% of UDP packets dropped


> hi,
>     I was trying to measure the UDP reception speed on my borad which
> has MIPS 4kc processor with 133 MHZ speed.I was transfering 10mb file
> from intel pentium 4 machine to MIPS board,but the recieved file was
> only 900kB.
> 
> When i further investigated the problem ,i came to know that the user
> application was not getting enough opportunities to get data from
> socket queue which caused almost 80% of packets to be dropped as
> socket queue had no free space.
> 
> When i increased the socket recieve buffer size,it resulted in
> increase in no. of packets recieved .When i slow slowed down the
> transmitter , it also caused more packets to be recieved.
> 
> But the above mentioned mechanism only decreased no. of lost
> packets.But there was no way that i could increase UDP reception speed
> because the user application was not getting enough opportunities to
> read packets in burst of UDP packets.
> 
> I noticed that user application started recieveing packets after
> Kernel had recieved all the UDP packets.
> 
> Please tell me how can i make sure that user application or udp client
> running MIPS 4kc processor gets enough opportunities to dequeue
> packets from socket buffer so that lost of packets could be reduced to
> minimal and also the size of UDP recieved file in a specific interval
> of time could be increased.
> 
> lhrkernelcoder
> 
> 

Re: Almost 80% of UDP packets dropped

[Kevin D. Kissell]

What value of HZ are you using?  If you're still at the 2.6 default of 1000,
try reducing it to 100 and see if things improve...

----- Original Message ----- 
From: "kernel coder" <lhrkernelcoder@gmail.com>
To: <linux-mips@linux-mips.org>
Sent: Saturday, January 07, 2006 8:02 AM
Subject: Almost 80% of UDP packets dropped


> hi,
>     I was trying to measure the UDP reception speed on my borad which
> has MIPS 4kc processor with 133 MHZ speed.I was transfering 10mb file
> from intel pentium 4 machine to MIPS board,but the recieved file was
> only 900kB.
> 
> When i further investigated the problem ,i came to know that the user
> application was not getting enough opportunities to get data from
> socket queue which caused almost 80% of packets to be dropped as
> socket queue had no free space.
> 
> When i increased the socket recieve buffer size,it resulted in
> increase in no. of packets recieved .When i slow slowed down the
> transmitter , it also caused more packets to be recieved.
> 
> But the above mentioned mechanism only decreased no. of lost
> packets.But there was no way that i could increase UDP reception speed
> because the user application was not getting enough opportunities to
> read packets in burst of UDP packets.
> 
> I noticed that user application started recieveing packets after
> Kernel had recieved all the UDP packets.
> 
> Please tell me how can i make sure that user application or udp client
> running MIPS 4kc processor gets enough opportunities to dequeue
> packets from socket buffer so that lost of packets could be reduced to
> minimal and also the size of UDP recieved file in a specific interval
> of time could be increased.
> 
> lhrkernelcoder
> 
> 

Re: Almost 80% of UDP packets dropped

[Alan Cox]

On Gwe, 2006-01-06 at 23:02 -0800, kernel coder wrote:
> I noticed that user application started recieveing packets after
> Kernel had recieved all the UDP packets.

If your network chip/ram/processor combination is not fast enough to run
user space applications and handle a full speed network packet stream
then you either need to send more slowly, make the kernel network driver
more efficient or add some kind of interrupt/polling code to reduce
system load to avoid this. The NAPI layer in the networking code is
designed to make this possible.

Probably worth discussing further on netdev@oss.sgi.com

Alan