* BUG: udp socket, getsockopt + setsockopt
@ 2002-01-29 16:49 David Ashley
2002-01-29 16:58 ` Josh Horvath
2002-01-30 0:05 ` Val Henson
0 siblings, 2 replies; 6+ messages in thread
From: David Ashley @ 2002-01-29 16:49 UTC (permalink / raw)
To: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BUG: udp socket, getsockopt + setsockopt
2002-01-29 16:49 David Ashley
@ 2002-01-29 16:58 ` Josh Horvath
2002-01-30 0:05 ` Val Henson
1 sibling, 0 replies; 6+ messages in thread
From: Josh Horvath @ 2002-01-29 16:58 UTC (permalink / raw)
To: David Ashley; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BUG: udp socket, getsockopt + setsockopt
2002-01-29 16:49 David Ashley
2002-01-29 16:58 ` Josh Horvath
@ 2002-01-30 0:05 ` Val Henson
1 sibling, 0 replies; 6+ messages in thread
From: Val Henson @ 2002-01-30 0:05 UTC (permalink / raw)
To: David Ashley; +Cc: linuxppc-embedded
When you set SO_RCVBUF with setsockopt, the kernel allocates twice the
memory you set. This has something to do with BSD compatibility and
storing internal kernel structures in the memory allocated for the
recv buf. Try getsockopt after you setsockopt.
This is ostensibly a feature, not a bug. Search the linux-kernel
archives for "so_rcvbuf" and "David Miller". Hint: you probably won't
convince Dave to change his mind.
-VAL
On Tue, Jan 29, 2002 at 08:49:02AM -0800, 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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BUG: udp socket, getsockopt + setsockopt
@ 2002-01-30 3:22 David Ashley
0 siblings, 0 replies; 6+ messages in thread
From: David Ashley @ 2002-01-30 3:22 UTC (permalink / raw)
To: Josh_Horvath-AJH051; +Cc: linuxppc-embedded
That's not getting set anywhere, the socket code is really small, just
like a textbook example. The man page says that is read only...
-Dave
>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
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BUG: udp socket, getsockopt + setsockopt
@ 2002-01-30 3:26 David Ashley
2002-01-30 3:41 ` Val Henson
0 siblings, 1 reply; 6+ messages in thread
From: David Ashley @ 2002-01-30 3:26 UTC (permalink / raw)
To: val; +Cc: linuxppc-embedded
I forgot to mention it doesn't act the same on my x86 desktop running
linux. I don't recall what version. On my pc there is no trouble.
Oh well.
Thanks--
Dave
>When you set SO_RCVBUF with setsockopt, the kernel allocates twice the
>memory you set. This has something to do with BSD compatibility and
>storing internal kernel structures in the memory allocated for the
>recv buf. Try getsockopt after you setsockopt.
>
>This is ostensibly a feature, not a bug. Search the linux-kernel
>archives for "so_rcvbuf" and "David Miller". Hint: you probably won't
>convince Dave to change his mind.
>
>-VAL
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: BUG: udp socket, getsockopt + setsockopt
2002-01-30 3:26 David Ashley
@ 2002-01-30 3:41 ` Val Henson
0 siblings, 0 replies; 6+ messages in thread
From: Val Henson @ 2002-01-30 3:41 UTC (permalink / raw)
To: David Ashley; +Cc: linuxppc-embedded
I'm not sure what version this change appeared. Also, your pc may
have different default socket size settings. This command will show
you both the max and default settings:
cat /proc/sys/net/core/?mem_*
(You can also set them in the usual way.)
-VAL
On Tue, Jan 29, 2002 at 07:26:56PM -0800, David Ashley wrote:
>
> I forgot to mention it doesn't act the same on my x86 desktop running
> linux. I don't recall what version. On my pc there is no trouble.
> Oh well.
>
> Thanks--
> Dave
>
> >When you set SO_RCVBUF with setsockopt, the kernel allocates twice the
> >memory you set. This has something to do with BSD compatibility and
> >storing internal kernel structures in the memory allocated for the
> >recv buf. Try getsockopt after you setsockopt.
> >
> >This is ostensibly a feature, not a bug. Search the linux-kernel
> >archives for "so_rcvbuf" and "David Miller". Hint: you probably won't
> >convince Dave to change his mind.
> >
> >-VAL
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-01-30 3:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-01-30 3:22 BUG: udp socket, getsockopt + setsockopt David Ashley
-- strict thread matches above, loose matches on Subject: below --
2002-01-30 3:26 David Ashley
2002-01-30 3:41 ` Val Henson
2002-01-29 16:49 David Ashley
2002-01-29 16:58 ` Josh Horvath
2002-01-30 0:05 ` Val Henson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).