Hi Sam, I have set up everything, so I should start testing soon.
I have a question, a user on OE forum pointed me to this:
If your wireless adapter uses the 8192CU driver you can add the following to /storage/.config/modprobe.d/8192cu.conf
# Disable power management
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
since adding this (I'm using a D-Link DWA-131 Rev:B1 adapter) my wireless transfer speeds have improved quite a bit.
Before disabling power management the transfer speeds were between 3 and 4 Mbyte/sec, after they are now between 7 and 12 MByte/sec.
Note: I'm living in the country and there are no other Wifi networks around, so there is minimal outside interference.
In case of EW-7811UTC that would be 8812au.
Iāve tried this out and it didnāt work for me on my OE setup.
Should this work at all?
Hi Sam, Iām stuck when I run apt-get update I end up with these messages:
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
Sounds good Sam, Iāll be delighted to give it a spin when itās ready.
Just a heads up, I encountered some errors during update, but since I was doing everything on my tv and not putty I couldnāt copy it here.
Everything works well, I didnāt encounter any bugs during testing.
Next time Iāll definitely use putty so I can copy any information which might be relevant.
Sam I have another off topic question (Sorry for bugging you).
I know that force_turbo disables the dynamic CPU frequency and basically the Raspberry Pi CPU gets stuck to whatever is the highest frequency.
But does it use more power constantly or just when itās under some load?
I would presume that when the CPU is idle nothing special happens.
Do you have any experience with this by any chance?
I am not Sam, but from my experience with other embedded hardware, I can tell that if the cpu is locked in full power mode, it will consume a lot more power when idle than downclocked and undervolted.
Good powermanagement will not only clock down the cpu but also deactivate some services when in low power mode like disabling the video and audiooutput or even send the ram to sleep.
This will not be the case here though as only the processor will clock down and up again when the power is needed. This will happen in small bursts though and you cqn get a bit of lag whenever it happens.
So not sure if it is worth the effort. Probably better to just force turbo if it is stable enough as you donāt have to worry about batterylife here. We are speaking about around 700mA vs 500mA without usb gear. So it will not be a huge gain anyway. Maybe a dollar or two when you leave it running 24/7.
There are some tests with the pi on the internet where real data was published. So some experiments have to be done.
Hi mcobit, thank for the answer!
I had a similar idea but wasnāt sure what happens with Raspberry Pi, does force turbo only affect CPU or more components.
If itās just CPU than thatās not too bad at all.
@sam_nazarko
Iāve noticed that ethernet transfer rate is greater with OSMC than with OE.
I use NTFS formatted 2 TB HDD.
OE is 9-10MB/s
OSMC is 10-11,5MB/s.
To some it might not be much but I recognize better drivers and better optimization when I see one.
Iām ready for the next one, just let me know when itās done.
Before you get too excited about the performance increase, it has a cost. If the system crashes, looses power etc itās a high chance that the library will be corrupted beyond repair.
But I donāt see (perhaps Iām missing something) how userspace can guarantee successful transactions anyway. If the power goes, the power goes, and ultimately, the write goes through the kernel anyway. Making the writeback synchronous doesnāt guarantee it is successful. If we have unstable PSU or a bad SD card, corruption will occur anyway. SQLite is serverless, so we are dependent on the userland application. If that crashes during a synchronous writeback, we are no better off than an asynchronous one?
Perhaps the in memory journal is more risky, but again, Iām not convinced, and thatās why we have staging to test these things, so weāll have plenty of time to test this either way.
Iāll try and explain.
When an app writes to disk the file system will ack the write as soon as itās in the buffer, once this is done the file system can decide when and how it will write the data. This might not be in the order they happened but in the order thatās most efficient for the disk layout. This can lead to writes happening in the wrong order which isnāt an issue for most file types but can break databases.
When issuing a synch Io with write through the file system will only ack the write once itās on disk, this gets rid of the reorder issue and it minimizes the time the data is vulnerable for crashes. All databases does this no matter of size or architecture.
Thereās still the issue that disks may play tricks as well and this is out of our hands.
Disabling write through can be a valid use case for unimportant data where you can afford to lose it, I would argue that users libraries are quite important data for them.
If you go on with this anyway I would suggest you make it a setting so users can easily disable it when issues appear and you wonāt have to get another build out right away
This will hopefully enable memory mapped IO, which is enabled in OpenELEC already (and explains the initial speed difference) without requiring us to recompile libsqlite. Iād appreciate if @vdb86 and @thansen_dk can test again with the same libraries as before, as this will let us know if itās working as expected.
You should look for these lines in /home/osmc/.kodi/temp/kodi.log
02:42:44 T:139969386363072 INFO: sqlite-osmc: memory is not mapped yet
02:42:44 T:139969386363072 INFO: sqlite-osmc: memory mapped IO is enabled
