extremely slow probe transfers

[Steve B]

hi guys,

i've noticed that probe transfers in our lab environment are painfully slow. The network speed is fine for Windows file share copies - seeing well over 100MB/s there. But when it comes to probe distribution within Infrastructure Manager or via admin console - it's extremely slow:

For example - this ~132MB probe has taken well over an hour to transfer. If I check the CPU usage on the target host, the controller.exe process is sitting @ 25% during the transfer.

We're running robot (non-secure) 9.31 on each of the hosts. The primary hub/archive is running the latest 20.3 release but i've noticed this in all the versions from 8.51 and I'm struggling to find where to look.

Does anyone have any advice on where to start looking?

Cheers​

[Luc Christiaens]

Try to select distsrv in raw configure and change block_size to: 512000 (as an example)

[David Michel]

Test it with Admin Console. 
has distrsv been deployed to the secondary hub with forwarding setup? 
How to Setup distsrv Package Forwarding in UIM?
Article Id: 34258
https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=34258

How to optimize distsrv probe performance when distributing superpackages
Article Id: 33940
https://knowledge.broadcom.com/external/article?articleId=33940

------------------------------
Support Engineer
Broadcom
------------------------------

[Steve B]

Thanks David,

Unfortunately its still not that great even after tweaking the settings.
- Probe deployment via admin console appears a bit faster but the receiving host still shows only ~10Mbps receive in task manager. The cabi probe seems to start at reasonable speeds but slows down dramatically after ~100MB
- Controller.exe still has high CPU usage on the target host
- The destination host is on the primary hub so doesn't seem to make use of any forwarding
- It's in our lab environment, so there's pretty much no other traffic
- All hosts have ~10gbps bandwidth 

Cheers

[David Michel]

tough case.
your test of remote into primary hub and do a windows copy to the robot is a good test.
cabi is a good example since as you point out the robot is directly under the primary hub, and it is one of the largest packages. 
another test is to setup one of your secondary hubs with a local archive and deploy from there to help identify if the problem is specific to the primary hub.

------------------------------
Support Engineer
Broadcom
------------------------------