Altap Salamander Support Forums

Not that it really matters, but ...

File Copy Operation Timings May Not Be Terribly Accurate? Or they could be affected by other instances of Copy operations/system operations?

I think what I did was started a copy from one instance of SS.

Opened another instance of SS & started a second copy.

Each instance reported something like this: After the second instance ended, #1 then reported more realistic numbers. (And my numbers are not necessarily accurate - just some point in time that I noted them, but the premise itself should be.)

therube wrote: Each instance reported something like this:

Code: Select all

3.6   GB of 8.6   GB copied 3MB/s, time left: 32 min (instance1)
  321 MB of   683 MB copied 2MB/s, time left: 2:20 (instance #2)

After the second instance ended, #1 then reported more realistic numbers.

Code: Select all

5.3   GB of 8.6   GB copied 6MB/s, time left: 11 min

one copied file = two points on your hardisk, source+target; the second copied file = are another two points; so if you are copying/moving two queues at the same time the hardisk is pretty busy. When one job is finished the second operation time left could be reduced more than twice. because hardisk do not need to be switching between two operations...

The algorithm behind the time/speed estimation in AS2.5 is pretty sophisticated. Petr spent 14 days on tweaking it. Of course there is always room for improvements.

Note: we have observed the antivirus software (NOD32 in our case) will stop the copy operations for seconds when you copy executable files (EXE, DLL). There will be more influences...

Note on NOD32 AMON and AS delays: If you want to get rid of the delay, turn off scanning on open. Your choice.

Jan Rysavy wrote:The algorithm behind the time/speed estimation in AS2.5 is pretty sophisticated. Petr spent 14 days on tweaking it. Of course there is always room for improvements.

Does Petr really take into account copy jobs from different instances of AS? And maybe even of Explorer and and other file managers?

The times given look pretty reasonable if looked at at a per instance view.
If there is no system wide view (which is probably impossible to do, at best the different instances of AS could do some inter-process communication), there is no way to do better.

If one instance of Salamander has knowledge of the copy job in the other instance, it needs to determin whether they access the same resources such as source and destination media and any resources involved in transfering the data (CPU, DMA, Bus, Memory, Network ...) and take a qualified quess on how one job influences the other (seek overhead, available network bandwith ...) A task which is nearly impossible to do. Is it really worthwhile?

Unless Petr can use the knowledge and expertise he gained in those 14 days in some other project, where this really matters, economically spoken, he just wasted time and money. Of course, AS users well benefit from hist work, at least some times.

I'm sorry, but I got lost in this thread. Is there some problem with speed and time estimation in Altap Salamander 2.5? If yes, please describe us how to reproduce it and where the problem is.

We are pretty happy with the current state, so please let us know...

Jan Rysavy wrote:Is there some problem with speed and time estimation in Altap Salamander 2.5?

therube gave you an example where Salamander missed it, most likely not by some seconds caused by virus scanning, but caused by some of the inherent difficulties in estimating these times as i briefly mentioned in my previous post.

By no means did I intend to criticise or belittle Petr's work, in the contrary, my intent was to point out some of the difficulties he had to cope with, but also my astonishement that you spend that much of your resources on such a rather subordinate task. I guess this is what makes Altap Salamander such an excellent product.

Unfortunately, therube did not give us much detail on his copy job Salamander did not estimate well. From what he says I assume he expected Salamander to do an estimation approximately like this:

Instance 1 has a tranfer rate of (8.6-3.6)*1024/(32*60) MB/s = 2.667 MB/s
Instance 2 has a transfer rate of (683-321)/(2*60+20) MB/s = 2.586 MB/s

So after 2:20, instance 2 finishes its task. Instance 1 has transfered another 373.333 MB. For the remaining 4.746.666 MB we sum up the transfer rates, so it takes another 903.6 s = 15:04. Therefore, the initial estimate for instance 1 ought to have been 15:04 + 2:20 = 17:24 (vs 32:00 by AS).

As we see from the second figure he gives us for instance 1, transfer rate indeed could have been summed up. It ended up to be (8.6-5.3)/(11*60) MB/s = 5.12 MB/s.

But the questions remain: how could one instance of AS know of the other instance's copy job, and how could AS know whether transfer rates could be summed up or whether they just were independent of each other?

I see your point, but I must disappoint you, our implementation is quite simple. It displays actual speed (calculated from the period of last five seconds) and time left is calculated using long-term speed (speed in last 30 seconds). Operations are independent, maybe we should add reset of speed meters whenever some new operation starts or any running operation ends - it would react faster to new speeds.

Real copy speeds are very tricky, you can copy at 40MB/s when the file is stored sequentialy (big files, e.g. movies) and at 200KB/s when the file is fragmented or very small (e.g. source codes). So I don't think that this feature costs any further time spending. Please try to accept it in the current quality, I think it is at least comparable with our competitors.

Jan Rysavy wrote:Is there some problem with speed and time estimation in Altap Salamander 2.5?

Not from me.
I was simply pointing out ...

Not that it really matters, but ...

File Copy Operation Timings May Not Be Terribly Accurate? Or they could be affected by other instances of Copy operations/system operations?

This is also the reason I posted in the General Discussion thread rather then elsewhere.