|  10:13  |  topi`>  |   jnettlet[m]: what kind of config do you have for hostapd to get 500Mbit/s rx/tx speeds? you'd have to enable VHT flags to get 802.11ac speeds  | 
|  10:14  |  topi`>  |   thus, you need channels 36-60 and probably 40mhz/80mhz wide channels  | 
|  10:14  |  topi`>  |   on my HB, the bloody driver/firmware/something prohibits the use of channels 36-60  | 
|  10:14  |  topi`>  |   so I only run it at 2.4ghz  | 
|  10:21  |  jnettlet[m]>  |   topi`: one second let me grab it.  | 
|  10:22  |  jnettlet[m]>  |   You need to make sure and set the region to EU.  I  | 
|  10:24  |  jnettlet[m]>  |   topi`: https://pastebin.com/iR7ENNS9  | 
|  10:26  |  topi`>  |   that's probably my pain point. The Compex card reports World domain  | 
|  10:26  |  jnettlet[m]>  |   most likely yes  | 
|  10:26  |  topi`>  |   so no matter what I try to do at user-space, it keeps on disabling those channels  | 
|  10:26  |  jnettlet[m]>  |   topi`: fyi, that patch while it works, skips over all the latency work that has been done.  | 
|  10:26  |  topi`>  |   also channels 12 and 13 are disabled, which are definitely in use in EU  | 
|  10:26  |  jnettlet[m]>  |   I am trying to sort out the proper patch to fix everything  | 
|  10:27  |  topi`>  |   I saw some transmit speeds of 130Mbit/s while running my WLE600VX in 802.11n mode (using 20mhz channels)  | 
|  10:27  |  jnettlet[m]>  |   that sounds about right  | 
|  10:28  |  topi`>  |   so for some reason, the 4.13 kernel was not affected  | 
|  10:28  |  jnettlet[m]>  |   as long as you have pretty clean 2.4Ghz airwaves around you.  | 
|  10:28  |  topi`>  |   lots of other problems, though. Like a deadlock issued immediately every time the first connection comes in  | 
|  10:28  |  topi`>  |   oh, we have no neighbors:)  | 
|  10:28  |  jnettlet[m]>  |   no you can get 130Mbits per second TX that is about what I would max out at.  | 
|  10:29  |  jnettlet[m]>  |   you will probably get more with the patch  | 
|  10:29  |  topi`>  |   but the Deadlock also causes some pain down the lane, at some point the whole Hummingboard freezes  | 
|  10:29  |  jnettlet[m]>  |   also I recommend disabling cubic tcp congestion algorithm.  There is another bug that effects that.  Switch to reno or westwood (if you have lossy connections)  | 
|  10:29  |  topi`>  |   and, what is most irritating, the RESET button (that, right down on the board) stops working then  | 
|  10:29  |  topi`>  |   it literally does nothing  | 
|  10:30  |  topi`>  |   works fine after I have power-recycled the board  | 
|  10:30  |  jnettlet[m]>  |   which generally means the SDHC card has crashed  | 
|  10:30  |  jnettlet[m]>  |   yep  | 
|  10:30  |  topi`>  |   I run the board from eMMC  | 
|  10:30  |  topi`>  |   maybe that 4.13 is still too unstable  | 
|  10:31  |  topi`>  |   which kernel(s) have you had a stab at?  | 
|  10:31  |  topi`>  |   4.9.x seem to be fine  | 
|  10:31  |  jnettlet[m]>  |   4.9 is what I am working with currently.  I will test 4.13 soon, getting ready for the 4.14 LTS  | 
|  10:32  |  topi`>  |   I recently rebased from 4.9.21 to 4.9.31  | 
|  10:32  |  topi`>  |   I've been testing it  | 
|  11:31  |  topi`>  |   this is what I get on dmesg:  | 
|  11:31  |  topi`>  |   [   77.563092] ath: EEPROM regdomain: 0x0  | 
|  11:31  |  topi`>  |   [   77.563106] ath: EEPROM indicates default country code should be used  | 
|  11:31  |  topi`>  |   so I guess the EEPROM needs fixing  | 
|  11:44  |  jnettlet[m]>  |   topi`: check further down.  it may come up as that and then program the country code  | 
|  11:46  |  topi`>  |   I'm pretty sure it is still dumbed down as World regd, since hostapd can't use any of those 5ghz channels  | 
|  11:46  |  topi`>  |   and normally hostapd can use channels 12&13, but not with this wifi card.  | 
|  11:51  |  Ke  |  11:51  * Ke puppy eyes jnettlet[m] for the cooling solution  | 
|  11:51  |  Ke>  |   not urgent though  | 
|  11:52  |  Ke>  |   topi`: what did you use for mbin cooling btw?  | 
|  13:26  |  topi`>  |   Ke: a 12cm fan. overkill yeah ;)  | 
|  13:27  |  topi`>  |   the heatsink works fine as long as running under 1.3ghz and not using all 4 cores at once  | 
|  13:27  |  topi`>  |   so make -j3 was stable, make -j4 was not  | 
|  13:27  |  Ke>  |   huh  | 
|  13:28  |  Ke>  |   I was hoping to be able to run full load at 2GHz indefinitely  | 
|  13:28  |  Ke>  |   obviously not a typical workload, but almost all my systems are self hosting when it comes to kernel  | 
|  13:29  |  Ke>  |   I guess I could consider the water cooling, if air does not work out  | 
|  13:34  |  topi`>  |   wow, hostapd started with jnettlet's config file. Excluding some odd HT_* and br_lan config items  | 
|  13:35  |  topi`>  |   Ke: it seems to me the 8040 does not consume significantly more power when at 2.0ghz versus 1.3  | 
|  13:35  |  topi`>  |   at least when idling  | 
|  13:35  |  topi`>  |   my unscientific test involved in removing the fan and seeing how rapidly the temperatures rise when loading cores  | 
|  13:35  |  topi`>  |   and to which value they converge at idle  | 
|  13:36  |  Ke>  |   last we discussed here, 1.3GHz limit is just a limitation, but has no other effects on the cpu  | 
|  13:36  |  Ke>  |   ie. if you software limit to 1.3GHz with 2.0GHz hw limit, it should be completely equivalent to 1.3GHz hw limit  | 
|  13:37  |  Ke>  |   but it is known that on some systems dynamic frequency scaling is not equivalent to hw frequency settings  |