Obviously something important was changed in new NW file handling procedures.
COPY:
Copying over the local network takes ages to complete. It doesn't matter the file length. After file copying apparently completes, it then waits for confirmation or something for another like 30 secs (per file).
RENAME:
Same thing - too long. Like 30 secs per file renamed.
However, the situation seems to improve after several successful operations (meaning - I let the Opus wait what it needs to, and not kill it first). Everything was working normal prior to 10.0 upgrade 2-3 days ago. However, turning off the firewall at the remote destination host helps (Outpost 7.1 Suite Free). For parallel example, MP3Tag software runs always fast in both reading and writing operations.
Is there some remedy for that or should I consider alternate solutions? All clients W7 x64.
Use Process Monitor, or a network usage monitor, to see if Opus is pulling down lots of network data. Maybe a column or setting is causing the files in the network folder to be read and that's using up the connection's bandwidth until it's finished.
Process Monitor may also be useful to see which operations are taking so much time.
I just turned off the option, will give it a test drive and report back.
The columns are nothing fancy in particular: name, size, ext, modified, attr. That's all. I like it this way for the speed's and less bloat's sake.
BTW, I've just taken a look in Process Monitor. It is really incredible how many events are generated in a single minute, and I just filtered out Opus. For the stuff like that I rely on SysInternals Suite, but I'm not sure if they provide NW usage monitoring. What do you recommend?
In Proc Mon, be sure to turn off the registry and network things, and just monitor filesystem access, to reduce the number of events. (But there will still be a huge number of events! That's normal.)
For monitoring how much data a program is sending/receiving from the network on a Windows 7 machine, the built-in Resource Monitor tool (Network tab after launching it) is excellent. It'll show you a process-by-process breakdown of upload/download/total network usage, and also which addresses the data is going between.
Just investigated the matter using the Resource Monitor by ordering DOpus to copy1 GB file over to the NW host. It's interesting that Resource Monitor doesn't display 'DOpus.exe', but 'System' under NW activity.
I think network file copies go via the system process. Which might make it a pain to be sure that it's Opus that's responsible for the data...
As a first test it'd be interesting to see how much data is being transmitted when the files are not being copied. That way we can see if it's something else using bandwidth that's slowing the file copies down.
Another thing to try: Clear everything under Preferences - File Operations - Copy Attributes. Some of those things are new to Opus 10 and I guess might cause noticeable per-file delays on slow connections (or if something is misbehaving).
Here I don't have the same problem as you but the transfer speed over the network is about half what it used to be with Directory Opus 9 (used to be over 100 ms/s now about 45 to 50).
There used to be a setting to change the buffer size and it improved the transfer speed a lot (Slow network copy performance) but is seems it has been removed.
I guess all those little problems will disappear pretty fast, that's one of the nice things about Directory Opus, you never have to wait long for fixes
Thank you very much Leo. It was the real speed (measured both by Directory Opus and Bandwidth Meter Pro) Changing the copy_buffer_size to the value I used previously (8192) solved the speed problem
I too have been having some inconsistent network copy problems with Opus. For example, after switching both machines on, the first copy with Opus will occur at up to 100MB/s (I have RAID on both machines and GB networking, Jumbo Frames disabled) and successive transfers drop down to ~4 MB/s (yes it's that extreme). Regardless of actual reported transfer speeds, the real-world time differences are that extreme. Occasionally from that point on, separate copy jobs during that same machine session jump back up to normal speeds, however I have yet to see a pattern and the majority of successive copies during that session occur at the low speed.
To be honest, up front, the only thing I've done so far is try changing the Opus copy_buffer_size to 8192, which appears to only buffer to RAM and the slow down still occurs. This could perhaps point to problems outside of Opus, however I need to investigate a lot of other things first before drawing any conclusions but nevertheless it is interesting and I just thought I'd mention it, as it relates to this discussion. I'll try to get back with more info when I get time.
Aliendream, since I changed the copy_buffer_size (now it's set to 1024 - at 8192 I noticed that sometimes it totally "overflowed my network adapter and I had to reboot my computer to get the network back) I have a very consistent speed. As an example, yesterday, I mirrored one of my hard drive to my "server" (it runs Gentoo Linux btw.) and during the whole copy process (close to 2 TB of data) speed alternated between 85 - 100 MB/s (speed varied depending on the size of the files - speed measured both with Directory Opus copy dialog and Bandwidth Meter Pro.
A side note: it seems that Directory Opus use two different way for copying over the network. If you open a dual Lister and drag files on a shared folder, it seems it uses a window dialog, if you open a dual Lister and in the destination, actually open the shared folder before you copy, then it uses a directory opus dialog. Do you have the same speed in both circumstanced ? Before I change the buffer, I noticed that when using the first method, speed was much higher (now it's the same)
I'm just reviewing my old posts and would like to conclude that topic with my definitive conclusion that got solved over time. The problem was with my firewall - Outpost 7 and 8 are just enough bad when it comes to network operations. Don't know why, but I just kicked it out, although I bought it for a lifetime.
