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... 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. > >>> 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. -- james _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
