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. Tha
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 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 2013-12-07 01:02, David Laight wrote:
On Fri, Dec 06, 2013 at 06:08:23PM +0100, Johnny Billquist wrote:
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 server (only other problems! :-)
I agree. I think i
On Fri, Dec 06, 2013 at 06:08:23PM +0100, Johnny Billquist wrote:
> >
> >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 server (only other problems! :-)
>
> I agree. I think it's nonsense. The idea that d
On 2013-12-05 13:14, matthew green wrote:
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
> > 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 nf
On 3 December 2013 22:45, David Laight 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 workers se
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 requ
On Dec 3, 2013, at 5:45 PM, David Laight 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 worke
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 workers serving requests. NFS, as
> mentioned above, is a fai
>> 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 re
Marc Balmer 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
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
Hi,
The question is not really kernel related. Possibly tech-userlevel@,
but neither it is related with NetBSD per se.
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()?
>
> I wrote simple mq sen
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 w
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, in
17 matches
Mail list logo
