On Tue, 2005-06-14 at 09:36, Talpey, Thomas wrote: > At 08:41 AM 6/14/2005, Hal Rosenstock wrote: > >The current implementation is: > >1. address resolution phase for some amount of time > >followed by: > >2. dapl_ib_connect timeout * 5 (since there are 4 retries) > > > >A better algorithm would be to divide down the timeout by some number of > >retries (which would vary based on the timeout requested) and have the > >number of retries vary based on the total timeout requested. > > Why is address resolution exempt from the timeout? If the caller > wants a timeout, it should be independent of low-level link resolution. > Socket connect()s don't care about ARP, for example.
I was just stating the way the algorithm is right now. The address resolution phase can be included in the calculation but this complicates things a little. I thought it was previously said that the timeout can be approximate. Also, the CM timeouts are approximate and not precise either. > I don't like the idea of retry counts because there is no deterministic > length of time that they will take. Are you proposing that the number of retries be set to 0 then (regardless of the timeout requested) ? > Exponential backoff could drive > even a few retries to many minutes. Of course, if an IB provider > can guarantee that N retries will be performed in M seconds, then > okay, but not in general. The CM is not using exponential backoff. -- Hal _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
