James Smart wrote:
>
>
> Joe Eykholt wrote:
>> James Smart wrote:
>>> A round trip time with 1 second to spare. Pretty tight if E_D_TOV is
>>> accurate.
>>
>> But E_D_TOV is very conservative. A round trip time is a few
>> milliseconds.
>
> E_D_TOV is supposed to be the maximum round trip time, with 2s just the
> initial default. The switch/bridge , in conjunction with the fabric, is
> free to reduce it if the round trip is smaller. You're suggesting it
> didn't. If it's only a few milliseconds - it should have. This is what
> I meant by "if E_D_TOV is accurate", meaning, how close to reality is it...
Good point. Since the fabric may be configured with a tight E_D_TOV, then
we shouldn't assume it's always 2s which would be safe for a fairly big
fabric, even with some long-distance FCIP inter-switch links or something.
> As an endpoint has no idea where the other endpoint is on the fabric, it
> has to assume the maximum round trip time.
>
>>
>> The REC_TOV specifies how often to send an REC while the I/O is
>> outstanding, not how long to wait for the REC response.
>
> Yes - they are 2 independent things....
>
> What REC_TOV is really saying is - REC generation should be no faster
> than once a second + the time of an infinitely fast REC request/response.
I agree. We should change REC_TOV to be based on E_D_TOV + 1, but the
current 2s, while incorrect, is fairly safe. A patch for that
isn't urgent.
>>>> The FCP
>>>> standard requires minimum value for REC_TOV and as far as I can tell
>>>> there is no restriction on larger REC_TOV value, that means we could
>>>> choose higher values
>>> True - but I look at FC-LS as giving the recommendation for any ELS.
>>
>> There are really two timeouts here, one is how long we wait for an
>> I/O before sending a REC (REC_TOV) another is how long we wait
>> for the reply to the REC. The latter should be 2 * R_A_TOV,
>> according to FC-LS. A healthy target should reply right away, so
>> a longer timeout won't hurt anything.
>>
>> REC_TOV should be E_D_TOV + 1s as Vasu points out. It would usually
>> only come
>> into play for tape recovery on long ops. Longer timeouts could lead
>> to really long recovery times for dropped frames, and I think we want
>> to do REC before SCSI times out.
>
> It's found on places other than tape - but that is the predominant case.
>
> But - I agree with you. This is all grey, and as there is no 1 correct
> answer, what you choose depends on your devices, configuration, and
> what's important.
Since this is all on the thread from my patch submission, and
I haven't seen anything incorrect about my patch, I would think the patch
is OK as it is. It improves things but doesn't go as far as it could go.
Further patches could correct REC_TOV and REC timeouts.
Does this sound OK?
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
