Increasing UDP Recieve Buffers

Hi, My application needs to read UDP packets which are coming at a
rate of about 50Hz. (For 1 or 2 second bursts). When I examine what
has been recieved, I see holes of missing data, perhaps 10 missing
packets per second.

I believe the problem is that my (C#) synchronous UDP client cannot
reliably Recieve() from the socket at that rate, even at the highest
priority, even with the most minimal overhead.

Is there a way to increase the size of the recieve buffer for my
socket so that the tcp/ip stack doesn't discard packets when my
application gets delayed? (I know TCP would be better, but it's not
an option)

Thanks

Chad
Thu Jan 22 19:53:32 CST 2004

cgrebeld@hotmail.com (Chris G) wrote in news:74c403e9.0401221743.39c505c1
@posting.google.com:
> Hi, My application needs to read UDP packets which are coming at a
> rate of about 50Hz. (For 1 or 2 second bursts). When I examine what
> has been recieved, I see holes of missing data, perhaps 10 missing
> packets per second.
>
> I believe the problem is that my (C#) synchronous UDP client cannot
> reliably Recieve() from the socket at that rate, even at the highest
> priority, even with the most minimal overhead.

50Hz should not be a problem for fetching the packets. By CPU standards that
is quite low.

What are you doing when you receive the packets? Have you considered just
grabbing them in a thread and queing them and letting another thread process
the queue?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

William
Thu Jan 22 20:01:52 CST 2004

Have you tried NetMon (or other) to verify the packets are making it to your
listener?

--
William Stacey, MVP

"Chris G" <cgrebeld@hotmail.com> wrote in message
news:74c403e9.0401221743.39c505c1@posting.google.com...
> Hi, My application needs to read UDP packets which are coming at a
> rate of about 50Hz. (For 1 or 2 second bursts). When I examine what
> has been recieved, I see holes of missing data, perhaps 10 missing
> packets per second.
>
> I believe the problem is that my (C#) synchronous UDP client cannot
> reliably Recieve() from the socket at that rate, even at the highest
> priority, even with the most minimal overhead.
>
> Is there a way to increase the size of the recieve buffer for my
> socket so that the tcp/ip stack doesn't discard packets when my
> application gets delayed? (I know TCP would be better, but it's not
> an option)
>
> Thanks

Feroze
Mon Jan 26 19:50:25 CST 2004

Remember that UDP is not a guaranteed delivery mechanism. Packets could be
discarded (even if you are doing loopback) at any time. I dont know what
kind of "holes" you are seeing, but this could explain any loss of packets
that you see.

--
Remove "user" from the email address to reply to the author.

This posting is provided "AS IS" with no warranties, and confers no rights

Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm




"Chris G" <cgrebeld@hotmail.com> wrote in message
news:74c403e9.0401221743.39c505c1@posting.google.com...
> Hi, My application needs to read UDP packets which are coming at a
> rate of about 50Hz. (For 1 or 2 second bursts). When I examine what
> has been recieved, I see holes of missing data, perhaps 10 missing
> packets per second.
>
> I believe the problem is that my (C#) synchronous UDP client cannot
> reliably Recieve() from the socket at that rate, even at the highest
> priority, even with the most minimal overhead.
>
> Is there a way to increase the size of the recieve buffer for my
> socket so that the tcp/ip stack doesn't discard packets when my
> application gets delayed? (I know TCP would be better, but it's not
> an option)
>
> Thanks

cgrebeld
Tue Jan 27 09:39:50 CST 2004

I realize UDP is not guaranteed, but I am wondering if there is some
way to tweak the algorithm Windows uses for discarding packets so that
I can be 99% certain that my packets won't get discarded on the
recieving end. IE. number of spots in a recieve queue or some kind of
timeout value.

Is there some registry keys or something that can be modified for this
purpose?



"Feroze [MSFT]" <ferozed@online.microsoft.com> wrote in message news:<#YgSDgH5DHA.1936@TK2MSFTNGP12.phx.gbl>...
> Remember that UDP is not a guaranteed delivery mechanism. Packets could be
> discarded (even if you are doing loopback) at any time. I dont know what
> kind of "holes" you are seeing, but this could explain any loss of packets
> that you see.
>
> --
> Remove "user" from the email address to reply to the author.
>
> This posting is provided "AS IS" with no warranties, and confers no rights
>
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
>
>
> "Chris G" <cgrebeld@hotmail.com> wrote in message
> news:74c403e9.0401221743.39c505c1@posting.google.com...
> > Hi, My application needs to read UDP packets which are coming at a
> > rate of about 50Hz. (For 1 or 2 second bursts). When I examine what
> > has been recieved, I see holes of missing data, perhaps 10 missing
> > packets per second.
> >
> > I believe the problem is that my (C#) synchronous UDP client cannot
> > reliably Recieve() from the socket at that rate, even at the highest
> > priority, even with the most minimal overhead.
> >
> > Is there a way to increase the size of the recieve buffer for my
> > socket so that the tcp/ip stack doesn't discard packets when my
> > application gets delayed? (I know TCP would be better, but it's not
> > an option)
> >
> > Thanks

Chad
Tue Jan 27 09:55:17 CST 2004

cgrebeld@hotmail.com (Chris G) wrote in
news:74c403e9.0401270739.2c783436@posting.google.com:
> I realize UDP is not guaranteed, but I am wondering if there is some
> way to tweak the algorithm Windows uses for discarding packets so that
> I can be 99% certain that my packets won't get discarded on the
> recieving end. IE. number of spots in a recieve queue or some kind of
> timeout value.

You can increase the TCP buffer size. I havent tried it with UDP.

However its a Winsock option, not sure if System.net.sockets exposes this.

As I said previously what you need to do is have one thread just plucking
packets. It then stores them in a queue for other threads to actually process
and handle whatever the action is that you want.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

William
Tue Jan 27 10:46:16 CST 2004

You do it at the socket level. If you using UdpClient, you need to derive
from UdpClient to get access to the protected Client (socket) object. Then
you can create a method like:

public int ReceiveSize
{
get
{

return (int)this.Client.GetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReceiveBuffer);
}
set
{
if ( value < 0 )
throw new ArgumentOutOfRangeException("ReceiveSize", value, "Invalid
size.");
Socket s = this.Client;
s.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReceiveBuffer, value);
}
}

Not sure changing buffer size will fix your issue. Are you binding multiple
sockets to the same IP by chance?

--wjs

cgrebeld
Tue Feb 03 09:44:11 CST 2004

Even with large recieve buffers, I found that I had the same problems.
But hypothetically, even if I had been able to recieve all packets
with larger buffers, I think the solution is inherently bad since it
won't scale to higher throughputs. So I built in some primitive flow
control logic instead. So far my sending queue has grown to a maximum
of 27 packets at the 50Hz rate, with the occasional timeout-resend. I
don't know where the drops were happening, but it works great now =)
Thanks for the advice.

Chris G



cgrebeld@hotmail.com (Chris G) wrote in message news:<74c403e9.0401221743.39c505c1@posting.google.com>...
> Hi, My application needs to read UDP packets which are coming at a
> rate of about 50Hz. (For 1 or 2 second bursts). When I examine what
> has been recieved, I see holes of missing data, perhaps 10 missing
> packets per second.
>
> I believe the problem is that my (C#) synchronous UDP client cannot
> reliably Recieve() from the socket at that rate, even at the highest
> priority, even with the most minimal overhead.
>
> Is there a way to increase the size of the recieve buffer for my
> socket so that the tcp/ip stack doesn't discard packets when my
> application gets delayed? (I know TCP would be better, but it's not
> an option)
>
> Thanks