On Monday, 21 May 2018 21:46:57 HKT Linus Lüssing wrote: > On Fri, May 18, 2018 at 09:47:54AM +0800, Marek Lindner wrote: > > When the ELP throughput meter fallback kicks in to trigger > > a throughput meter measurement the test duration can be > > configured via this attribute. > > > > Default tp test duration: 1000ms > > Would it make sense to note the adjusted default tp test duration > in the commit message, too? It is adjusted from 10ms to 1000ms > here, right? I am having a hard time following your thoughts here. The default duration is part of the commit message. The user space tp meter test is not affected by this change. The tp meter ELP duration of 10ms default was introduced in the previous patch only. Anyway, will change the previous patch to use 1000ms. > I'm also wondering if it would make sense to make the test > interval adjustable instead of the duration: > > With 1000ms on a 16MBit/s DSL line this would generate 864GB of > traffic per month and would be an issue for several existing > setups right now. Assuming you are talking about the batman-adv-over-VPN-over-internet use-case: Simply set the interface throughput to 16MBit/s to disable the ELP throughput meter measuring altogether (see throughput_override). ELP throughput measuring is not built to improve that use-case. > Is there some minimum test duration at which the tp meter is > supposed to not work realiably anymore, where an increased check > period would be more suitable? The ELP throughput meter test is designed to handle interface / neighbors with fluctuating link throughput. For those setups, having up-to-date link throughput information is what makes this worthwhile. Static DSL uplinks don't fall into that category. Every regular throughput check (no matter how rare) is worse than no test at all. To handle those case, batman-adv already provides a knob. Cheers, Marek