On Sat, Dec 07, 2013 at 12:38:42AM +0100, Johnny Billquist wrote:
You know, you might also hit a different problem, which I have had on
many occasions.
NFS using 8k transfers saturating the ethernet on the server, making the
server drop IP fragemnts. That in turn force a resend of the
On 2013-12-07 20:51, David Laight wrote:
On Sat, Dec 07, 2013 at 12:38:42AM +0100, Johnny Billquist wrote:
You know, you might also hit a different problem, which I have had on
many occasions.
NFS using 8k transfers saturating the ethernet on the server, making the
server drop IP fragemnts.
On Sat, Dec 07, 2013 at 12:02:02AM +, David Laight wrote:
I believe that the disk driver on the server selected the disk transfers
using the 'elevator' algorithm. Since the writes were for more or less
sequential sectors, as soon as they got out of sequence one of the write
requests
On 3 December 2013 22:45, David Laight da...@l8s.co.uk wrote:
On Tue, Nov 26, 2013 at 01:32:44PM -0500, Mouse wrote:
When serving a request takes nontrivial time, and multiple requests can
usefully be in progress at once, it is useful - it typically improves
performance - to have multiple
Run a single nfsd and it all works much better.
On that basis should the NetBSD default be changed from -n 4?
i definitely would object to such a change.
i see slowness from multiple clients when i run nfsd with just
one thread. i've never seen the problem dsl has seen with a
netbsd nfs
da...@l8s.co.uk (David Laight) writes:
But what tends to happen is that the disk 'elevator' algorithm makes
one of the server process wait ages for its disk access to complete,
by which time the client has timed out and resubmitted the RPC request.
The NFS client does not resubmit the RPC
What is the prupose or reasoning behind the fact that multiple processes
can open a message queue for reading using mq_open()?
I wrote simple mq sender and mq receiver programs; when I start multiple
receivers on the same mq, and send a message to it, only one of the
receivers gets the message,
On Tue, Nov 26, 2013 at 09:39:44AM +0100, Marc Balmer wrote:
What is the prupose or reasoning behind the fact that multiple processes
can open a message queue for reading using mq_open()?
You can dispatch messages from one producer to several workers (one
writer, multiple readers), or inject
Hi,
The question is not really kernel related. Possibly tech-userlevel@,
but neither it is related with NetBSD per se.
Marc Balmer m...@msys.ch wrote:
What is the prupose or reasoning behind the fact that multiple processes
can open a message queue for reading using mq_open()?
I wrote
Am 26.11.13 15:13, schrieb Mindaugas Rasiukevicius:
Hi,
The question is not really kernel related. Possibly tech-userlevel@,
but neither it is related with NetBSD per se.
I asked here because it is implemented in the kernel and because what I
see might as well be a buglet (given that aio
Marc Balmer m...@msys.ch wrote:
Am 26.11.13 15:13, schrieb Mindaugas Rasiukevicius:
Hi,
The question is not really kernel related. Possibly tech-userlevel@,
but neither it is related with NetBSD per se.
I asked here because it is implemented in the kernel and because what I
see
Why do you think it is meant to connect only two processes? It is
[...] just a FIFO queue of messages. [...]
So what is the purpose of those interface? When I inject a message,
I don't know which of the possibly many receivers is getting it?
Right. To rephrase that, when I make a request,
12 matches
Mail list logo
