I have tested the current unstable on my running system.
Linux 4.14.210-ipfire #1 SMP Sat Dec 5 14:54:12 GMT 2020 x86_64 Intel(R) Celeron(R) CPU J1900 @ 1.99GHz GenuineIntel GNU/Linux
Time result was:- real 0m44.954s user 0m44.242s sys 0m0.315s
Regards,
Adolf.
On 06/12/2020 21:01, Michael Tremer wrote:
Hi,
Thank you, Arne, for testing.
It is good to know that this algorithm finishes on this device.
However, this is still not really acceptable for an IPFire device in production.
I would absolutely encourage to upgrade :)
-Michael
On 6 Dec 2020, at 13:35, Arne Fitzenreiter arne_f@ipfire.org wrote:
Now i have done a new test on a first gen RPi1 (256MB) version:
[root@RPi1 ~]# free total used free shared buffers cached Mem: 227244 133060 94184 0 6988 71416 -/+ buffers/cache: 54656 172588 Swap: 0 0 0 [root@RPi1 ~]# uname -a Linux RPi1.localdomain 4.14.210-ipfire-multi #1 SMP Wed Dec 2 23:46:20 GMT 2020 armv6l BCM2835 GNU/Linux [root@RPi1 ~]# rm /var/lib/location/database.db rm: remove regular file '/var/lib/location/database.db'? y [root@RPi1 ~]# time update-location-database Downloaded new database from Sun, 06 Dec 2020 04:34:29 GMT Reloading firewall [ OK ]
real 14m28.682s user 12m45.663s sys 0m17.090s
I think this time and xt_ipv4 output looks ok. Also the bug if the WebIF that firewall rules could not created on machines with low ram seems to be fixes.
Arne