[digiKam-users] Network Library too slow and not reconnect

Mon Apr 20 15:17:10 BST 2020

Hi, woenx,

   Sorry by the huge delay. Let me explain all I have been passing through.

   After you said about ping time (why I didn't think about testing this? thinking the most complex tests and forgot the basic..) I tested here and almost had a crash. Ping times between 2.000ms and 5.000ms ! OMG...

64 bytes from 192.168.88.2: icmp_seq=21 ttl=64 time=4.874 ms

64 bytes from 192.168.88.2: icmp_seq=22 ttl=64 time=2.195 ms

64 bytes from 192.168.88.2: icmp_seq=23 ttl=64 time=4.000 ms

64 bytes from 192.168.88.2: icmp_seq=24 ttl=64 time=3.837 ms

64 bytes from 192.168.88.2: icmp_seq=25 ttl=64 time=2.055 ms

64 bytes from 192.168.88.2: icmp_seq=26 ttl=64 time=5.138 ms

64 bytes from 192.168.88.2: icmp_seq=27 ttl=64 time=4.982 ms

64 bytes from 192.168.88.2: icmp_seq=28 ttl=64 time=2.447 ms

64 bytes from 192.168.88.2: icmp_seq=29 ttl=64 time=5.028 ms

64 bytes from 192.168.88.2: icmp_seq=30 ttl=64 time=5.927 ms

64 bytes from 192.168.88.2: icmp_seq=31 ttl=64 time=80.328 ms

64 bytes from 192.168.88.2: icmp_seq=32 ttl=64 time=1.990 ms

64 bytes from 192.168.88.2: icmp_seq=33 ttl=64 time=200.179 ms

64 bytes from 192.168.88.2: icmp_seq=34 ttl=64 time=5.035 ms

64 bytes from 192.168.88.2: icmp_seq=35 ttl=64 time=1.418 ms

64 bytes from 192.168.88.2: icmp_seq=36 ttl=64 time=2.272 ms

64 bytes from 192.168.88.2: icmp_seq=37 ttl=64 time=4.538 ms

64 bytes from 192.168.88.2: icmp_seq=38 ttl=64 time=1.910 ms

64 bytes from 192.168.88.2: icmp_seq=39 ttl=64 time=2.205 ms

64 bytes from 192.168.88.2: icmp_seq=40 ttl=64 time=4.593 ms

Initially, I thought it was my NAS problem, but after some tests I realized that the high ping was from my MacBook and  my AP (an Tp-Link RE450).

Since I was about to chang it, I left as it was.

Some days later, I had changed all my AP do TP-Link Deco M5. All of them connected by 1Gb cable to my router.

But the ping times were still very high. The Wi-Fi connection on my MBP was telling my speed was 300Mbps, a little lower than the 450Mbps of RE450, 

but then I was thinking that my Wifi card (802.11/n) could never reach the 450mbps. don't know why it was on RE450. 

But nothing changed on my ping time. So I started searching about high pings on MacBook Pro, and realized that everybody was having issues on these computers regarding to Wifi. I tried a lot of solutions, took me some days to try all, but nothing worked.

I then tried to run some other tests. I opened my wife's computer, a newly bought Samsung with Windows 10, connected wifi Wifi/ac and ping my router:

Disparando 192.168.88.2 com 32 bytes de dados:

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=7ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=5ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=6ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=6ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=7ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=6ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=8ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=7ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=5ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=6ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=7ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Windows's ping is different. I does not show decimal numbers, and I don't know if my MBP's numbers (ex.: time=3.837 ms) are 3ms or 3837ms.

Here in Brazil we use the comma as decimal separator, but I think my MBP is giving me decimal separated by dots. So, the times are equivalent.

Put the Samsung on cable (Gb ethernet) and ping again:

Disparando 192.168.88.2 com 32 bytes de dados:

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Put my MBP on the same cabe (also Gb ethernet):

64 bytes from 192.168.88.2: icmp_seq=136 ttl=64 time=1.308 ms

64 bytes from 192.168.88.2: icmp_seq=137 ttl=64 time=0.821 ms

64 bytes from 192.168.88.2: icmp_seq=138 ttl=64 time=1.289 ms

64 bytes from 192.168.88.2: icmp_seq=139 ttl=64 time=1.185 ms

64 bytes from 192.168.88.2: icmp_seq=140 ttl=64 time=1.123 ms

64 bytes from 192.168.88.2: icmp_seq=141 ttl=64 time=1.239 ms

64 bytes from 192.168.88.2: icmp_seq=142 ttl=64 time=1.222 ms

64 bytes from 192.168.88.2: icmp_seq=143 ttl=64 time=0.872 ms

64 bytes from 192.168.88.2: icmp_seq=144 ttl=64 time=1.324 ms

64 bytes from 192.168.88.2: icmp_seq=145 ttl=64 time=1.219 ms

64 bytes from 192.168.88.2: icmp_seq=146 ttl=64 time=1.095 ms

64 bytes from 192.168.88.2: icmp_seq=147 ttl=64 time=0.826 ms

64 bytes from 192.168.88.2: icmp_seq=148 ttl=64 time=1.020 ms

64 bytes from 192.168.88.2: icmp_seq=149 ttl=64 time=0.949 ms

64 bytes from 192.168.88.2: icmp_seq=150 ttl=64 time=0.991 ms

64 bytes from 192.168.88.2: icmp_seq=151 ttl=64 time=1.221 ms

64 bytes from 192.168.88.2: icmp_seq=152 ttl=64 time=1.270 ms

64 bytes from 192.168.88.2: icmp_seq=153 ttl=64 time=0.922 ms

64 bytes from 192.168.88.2: icmp_seq=154 ttl=64 time=0.774 ms

64 bytes from 192.168.88.2: icmp_seq=155 ttl=64 time=0.871 ms

64 bytes from 192.168.88.2: icmp_seq=156 ttl=64 time=0.769 ms

64 bytes from 192.168.88.2: icmp_seq=157 ttl=64 time=0.731 ms

64 bytes from 192.168.88.2: icmp_seq=158 ttl=64 time=0.731 ms

64 bytes from 192.168.88.2: icmp_seq=159 ttl=64 time=0.774 ms

64 bytes from 192.168.88.2: icmp_seq=3505 ttl=64 time=1.075 ms

64 bytes from 192.168.88.2: icmp_seq=3506 ttl=64 time=1.226 ms

64 bytes from 192.168.88.2: icmp_seq=3507 ttl=64 time=1.366 ms

64 bytes from 192.168.88.2: icmp_seq=3508 ttl=64 time=1.091 ms

64 bytes from 192.168.88.2: icmp_seq=3509 ttl=64 time=1.217 ms

64 bytes from 192.168.88.2: icmp_seq=3510 ttl=64 time=1.130 ms

64 bytes from 192.168.88.2: icmp_seq=3511 ttl=64 time=1.188 ms

64 bytes from 192.168.88.2: icmp_seq=3512 ttl=64 time=0.775 ms

64 bytes from 192.168.88.2: icmp_seq=3513 ttl=64 time=0.936 ms

64 bytes from 192.168.88.2: icmp_seq=3514 ttl=64 time=0.799 ms

64 bytes from 192.168.88.2: icmp_seq=3515 ttl=64 time=0.609 ms

64 bytes from 192.168.88.2: icmp_seq=3516 ttl=64 time=0.610 ms

64 bytes from 192.168.88.2: icmp_seq=3517 ttl=64 time=0.756 ms

64 bytes from 192.168.88.2: icmp_seq=3518 ttl=64 time=0.997 ms

64 bytes from 192.168.88.2: icmp_seq=3519 ttl=64 time=0.744 ms

64 bytes from 192.168.88.2: icmp_seq=3520 ttl=64 time=1.046 ms

64 bytes from 192.168.88.2: icmp_seq=3521 ttl=64 time=0.753 ms

64 bytes from 192.168.88.2: icmp_seq=3522 ttl=64 time=0.628 ms

64 bytes from 192.168.88.2: icmp_seq=3523 ttl=64 time=1.025 ms

64 bytes from 192.168.88.2: icmp_seq=3524 ttl=64 time=1.389 ms

64 bytes from 192.168.88.2: icmp_seq=3525 ttl=64 time=0.775 ms

64 bytes from 192.168.88.2: icmp_seq=3526 ttl=64 time=0.661 ms

64 bytes from 192.168.88.2: icmp_seq=3527 ttl=64 time=0.991 ms

I think the times are equivalent.

So, I decided to install Digikam on Samsung notebook. Left it on Wifi and left my MBP on cable.

Configured Digikan on it to access my remote files on NAS.

Started both on my MBP and Samsung.

On my MBP, took 1h45min just to the interface comes up. The message on splash screen was Checking ICC repository.

After that, Digikam started to find new items. 

After 20min: 

    MBP: 0% , Samsung 2%

I could see, on Samsung's digikam interface, it finding the itens. Since I have more than 100.000 items on my library, I know it would take a long time. At least it was working.

After 1h:

   MBP: 0%, Samsung: 8%

I then decided to plug the cable back to Samsung. The speed increased drastically, of course, since it was Gb speed, and on about 10 minutes it passed to 12%.

And after 3 hours, I quit digikam on MBP. Still on 0%.

I don't know what else I can do. Already thinking to changing my computer, but I don't want and I will not, my MBP is quite old (2011), but everything works perfectly on it. 

---- Ativado Qua, 08 abr 2020 15:25:46 -0300 woenx <marcpalaus at hotmail.com> escreveu ----

Alex, what is the typical network latency (the milliseconds on each ping) to 
the server where the photos are stored? 

I spend some time abroad last year and the latency was quite high (~125ms) 
despite having a decent network speed (realistically, ~40Mbps). My library 
(around 100000 pictures, around 300GB), and digikam took around 9 minutes 
just to show the main interface (and many many more to complete the initial 
scan). However, the same library, from home (40ms to the server where they 
are stored), starts almost immediately and completes the initial scan within 
7 minutes, considering there are not new pictures to be found. So, 
apparently, network latency matters even more than network speed. I also use 
a newer version, so it might have been caused by some bug that is fixed now. 

In the case there are new pictures to be found, digikam tried to transfer 
them in order to look at the metadata, so the process is slower, but that is 
a background process and you can use the program normally meanwhile. 

-- 
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200420/cc791853/attachment-0001.html>