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(a)ipfire.org> wrote:
>>
>> Now i have done a new test on a first gen RPi1 (256MB) version:
>>
>>
>> [root(a)RPi1 ~]# free
>>              total       used       free     shared    buffers     cached
>> Mem:        227244     133060      94184          0       6988      71416
>> -/+ buffers/cache:      54656     172588
>> Swap:            0          0          0
>> [root(a)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(a)RPi1 ~]# rm /var/lib/location/database.db
>> rm: remove regular file '/var/lib/location/database.db'? y
>> [root(a)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
>