On 10/29/12 at 04:22pm, Vlad Yasevich wrote: > On 10/29/2012 07:37 AM, Neil Horman wrote: > >Hm, ok, looking for the maximum rto seen is definately more efficient that a > >high polling rate on the remaddr file. Still can't say I really like it as a > >statistic though. While it helps in diagnosing a very specific type of problem > >(applications that have a maximum allowable latency), its really not useful, and > >potentially misleading, in the general case. Specificaly it may show a very > >large RTO even if that RTO was an erroneous spike in behavior earlier in the > >lifetime of a given transport, even if that RTO is not representative of the > >current behavior of the association. It seems to me like this stat might be > >better collected using a stap script or by adding a trace point to > >sctp_transport_update_rto. If the application needs to know this information > >internally during its operation to take corrective action, you can already get > >it via the SCTP_GET_PEER_ADDR_INFO socket option on a per transport basis just > >as efficiently. SCTP_GET_PEER_ADDR_INFO doesn't help here as the whole point of this stat is to get max(rto) as seen by the SCTP stack. > The max_rto is reset after each getsockopt(), so in effect, the > application sets its own polling interval and gets the max rto > achieved during it. If the rto hasn't changed, then the last value > is returned. Not sure how much I like that. I would rather get max > rto achieved per polling period and upon reset, max_rto is > accumulated again (easy way to do that is set to rto_min on reset). > This way an monitoring thread can truly represent the max rto > reported by association. It should normally remain steady, but this > will show spikes, if any. I would still reset it to 0 but I agree that it makes more sense to return 0 if max(rto) remains unchanged within the observation period rather than returning the previous max(rto). -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
