On Thu, Oct 7, 2010 at 5:06 PM, Bruno Randolf <br1@xxxxxxxxxxx> wrote: > On Thu October 7 2010 15:51:49 Helmut Schaa wrote: >> On Thu, Oct 7, 2010 at 3:03 AM, Bruno Randolf <br1@xxxxxxxxxxx> wrote: >> > On Wed October 6 2010 18:54:37 Helmut Schaa wrote: >> >> On Tue, Oct 5, 2010 at 11:55 AM, Bruno Randolf <br1@xxxxxxxxxxx> wrote: >> >> > This adds three new values to the survey results: >> >> > >> >> > * BUSY - percentage of time the channel was busy >> >> > * BUSY_TX - percentage of time spent transmitting frames >> >> > * BUSY_RX - percentage of time spent receiving frames >> >> >> >> Does BUSY include BUSY_RX and BUSY_TX already? At least on >> >> rt2800 devices we only have access to BUSY which already includes >> >> BUSY_RX and TX. >> > >> > yes, BUSY includes TX and RX. >> > >> >> And what about BUSY on the secondary channel in case of 40Mhz? >> > >> > i have no information about that. luis? >> >> At least we've got a register for that in rt2800 ;) >> That's why I'm asking. > > which units do you have for the busy time? what about other drivers? > > in ath[59]k we have it as cycles (which is about 1/44000 of a second, > depending on the mode). so it counts up rather fast. > > i have been thinking more about it and i think my current approach is flawed. > the idea was that we probably need to use a percentage as the least common > denominator between all drivers, and i wanted to leave the time period up to > userspace. so if userspace wants to have the percentage in the last second, it > would poll every second, if it wants it every 100ms it would poll every 100ms. > that would work, if there is only one userspace process querying this in > regular intervals. > > but what if there is a second process who does the same, or a user issues "iw > wlan0 survey dump", that would reduce the timespan for the other process... so > that is obviously flawed... > > some absolute cumulative value would be better, so several userspace processes > can poll and do their own averaging or percentage calculations. > > but which units to use? what would be a good way of solving that? > any ideas??? My 2c: I do something similar with my work. I output the amount of time in tx & rx, as well as the 'measurement' time, being the elapsed time since it was read last (all in ms). If you get a timer to go off periodically (either ANI doing it, or something else if ANI is disabled), then the user can calculate the % if required, based on the elapsed time. Having a unit in ms seems to make the most sense as it will be driver/clock agnostic, and easily match up to frame txtimes if you wanted to de-construct the value further. > > bruno > -- Jonathan Guerin -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
