I've found a very strange bug in linux ppc 2.4.17, I think. I'm pulling
udp packets off the LAN and reading them in a user space program. They come
in sets of about 60k bytes all together, then pause for a while. I only can
read the first 48k successfully, then they get lost.
If I have a setsockopt call on the socket, setting SO_RCVBUF to 65535,
then I don't lose any data. But if I do a getsockopt beforehand on
SO_RCVBUF, it reports 65535. Without the setsockopt I get the packet loss,
with it I don't lose any. It is strange because the value doesn't appear
to be changing.
What can be causing this mysterious behaviour?
-Dave
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
This is just a guess, but is SO_RCVLOWAT getting set somewhere? The receive
call will block until it gets the number of bytes set with this option. I
think it defaults to 1, so it should normally return when any data is
available on the socket. But if it has been bumped up to a big number, it
might account for the behavior you're seeing.
-Josh
David Ashley wrote:
I've found a very strange bug in linux ppc 2.4.17, I think. I'm pulling
udp packets off the LAN and reading them in a user space program. They come
in sets of about 60k bytes all together, then pause for a while. I only can
read the first 48k successfully, then they get lost.
If I have a setsockopt call on the socket, setting SO_RCVBUF to 65535,
then I don't lose any data. But if I do a getsockopt beforehand on
SO_RCVBUF, it reports 65535. Without the setsockopt I get the packet loss,
with it I don't lose any. It is strange because the value doesn't appear
to be changing.
What can be causing this mysterious behaviour?
-Dave
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/