On Sun, Feb 08, 2009 at 09:58:23PM +0000, Dieter wrote:
> > > > Grepping through a few log files, the userland program read 44,751,896
> > > > bytes
> > > > with a single syscall. The default recv buf size of 65536 doesn't get
> > > > the
> > > > job done for this application.
OK, I'll take the bite. The following scenario might apply to your
userland app:
If your userland program has a very big buffer, it probably takes a
while to process it once the read(2) call succeeds. In the meantime
new data arrives (which might be dropped on the floor if the sending
side does not back off quickly enough because of lack of acks): the
kernel buffer fills up to the maximum receive size, and the userland
buffer is not available because the new read call has not been issued
yet.
Not until now you have just given us vague assumptions and jump to
conclusion statements without almost no facts about your app, so of
course we jump the gun and bash you.
If you expect us to help to solving a problem provide details, and not
conclusions.
> You have no clue if my userland app is well behaved or not. And there IS a
> problem if another driver locks the Ethernet driver out for too long. I
> hunted down and beat into submission an example of that problem recently.
See above. Until you give us details these statements have not useable
content.
>
> > > Our socket buffers will never allow that amount of memory to be queued.
> >
> > I think Claudio doesn't know that Step 1 in "solving" userland
> > throughput problems is to blame it on the kernel, hardware, drivers or
> > actually anything except the application?
>
> Learn to read. It is a latency problem, not a throughput problem.
See above.
>
> > And I see the alternative "all my problems would be solved if OpenBSD
> > had feature X (in this case real-time support)" is also used, so extra
> > bonus points!
>
> Learn to read. I haven't tried it on OpenBSD yet, just FreeBSD and NetBSD.
See above.
> Geez, ask an innocent question and suddenly get accused of not understanding
> anything. By people that didn't bother to read and clearly don't understand
> the problem.
If anything, we do not understand the problem BECAUSE you are not
giving details.
-Otto
