Question about the buildbot. Google cloud infrastructure allows pretty cheap high powered computing on preemptible instances. Like you could get 64 cores and several hundred gigs of RAM or some such thing for 12 hours in the middle of the night, costing around 5 to 10 bucks. Would setting that up be useful? Is that already what's done?
Depending on where OpenWrt's build servers are, that's likely far more expensive at a cost of ~$1,825 - $3,650/yr.
- While many OpenWrt users likely wouldn't have an issue donating to OpenWrt (I've wanted to for some time, but have no clue where to contribute funds), how would OpenWrt guarantee that amount would be donated year in and year out?
You only pay for the actual run time. My assumption was it runs maybe once a week or the like. $10 a week is $520 a year. Perhaps my assumptions are incorrect. How long does it currently take to build a full release candidate image for every target? How often is it built? What kind of machine is it built on?
1 Like
It is an always on buildbot , where new commits trigger new builds.
There can be several buiildslaves.
Kernel and firmware images are built separately, and that took maybe 36 hours initially. Next build round will be quicker as tools and toolchain for all targets have already been built.
http://release-builds.lede-project.org/18.06/images/grid
Packages buildbot has been crunching 48 hours and has compiled maybe 2/3 of targets.
http://release-builds.lede-project.org/18.06/packages/grid
There is similar buildbot for 17.01 (that compiled new images and packages after changes), although no formal releases are made. The goal is to ensure that breakages are noticed quickly.
And the main buildbot for master, with several buildslaves
Images https://phase1.builds.lede-project.org/grid
Packages https://phase2.builds.lede-project.org/grid
So it is not about let's hire a machine for a few hours. I have no specifics about the actual hosts. But I know that some people have contributed buildslaves.
So that's a bunch of time. My suggestion was mostly about throwing say 64 cores at this and maybe have it take 3-5 hours at cost of maybe $4 or whatever, and the assumption is maybe it doesn't have to be done very often so a few times a year spending a few bucks to enable a quick turnaround on testing a release could be good.
If the current system is fine, then good. Just was noticing that a lot of this is trivially parallelizable and even if you can't afford to buy a 64 core machine and have it run all the time, you can rent one pretty cheap.
I'd like to fork this thread. The infrastructure discussion deserves its own topic, so I created a Infrastructure for OpenWrt topic.
Please continue this topic with further updates on the timeline for an 18.x release. Thanks.
ramips mt7621 with ISP WAN port speed test:
18.06 kernel 4.14.37: 160Mb/s
17.01 kernel 4.4.131: 250Mb/s
I do not think 18.04 can make a release right now.
1 Like
[Device XXXX isn't performing as well as it should]
I do not think 18.04 can make a release right now.
This highlights the needs for a fixed timeline even more.
Why should all the other users be held up because some other architecture isn't performing well?
If there had been a slush date and Device XXXX wasn't performing well with new code, well, that new code shouldn't be considered for the release. Device XXXX will just have to wait a few months to get that new code (assuming it isn't security related, which it isn't).
Should all the ar71xx users be demanding that 18.whatever be held because it's running kernel 4.9 not 4.14? No, even though there may well be far more of them than there are ramips users.
ar71xx will never be bumped to anything never than 4.9
Why,well because it uses legacy way of not using DTS.
And it is now in process of migrating to ath79 which does support DTS,currently only internal WLAN is not working.
Which is exactly the point -- Archer C7 users will have to wait for 4.14.
The presence of that work, as quickly as it is progressing and as exciting as I find it, should not cause other users to have to wait even longer than they already have.
OpenWrt is a community project and as such it depends on time of a big number of volunteers.
ar71xx is pretty much hit the end because mach files are taking too much space on flash and in the RAM for a number of devices.
Switch has to happen sometime,and it looks like the time is now
1 Like
I don't understand why we even need to ask this question considering the point that all ar71xx users have to do is not upgrade when a new version comes out. Good advice for any embedded device. This vs not being able to use new hardware in production because no stable release with support is available... no comparison.
LP,
Jure
1 Like
So any ar71xx devices with 18.06 will perform not as good as with 17.01?
No, they should perform pretty much identical to their 17.01.x base line.
But kernel 4.14 and flowoffloading allows a significant speedup compared to everything before (new feature), that is not available to ar71xx (which is stuck on kernel 4.9), but will be part of the new kernel 4.14 and DTS based ath79 target (covering the same devices). ath79 is actively being worked on right now, it just didn't make it in time for the 18.06.x branch (and it will take a few more weeks before it actually becomes feature complete for the supported devices in master as well, followed by porting over the individual devices one by one).
2 Likes
AFAIK devices such as the Archer C7 will get 18.06, but on the 4.9 kernel instead of 4.14. It will be perfectly usuable and will have all the security patches it needs.
Does anyone know whether 18.06 images are being created automatically by the buildbots? Or is compiling yourself necessary at this time?
Sure the 18.06 binaries will be generated automatically. Buildbot is already crunching normal test snapshot builds of 18.06:
http://release-builds.lede-project.org/18.06/images/grid
http://release-builds.lede-project.org/18.06/packages/grid
But no "official" rc binaries have been released so far, as the build after branching is still being stabilised. (e.g. the build signing keys in the keyring were adjusted yesterday)
I must be blind, but I can only find the build logs, including the logs were the images are being uploaded. However, I am unable to find the images themselves. Care to point me in the right direction? 
On a personal note, I simply would not run a firmware that didn't at least support FastPath / CTF / SFE by now. The performance is just too slow without it to a point where OEM firmwares with hardware NAT blows it away (yes I know QoS functionality takes a hit but don't need all that) where I don't max out my 500Mbit cable modem.
In many routers DD-WRT already supports this (e.g. R7000, R7800) via SFE, and now FastPath is finally hitting OpenWrt (e.g. WRT3200ACM, WRT32X, not sure what else).