Ok, in this case, what I understood is that the "optimal rate algorithm" needs to be updated, rewritten, corrected . . . etc. I was also a programmer once, and I know that this can't happen from one day to another, so as a workaround I propose the following: mention about these "issue" in the afterboot manual (afterboot - things to check after the first complete boot) . For more about afterboot type man afterboot.
On Thursday, February 15, 2018 1:46 AM, Charlie Eddy <charlie.e...@occipital.com> wrote: Nice! >From Stefan's mail: >"In the current implementation, the wifi layer selects a transmit rate >based>on the number of frame transmission retries reported by wpi(4) firmware." That's the "automatically selected optimal media type", comme ci comme ca defined w/r/t the strictness of your definition. >"If you find that one of these commands makes it work as fast as it does on >Windows, we can conclude that the problem is with OpenBSD's rate selection >algorithm. This algorithm is very old and dates from a time when wifi networks >were much less densly deployed." It looks like OpenBSD is like driving a beautiful old car. Malfunction doesn't make sense to say even though existing properties of the OS and existing properties of the world aren't making it easy. On Wed, Feb 14, 2018 at 1:47 PM, Zsolt Kantor <zsoltkan...@yahoo.co.uk> wrote: > >Now, I just switched to OpenBSD, and executed the commands as you wrote down. >AND IT WORKS! >You have more in depth network knowledge than me, so I just will write down >what I did, and I have also some questions related to that media option of the >ifconfig (which I, to be honest don't really understand). >So, I used the same mirror (https://ftp2.eu.openbsd.org/ >pub/OpenBSD/6.2/amd64/) for testing and used only wget for downloads. With >wget the download speed is a bit higher compared to firefox or chromium, I >think because wget is more 'light', command line tool, more optimized >(probably the code is more clear), firefox and chromium opens slower maybe >also bloat in code, so the download rate is also less. >Now back to the point. I logged in to Xfce, I opened a terminal with two tabs, >one for normal user, to execute the downloads, with the following command: >'wget https://ftp2.eu.openbsd.org/ pub/OpenBSD/6.2/amd64/ install62.fs', and >one for root user to use ifconfig to make those settings. After every ifconfig >change, I switched to the normal user tab and started the download process >(sometimes, when I saw some unusual fluctuation I interrupted the download >process and started again, waited a while to see what happens, than if the >download process was not stable I waited a little to be just sure, after that >started the process again and so on, to have a more precise report). >Here are the test results: >OFDM6: max: 1.30MB/s, min: 700KB/s (this config. is not stable, sometimes >drops from 1.20MB/s to 700KB and back) >OFDM9: average: 1.45MB/s (more stable, do not drops above 1.30MB) >OFDM12: quite stable as with OFDM9, sometimes reaches a max. of 1.70MB/s >OFDM18: stable, average: 1.50MB (I saw also 1.80MB/s for fractions of seconds) >OFDM24: At the first try was not stable, fluctuated between 900KB/s and >1.70Mb/s, at the second try it was stable, avg: 1.55MB/s (for fractions of >seconds 1.80MB/s), at the third, fourth . . . tries was stable, avg: 1.60MB >OFDM36: quiet stable, avg: 1.55MB/s >OFDM48: not so stable, 700KB/s, 800KB/s, rarely reaches 1000KB/s (but >immediately drops) >OFDM54: not stable at all, between 700KB and 900KB (sometimes reaches 1.1MB/s, >rarely drops down to 300KB/s), the avg. rate is 700-750KB. > >These for the tests. Now, I have a few questions. In the ifconfig manual at >the media option states that if it is used with no arguments displays all >available media. In my case it looks like this: > >supported media: >media autoselect >media autoselect mediaopt monitor >media autoselect mode 11a >media autoselect mode 11a mediaopt monitor >media autoselect mode 11b >media autoselect mode 11b mediaopt monitor >media autoselect mode 11g >media autoselect mode 11g mediaopt monitor > >But what you proposed to me to try is OFDM6, 9, 12 . . . In the supported >media list I don't find those types, why? > >The second question is: now theoretically the problem is solved, to be honest >I have no clue about media types, radio frequencies and such things, but based >on my tests it's need to be corrected something in OpenBSD related to this >issue? Or it is more like a user side configuration? If somebody would ask me >I think the optimal media type should ne automatically selected by the system >(driver, firmware . . . I don't know who's in charge for this), and not by the >user (after the system is installed). >That's all, thanks again. For me the problem is solved. You need to decide if >this is a malfunction or not. > >Thanks again. > > > > > >On Wednesday, February 14, 2018 9:36 PM, Zsolt Kantor ><zsoltkan...@yahoo.co.uk> wrote: > > > >You told me a very interesting thing, and I need to admit that I did not >thought about this (although in the past I wrote some ping program using >sockets, so I have a basic knowledge about networking in general). I will try >that, but right now I need to resolve other things (not related to OpenBSD), I >also thought to do some wireshark tests in Win and BSD and check the traffic, >the packets, and the times between the packets sent and received. I also want >to test the wired connection in OpenBSD. I'm only using wifi, I have no wires >to connect to the router, so I need to buy one and test. I also need to study >a little bit more how transmissions are working in OpenBSD, the layers, etc. I >will be back when I have some concrete result. > >Thanks for the advices, >Zsolt > > > >On Wednesday, February 14, 2018 1:09 PM, Stefan Sperling <s...@stsp.name> >wrote: > > > >On Tue, Feb 13, 2018 at 11:00:39PM +0000, Zsolt Kantor wrote: >> So if you have any idea, any new testing method, please tell me, I will try. > >The information we'd need to fix anyting is still not there because >what you are measuring is the result of an interaction between many >layers: application, sockets, TCP, IP, wifi, physical medium (radio). > >In order to fix anything we'll need to determine which layer is >causing the problem, and why. > >I can make a guess, based on my knowledge of how the wifi layer behaves: > >The transmit rate used by wpi(4) is selected dynamically by the wifi layer. >The higher the selected transmit rate is the faster your TCP stream will >be because your TCP ACKs will flow faster. > >In the current implementation, the wifi layer selects a transmit rate based >on the number of frame transmission retries reported by wpi(4) firmware. > >Frame transmission retries at a given transmit rate will happen if either: > >1) You are too far away from the AP. A lower rate has more chance > of getting through so lowering the rate is a good idea. > > >or: > >2) You are close to the AP but there is lots of unrelated wifi traffic > on the same channel using up air time. Attempts to transmit a frame > are often blocked by other legitimate frames on the air, so we need > more than one attempt and all our attempts get counted as retries, > and now we end up using a lower transmit rate. > Using a lower rate in this situation means we use up more air time > and make the problem even worse, not just for us but for everyone > on this channel. > >The access point density in many residential buildings today means that >case 2 is very likely and case 1 is very unlikely, especially on a 2GHz >channel. Adapting the transmit rate based on retries doesn't achieve >the desired result in this situation, so your download speed sucks. > >You can test my theory by disabling the automatic rate selection algorithm >and tell wpi(4) to send all frames at a transmit rate of your choice. >To do so, associate to the AP, and now fix the transmit rate as shown below. >Repeat your test each time after changing the transmit rate. > > ifconfig wpi0 media OFDM6 mode 11g > # repeat test > ifconfig wpi0 media OFDM9 mode 11g > # repeat test > ifconfig wpi0 media OFDM12 mode 11g > # repeat test > ifconfig wpi0 media OFDM18 mode 11g > # repeat test > ifconfig wpi0 media OFDM24 mode 11g > # repeat test > ifconfig wpi0 media OFDM36 mode 11g > # repeat test > ifconfig wpi0 media OFDM48 mode 11g > # repeat test > ifconfig wpi0 media OFDM54 mode 11g > # repeat test > >If you find that one of these commands makes it work as fast as it does on >Windows, we can conclude that the problem is with OpenBSD's rate selection >algorithm. This algorithm is very old and dates from a time when wifi networks >were much less densly deployed. Windows is probably using a different algorithm >to make decisions about which transmit rate to use (for reference, it probably >uses a similar algorithm as was implemented in Intel's Linux iwlegacy driver, >in file 3945-rs.c of that driver's source code). > >
