On 5/1/06, [email protected] <[email protected]> wrote:
> On Mon, 01 May 2006 00:26:05 CDT, Circuitsoft Development said:
> > about 600 microseconds, topped at 3msec over 10 minutes) I figure that
> > 5msec timeout won't add any noticeable lag to the volume manager, as
> > most disk seek times are in that range.
>
> Note that if you're setting 5ms as your timeout for detecting a *crash*,
> and your *ping* takes 3ms, that leaves you a whole whopping 2ms. If you
> have 1ms scheduler latency at *each* end (remember - you're in userspace
Volume/Lock manager in Kernelspace - Don't feel like dealing with
user-mode block devices
I was actually planning on a 5msec timeout to ignore that computer,
for now, then if I don't get a response within 100msec, ping them,
and permenantly remove them from the list of peers and broadcast a
"this peer is dead" message to the network if the ping times out at
500msec.
> at both ends, right?) you have approximately 0ms left for the remote end to
> actually *do* anything, and for the local end to process the reply.
>
> And if the remote end has to issue a syscall during processing the request,
> you're basically screwed.
The code on the remote end is checking a list of locks to see if a
block is in it.
On Mon, 1 May 2006, Circuitsoft Development wrote:
> I was actually planning on a 5msec timeout to ignore that computer,
> for now, then if I don't get a response within 100msec, ping them,
> and permenantly remove them from the list of peers and broadcast a
> "this peer is dead" message to the network if the ping times out at
> 500msec.
How are you going to prevent your "dead" peer from writing
to the disk anyway ?
--
All Rights Reversed