Build: armbian-hardware-optimize chosing invalid scheduler
I was testing script above and noticed that i was getting an error for the flash based-optmization.
I don't have noop scheduler on sunxi 5.0x or meson64 4.20. Quick googling says that noop is kind of a legacy scheduler instead of multiqueue offerings.
Does it make sense to choose a different scheduler, or just clean up code so that it checks for existence of noop before attempting to apply?
root@lepotato:/sys/block/mmcblk0/queue# journalctl --unit armbian-hardware-optimize
-- Logs begin at Fri 2019-03-22 22:15:57 EDT, end at Sun 2019-03-24 21:33:39 EDT. --
Mar 22 22:16:03 lepotato systemd[1]: Starting Armbian hardware optimization...
Mar 22 22:16:03 lepotato systemd[1]: Started Armbian hardware optimization.
Mar 22 22:16:03 lepotato armbian-hardware-optimization[1662]: /usr/lib/armbian/armbian-hardware-optimization: line 31: echo: write error: Invalid argument
Mar 22 22:16:03 lepotato armbian-hardware-optimization[1662]: [ ok ] Setting noop I/O scheduler for mmcblk0
Mar 22 22:16:03 lepotato armbian-hardware-optimization[1662]: /usr/lib/armbian/armbian-hardware-optimization: line 31: echo: write error: Invalid argument
Mar 22 22:16:03 lepotato armbian-hardware-optimization[1662]: [ ok ] Setting noop I/O scheduler for mmcblk0boot0
Mar 22 22:16:03 lepotato armbian-hardware-optimization[1662]: /usr/lib/armbian/armbian-hardware-optimization: line 31: echo: write error: Invalid argument
Mar 22 22:16:03 lepotato armbian-hardware-optimization[1662]: [ ok ] Setting noop I/O scheduler for mmcblk0boot1
Mar 22 22:16:03 lepotato armbian-hardware-optimization[1662]: /usr/lib/armbian/armbian-hardware-optimization: line 31: echo: write error: Invalid argument
Mar 22 22:16:03 lepotato armbian-hardware-optimization[1662]: [ ok ] Setting noop I/O scheduler for mmcblk1
Mar 22 22:16:04 lepotato armbian-hardware-optimization[1662]: sed: no input files
Mar 22 22:16:04 lepotato armbian-hardware-optimization[1662]: /usr/lib/armbian/armbian-hardware-optimization: line 114: /proc/irq/$(awk -F":" "/eth0/ {print \
root@lepotato:/sys/block/mmcblk0/queue# cat scheduler
[mq-deadline] kyber bfq none
lanefu
All 17 comments
I can implement fix, just looking for a recommendation on which way to fix.
lanefu
on 25 Mar 2019
As you see... nobody cares (any more). Armbian has transformed from a project trying to squeeze out the max out of underpowered SBC to be usable as energy efficient servers into something only focused on fancy shit like supporting TV boxes with Linux.
ThomasKaiser
on 2 Apr 2019
Ya but i care...
lanefu
on 3 Apr 2019
maybe i should evangelize the roku more
lanefu
on 3 Apr 2019
@ThomasKaiser , I feel that you upset for some unkown reason, at least public in this forum/project.
Personally, I try to painfully replace @Zador which also leave for personal reason.
Personally, I've never worked on any TVBox, I've leave that to @JMCC or @Jernej or @150balbes , but you should NOT blame them to doing so ...
You've been the performance/benchmark expert in the past, but you decided to quit Armbian...
There is maybe a person to replaced you in @StuartNaylor, but you've decided to bash him on his early posts ...
BTW, are you volunteer to do the task of migrating DEV from 5.0y to 5.1.y in the upcoming days or week ?
martinayotte
on 3 Apr 2019
Unfortunately I have no experience in this circle. I am, as I've stated repeatedly, a hardware developer of small devices (sensors/actuators/etc) and an EXTREMELY low-level coder. (I know 5 different platforms' assembly language). How Linux does it's scheduling and/or how to optimize it is not something I can help with, I can, however, debug things like bootloaders, hardware abnormalities, etc. This does not mean that "nobody cares (any more)" or that I'm "focused on fancy shit".
@martinayotte I've seen your massive increase in contributions, I'm sorry I've not correspondingly stepped up, but we've talked about what I'm working on at this second, I'm in a bit of a down time now and get back to this.
Tonymac32
on 3 Apr 2019
@anyone sooo FYI im a systems / infrastructure / devops guy.. so i do like performance tuning n stuff.
re kernel change. im really trying to get a better picture of the roadmap and maintenance type stuff so i can help track and work as well. if there's an existing thread please direct me, or lets kick off a new one?
lanefu
on 3 Apr 2019
Perhaps a new thread, although keeping the 10 or so interested parties focused is... a task unto itself.
@ThomasKaiser reminded me I want to try something with the build system, which is like a festering wound IMHO: All of these boards sources are interacting with each other and causing compromises in individual board's support (without resorting to the absolutely intricate interactions seen in the sunxi folder). Too far off topic here, might open a topic on the forum concerning it, it should allow users to make whatever they want without actually messing with the main scripts
Tonymac32
on 3 Apr 2019
Personally, I've never worked on any TVBox, I've leave that to @jmcc or @jernej or @150balbes , but you should NOT blame them to doing so ...
Huh? I'm talking about Igor's newest idea to generate a new branch tvboxes that should replace master soon and will introduce countless upgrade hassles.
I'm a server guy. I'm interested in stable operation. I'm even willing to use a distribution like Debian where everything is outdated as hell just to be able to benefit from the 'stable' principle. But when running Debian or Ubuntu on ARM devices relying on Armbian I get the downsides of 'stable' (packages outdated as hell) combined with the downsides of a rolling distribution since again and again totally unnecessary upgrade hassles have been introduced (due to lack of communication and testing, a single person's taking decisions, not acting as a community but a one man project).
If you keep packages on a remote server up to date and the thing is bricked after an update and doesn't reboot properly that's worst case possible and happened way too often with Armbian within the last years. And all babbling about this issue was to no avail since Igor is not affected by others' concerns (have you read the countless complaints by Mikhail and me in the forum and elsewhere?)
As such the initial goal of Armbian (energy efficient server) has turned into something entirely different and the only focus now is on fancy shit and making the whole thing even less maintainable by focusing on adding more and more hardware to the mix for reasons unknown to me (no idea how much influence 'negotiated deals' with board makers have here). I wasted days of my life discussing the situation starting already in 2017 but to no avail since it's always the same. Once you think a consensus is reached one person does his thing as if nothing would've happened before.
As for the overall situation wrt answers and 'bashing' ... talking about the forum now. I don't like to use a forum where one person is abusing his moderator rights censoring stuff and then even denying that he did so. How much sense does it make to contribute to a forum when a moderator moves your posts to the bin? Especially when he's not able to realize what he's doing?
ThomasKaiser
on 3 Apr 2019
Last paragraph here pretty much sums it up what separates Armbian from a community driven open source project...
ThomasKaiser
on 3 Apr 2019
@lanefu as for the IO schedulers. I don't know whether any testing has happened here since the differentiation between rotational media and flash was already there when the script was called armhwinfo and I touched it the first time several years ago.
Maybe this is just relying on 'Internet wisdom' just like everyone will tell you lz4 would outperform lzo when it's about compression on Linux while on our ARM boards it's exactly the opposite.
So if you want to 'fix' something here you obviously need to do some testing first. My usual procedure with something like this is rather time consuming (see the above research about compression algos and how this impacts real world tasks -- running shitty kitchen-sink benchmarks à la Phoronix never helps) and the question is whether the whole approach is not BS anyway. 'Flash' can be anything ranging from crappy SD cards over to good A1 rated SD cards to eMMC to USB2 attached SATA SSDs, to SATA SSDs, up to NVMe.
Alone testing through these guys below will keep you busy for a few days so good luck with an attempt trying to improve the situation instead of simply adding a 2>/dev/null.
ThomasKaiser
on 3 Apr 2019
Last comment here...
This line here is the really scary one since this means Ethernet IRQs will be processed on cpu0 which is usually overwhelmed by other processes. OTOH just another Armbian mainline kernel experience: move from a smelly vendor BSP kernel to mainline and performance decreases...
Mar 22 22:16:04 lepotato armbian-hardware-optimization[1662]: /usr/lib/armbian/armbian-hardware-optimization: line 114: /proc/irq/$(awk -F":" "/eth0/ {print \
And the place to properly deal with IO schedulers could be a udev rule instead of some script lines using defaults from last century. This affects a lot of the other tweaks contained in armbian-hardware-optimization in a similar way.
ThomasKaiser
on 3 Apr 2019
I'm talking about Igor's newest idea to generate a new branch tvboxes that should replace master soon and will introduce countless upgrade hassles.
This now 6+ months old partially developed idea solves some problems. "soon" is delayed and delayed since its not finished nor matured ... and maintenance complexity is getting up while the purpose was to make it go down. I choose tvboxes because there was even more dirty trick used.
Perhaps this is a good time to make a move we were discussing on some time ago - to break it into development and stable/maintained only branch and to unleash possibility for even more radical changes. This become even more manageable if we divide sources patching outside of the main script, like we recently talked about ...
There is more people around now and Steven is willing to help for full-time maintenance. Is this good or bad?
As such the initial goal of Armbian (energy efficient server) has turned into something entirely different and the only focus now is on fancy shit and making the whole thing even less maintainable by focusing
There are many more hw on the market than 5 years ago and more people dealing with it than 5 years ago. Project is more complex and harder to maintain and keeping under control. Board support count is only one parameter in this.
on adding more and more hardware to the mix for reasons unknown to me
We could drop RK3399 entirely to catch up. One board means little while different hardware is the fun part of the project, perhaps a motivation ... until it's not 2 much.
how much influence
Board vendors that support Armbian are displayed on the website. If they influence random people with Armbian and around we can't do anything about. Industry will always have the interest.
igorpecovnik
on 7 Apr 2019
I don't think dropping rk3399 is necessary, but I maintain my statement
about providing images for anything that isn't proven. A few think that's
too much, but honestly, I see questions in RockPro, RockPi, T4, M4, etc all
the time.
Before we drop anything, keeping in mind people are using this stuff, let's
work out "common to all" issues such as how to simplify support. Rk3399's
issue is 100% u-boot from what I can tell, and fragmentation because we all
just plopped things into the directories. Not going to lie, that's why I
quit contributing to rk3399 for a while, it was too schizophrenic, kernels
and family names flying all over.
On Sun, Apr 7, 2019, 4:50 PM Igor Pečovnik notifications@github.com wrote:
I'm talking about Igor's newest idea to generate a new branch tvboxes that
should replace master soon and will introduce countless upgrade hassles.This now 6+ months old partially developed idea solves some problems.
"soon" is delayed and delayed since its not finished nor matured ... and
maintenance complexity is getting up while the purpose was to make it go
down. I choose tvboxes because there was even more dirty trick used.Perhaps this is a good time to make a move we were discussing on some time
ago - to break it into development and stable/maintained only branch and to
unleash possibility for even more radical changes. This become even more
manageable if we divide sources patching outside of the main script, like
we recently talked about ...There is more people around now and Steven is willing to help for
full-time maintenance. Is this good or bad?As such the initial goal of Armbian (energy efficient server) has turned
into something entirely different and the only focus now is on fancy shit
and making the whole thing even less maintainable by focusingThere are many more hw on the market than 5 years ago and more people
dealing with it than 5 years ago. Project is more complex and harder to
maintain and keeping under control. Board support count is only one
parameter in this.on adding more and more hardware to the mix for reasons unknown to me
We could drop RK3399 entirely to catch up. One board means little while
different hardware is the fun part of the project, perhaps a motivation ...
until it's not 2 much.how much influence
Board vendors that support Armbian are displayed on the website. If they
influence random people with Armbian and around we can't do anything about.
Industry will always have the interest.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/armbian/build/issues/1325#issuecomment-480628507, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AUEygnR_MK07h-Pa_IVssWfJibl2RkQaks5veloIgaJpZM4cF6ca
.
Tonymac32
on 8 Apr 2019
There is more people around now and Steven is willing to help for full-time maintenance. Is this good or bad?
@igorpecovnik can you speak a little more to above? Steven From Xunlong? Maintenance on what?
lanefu
on 10 Apr 2019
Steven From Xunlong? Maintenance on what?
Project in general. It would be very helpful to have at least one full timer around.
igorpecovnik
on 10 Apr 2019
https://github.com/armbian/build/pull/1381/files should fix this.
igorpecovnik
on 26 May 2019
Related issues
bremme
·
7Comments
Fourdee
·
14Comments
Fourdee
·
12Comments
Fourdee
·
9Comments
topilski
·
4Comments
Most helpful comment
Last paragraph here pretty much sums it up what separates Armbian from a community driven open source project...