But, does one actually perform any better than the other in terms of actual performance (measured throughput) and reliability ?
You realise that a driver canāt affect received signal strength, right ? It can only report it differently (or completely incorrectly as above) but that doesnāt necessarily mean it will cause you issues actually using it. There are a few linux wifi drivers that do not report signal strength correctly to the OS but still work fine anyway.
(Obviously we still want the best drivers we can in OSMC of course, but I just had to point out that reported signal strength is not the be all and end all because its equally easy to falsify or give inaccurate readings in the āsuspiciously strongā direction tooā¦)
a simple ssh session with the first driver fall down every minute or so.
with the second driver itās rock solid for hours
they can tell me all the numbers they want, but in this case performance is MUCH different.
Just to save my Raspberry from being kicked out of the window, iām now using a RT5370 wifi dongle and this is MUCH more reliable.
I really hope realtek drivers will get fixed soon
Realtek RTL-8188eu OSMC driver works fine here.
I can confirm that the Link Quality and Signal level indication are broken, but the driver works as expected and the wifi link speed (file transfer via samba share) is about 2.2-2.5 MB/s and there arenāt connennection drop-outs anymore. I have had serious connection dropout problems in the past, but now the wifi dongle works well (thank you DBMandrake ).
My setup: OSMC RC3 and Raspberry pi 2, wifi dongle TP-LINK TP-725N v2 (chipset 8188eu).
Ouch 2.5 MB/s isnāt that good. I use the same Wi-Fi dongle and get about 6-7 MB/s one time even 11.3 MB/s (But my router wasnāt hit as hard by multiple devices at the time)
If I remember correctly I got your speeds before setting max_usb_current so you may want to do that.
As for the drivers I would like them updated. Just because my Wi-FI works most of the time for raw Bluray doesnāt mean it couldnāt be better with a updated driver. It wouldn;t be the first time that due to lack of knowledge I assumed I was using a device to its full extent just to find out that it could of been better.
@shadow: how do you measured 6-7 MB/s?
I did my test with a 2 GB file transfer from laptop (wifi connected) to Raspberry pi 2 (wifi connected also). Files on the Rpi are stored on a local attached hdd NTFS formatted, so considering that NTFS file system is not the best choice for Rpi (cpu overhead) and the USB bus is shared between hdd and wifi dongle, I think that 2.5 MB/s is acceptable (setting max_usb_current=1 obviously).
sshād into it (use a little bit of bandwidth for the connection) then pv (cp with progress info) a file from my NAS via NFS
also sshād into it running iftop when watching a full Bluray video from either NFS or UPNP
But maybe it is stuff like it being NTFS or Samba which I heard is one of the worst for bad speed (but they say the same about scp which I still get good speed from)
Itās not a matter of indicators.
When those drivers came out on raspbian, i had my raspi1 working quite good (slow, but stable), and the raspi2 loosing connection every 10 seconds and unable even to do a apt-get call.
Now itās the same on the raspi1 with osmc.
I donāt think mr engman is keeping updated the driver for a matter of indicators, do you?
@Massi
I used the rtl8188eu chipset since Raspbmc (Rapsberry pi model B) and compiled myself the driver from source.
Honestly I donāt remember if the source was provided by Mr. engman or not, but after some problems, it worked fine (slow speed in file transert but that was related to my configs, see my previous post).
Now Iāve a Raspberry pi 2 with OSMC and the same USB Wifi dongle, a TP-LINK TP-725N v2 (chipset 8188eu) and after some connection problems (the same you are suffering now with OSMC) it works fine with OSMC RC3 driver (I suspect even with RC2 driver but Iām unsure). My problem was in the Router TCP/IP configs.
I did a router factory reset and a full reconfiguration and my rtl8188eu worked fine since then.
I use aMule in background and I can assure you I have no disconnections/dropouts anymore with OSMC driver, and p2p programs will stress network connection a lot.
This is my experience and Iāve not tested OSMC with Raspberry pi 1 at all.
I donāt know if the Mr. Engman develops the driver or simply provides src for Raspbian but if his driver is useful for your problem and you are unable to compile yourself then maybe the OSMC developers (DBMandrake?) could have a look at the Mr. Engman work and eventually include it in OSMC.
There seems to be some confusion here. Raspbian is a userland. Mr Engman (the user on the Pi forum) has provided some instructions to compile the out-of-tree modules for the kernel and include them in Raspbian. The drivers arenāt āpartā of Raspbian and they should actually be considered kernel space.
BTW: OSMC is not always based on Raspbian: Pi 2 is actually based on Debian Jessie upstream and does not include any Raspbian components.
The issue is that Realtek hit a merge window once every few months for the mainline, and if it somewhat works no one cares or has the energy to test the drivers. The solution is simple: build out of tree (which is effectively what Engman does, with the latest RTL driver). Iām now starting to ship our own, customised Realtek drivers for OSMC (patched to actually compile on 3.18x+ kernels, additional vid/pid combos). Iāll do this for 8188EU soon, but I do not have a dongle to test.
Whatās the status of 8188eu driver? osmc@osmc:~$ iwconfig wlan0 IEEE 802.11bgn ESSID:"thaks98" Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency:2.412 GHz Access Point: FC:DD:55:05:EC:70 Bit Rate:65 Mb/s Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Power Management:off Link Quality=8/100 Signal level=30/100 Noise level=0/100 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
The link quality and signal level is still low.
and I am using: osmc@osmc:~$ uname -a Linux osmc 4.3.0-10-osmc #1 SMP PREEMPT Sun Nov 29 14:06:50 UTC 2015 armv7l GNU/Linux