Last firmware that flashed successfully for me on both partitions was r40134 which had a filesize of 38404KB for the webflash (38400KB for factory)...
You are right that from current firmware that's about 1MB less...I know when I saw ZFS being used that is a resource hog compared to BTRFS and that was something that it looks like he was trying to improve on today...
As others pointed out as well there is some stuff that can be eliminated like the built-in speedtest which I doubt many actually use...Then someone mentioned something about tethering that may not even function anymore...
Someone said the new kernel is bigger and accounts for some of the increase...But I would bet that if BS got rid of some of the old stuff that may not even work anymore that it could be downsized enough but when you start removing a bunch of stuff it may start breaking other stuff so it might not be that straight forward... _________________ WRT1900ACSv2
Last firmware that flashed successfully for me on both partitions was r40134 which had a filesize of 38404KB for the webflash (38400KB for factory)...
You are right that from current firmware that's about 1MB less...I know when I saw ZFS being used that is a resource hog compared to BTRFS and that was something that it looks like he was trying to improve on today...
As others pointed out as well there is some stuff that can be eliminated like the built-in speedtest which I doubt many actually use...Then someone mentioned something about tethering that may not even function anymore...
Someone said the new kernel is bigger and accounts for some of the increase...But I would bet that if BS got rid of some of the old stuff that may not even work anymore that it could be downsized enough but when you start removing a bunch of stuff it may start breaking other stuff so it might not be that straight forward...
You mean the speed test that sponsor dd-wrt ? I'm all for this project being sustainable, but it's a bit counterproductive if all the boat means I can't flash the firmware.
I've been keeping records of the size of the wrt1900acsv2 webflash (actually wrt1x00 series have same sizes).
Last flashable build to partition 2 is 40167.
Recent couple of builds have gotten even larger.
We need to shave off 1MB to get back to the 37.63MB of 40167.
Code:
40134 - ok - 37.5MB 39325696
40167 - ok - 37.63MB 39456768
40189 - not ok - 37.88MB 39718912
40260 - not ok - 39718912
40276 - not ok - 39718912
40352 - not ok - 39718912
40400 - not ok - 38.63MB 40505344
40439 - not ok - 40505344
Yeah...I kind of figured when he put that in the firmware a while back that he was getting some kind of compensation (Which I fully support as well).
And I wonder about all that old HOTSPOT STUFF..
Does anybody really use that...Here in the U.S. if your ISP found out you were doing that HOTSPOT stuff on your bandwidth they'd kick you off...Maybe it's useful in the underdeveloped nations for bandwidth sharing but I can't imagine anybody in the U.S. or Europe (At least Western Europe) doing that without risking getting kicked off their ISP.
ttowling wrote:
You mean the speed test that sponsor dd-wrt ? I'm all for this project being sustainable, but it's a bit counterproductive if all the boat means I can't flash the firmware.
I'm pretty sure businesses like cafes use a standard connection to provide free WiFi to customers all the time, but 99.9% of them don't have any kind of meaningful user restrictions or QoS.
The only place you have to give identification is places like shopping centres etc.
The bottom line is - if it won't flash, nobody will use it.
Posted: Sat Aug 03, 2019 14:21 Post subject: Re: Firmware image size is still the same
dyilmaz wrote:
Firmware image size is still the same on r40501...
I think all you need to do is type 'ubootenv set boot_part 1' in the command box before flashing? I just upgraded to the latest build, but I was on partition 2 so flashed via Web.. my comments about the bloat are still relevant. I don't want to have to use one partition repeatedly.
Since the r40009 firmware, I've seen the GUI get much, much slower until I lose access to it completely on my WRTACS v1.
Others have reported this as well in the new build threads The router is working and I don't lose internet and I can access the router via putty. I just lose access to the web GUI from multiple browsers and machines until I reboot it.
Could this slowdown/GUI loss be attributed to this file size bloat?
Joined: 08 May 2018 Posts: 14126 Location: Texas, USA
Posted: Sat Aug 03, 2019 15:54 Post subject:
The commit in the OP was to help fix the problem that was bricking Broadcom ARM, if I am not completely losing my mind. I honestly do not follow the Marvell-specific configs and commits, but this is something that needs to be addressed directly, if it hasn't already.
Posted: Sat Aug 03, 2019 17:13 Post subject: Re: Firmware image size is still the same
ttowling wrote:
I think all you need to do is type 'ubootenv set boot_part 1' in the command box before flashing? I just upgraded to the latest build, but I was on partition 2 so flashed via Web.. my comments about the bloat are still relevant. I don't want to have to use one partition repeatedly.
I believe mrjcd confirmed in the r40443 thread and my experience confirms it as well that you would run the "ubootenv set boot_part 2" command prior to update.
If I understand correctly the command doesn't change partitions but simply overwrites the current partition data the router "thinks" it's on to partition 2 so when you update it automatically writes to the opposite partition which is partition 1 after running the "ubootenv set boot_part 2" command.
I use the "ubootenv set boot_part 2" before every update now as I'm always on partition 1 with these new releases. It seems to do what mrjcd suggested. Please correct me if that info was wrong. =)
I agree with you. I have a ACS V2 and I'm having the same issues on recent firmwares. If I click an option on web interface, it becomes unresponsive and I have to switch my router off and on. I think dd-wrt have some code inefficiencies nowadays. It would be a very good job if they removed useless codes.
ellick wrote:
Since the r40009 firmware, I've seen the GUI get much, much slower until I lose access to it completely on my WRTACS v1.
Others have reported this as well in the new build threads The router is working and I don't lose internet and I can access the router via putty. I just lose access to the web GUI from multiple browsers and machines until I reboot it.
Could this slowdown/GUI loss be attributed to this file size bloat?
Joined: 08 May 2018 Posts: 14126 Location: Texas, USA
Posted: Mon Aug 05, 2019 11:40 Post subject:
dyilmaz wrote:
I agree with you. I have a ACS V2 and I'm having the same issues on recent firmwares. If I click an option on web interface, it becomes unresponsive and I have to switch my router off and on. I think dd-wrt have some code inefficiencies nowadays. It would be a very good job if they removed useless codes.
I guess the multi-threading httpd fixes broke Marvell devices. The only recent things I recall around these build numbers were the thread # limiting and then the switch to nanosleep. 40065 was the first or second build with thread limiting, and 40276 was the first build with nanosleep.
I agree with you. I have a ACS V2 and I'm having the same issues on recent firmwares. If I click an option on web interface, it becomes unresponsive and I have to switch my router off and on. I think dd-wrt have some code inefficiencies nowadays. It would be a very good job if they removed useless codes.
I guess the multi-threading httpd fixes broke Marvell devices. The only recent things I recall around these build numbers were the thread # limiting and then the switch to nanosleep. 40065 was the first or second build with thread limiting, and 40276 was the first build with nanosleep.
Is it reported? I don't see any change record belongs to this issue on svn page.
I agree with you. I have a ACS V2 and I'm having the same issues on recent firmwares. If I click an option on web interface, it becomes unresponsive and I have to switch my router off and on. I think dd-wrt have some code inefficiencies nowadays. It would be a very good job if they removed useless codes.
I guess the multi-threading httpd fixes broke Marvell devices. The only recent things I recall around these build numbers were the thread # limiting and then the switch to nanosleep. 40065 was the first or second build with thread limiting, and 40276 was the first build with nanosleep.
Is it reported? I don't see any change record belongs to this issue on svn page.
I'm using an ACS v2 with 40501 and not experiencing any problems of this sort.