Is refusing the delivery an option? If you've got the cancellation request in writing then I'd simply refuse to pay any sort of restocking fee.

Dashlane is what we had as a major contender the last time we looked at this

@magicmarker said in File transfer drop:

Server 2019 enables by default some Hyper-v feature called RSC. I wonder if this is your issue. Someone had this same issue as me and turned it off and my Read speed went up to the 900Mbps limited by switch speed now.

https://serverfault.com/questions/976324/very-poor-network-performance-with-server-2019

@Jimmy9008 Looks like this might be your silver bullet

@Jimmy9008 said in File transfer drop:

@notverypunny said in File transfer drop:

So a couple of things I'd be looking at if it were me:

• RAID card config: write-through / write-back will have performance impacts (but should hit S2019 and W10 equally)
• Network vs storage:
  -- iperf3 only runs in memory, so it completely removes storage from the troubleshooting equation, if you see the same type of drop-off testing with iperf3 you know that there's a networking gremlin somewhere that needs to be dealt with.
  -- something like LANSpeedTest actually writes and reads a file on the far-end storage, so it should provide the same results as your typical file transfer, you can also arbitrarily set the transfer size, just in case you want to test something bigger than what you've got as a static file.
• What's actually running in the OS at the same time
  -- use something like processhacker to see what else might be using the network or other IO when your file transfer slows to a crawl.
  --Maybe there's security configs being applied to your servers and not the W10 guests that aren't being taken into consideration.

I'm not sure if these will help...

The physical servers over the network work fine. Full speed ahead! So, cant be RAID settings, network issue or storage. Physical <-> Physical is perfect. What is the point of testing with iperf, im saying already physical <-> physical is perfect...

The issue is with the VMs. From a VM on host A to a VM on Host B, im seeing much slower speeds. From physical A to physical B, its fine.

Granted, your physical network and storage may be up to par from host to host. You still need to identify where the VMs are having issues, so it's from within your VMs that you need to do this testing, to see if the problem is with your virtualized storage / network / other. Virtualization passthrough sounds like a miracle but it doesn't always work as expected.

So a couple of things I'd be looking at if it were me:

• RAID card config: write-through / write-back will have performance impacts (but should hit S2019 and W10 equally)
• Network vs storage:
  -- iperf3 only runs in memory, so it completely removes storage from the troubleshooting equation, if you see the same type of drop-off testing with iperf3 you know that there's a networking gremlin somewhere that needs to be dealt with.
  -- something like LANSpeedTest actually writes and reads a file on the far-end storage, so it should provide the same results as your typical file transfer, you can also arbitrarily set the transfer size, just in case you want to test something bigger than what you've got as a static file.
• What's actually running in the OS at the same time
  -- use something like processhacker to see what else might be using the network or other IO when your file transfer slows to a crawl.
  --Maybe there's security configs being applied to your servers and not the W10 guests that aren't being taken into consideration.

@Pete-S said in File transfer drop:

This sound like the exact same problem as in the thread below:
https://mangolassi.it/topic/21725/disabling-spectre-mitigations-in-2020

"What I find puzzling / frustrating is that I've tested installing Server2019 and W10 1909 as guests on the same hardware with the same XenTools and get hugely different performance results. My understanding was that they were essentially a shared code-base so I'm at a loss as to why such a performance difference. Specific test case is a huge file transfer, the W10 guest spikes a cpu thread to 95 or 100% while the Server 2019 guest runs a thread up to about 20% and it stays there for the duration of the file transfer."

Not sure, he seems to have better / more consistent performance on W10 than Server 2019, which is the opposite of what I was seeing with my setup.

https://venturebeat.com/2020/05/19/microsoft-windows-package-manager-powertoys/

Not implying that ms is cribbing the choco code, but this could make for some interesting developments....

@AshKetchum
Is this VMWare Workstation or ESXi? You'll need a retail key on ESXi for sure... probably on Workstation as well, but I'm sure that someone else will chime in on that aspect since I've nudged the licensing door open. I would never try to clone over a P2V for a workstation if you don't have to. Just a fresh install as a VM.

So with everything that's going on we're facing the prospect of having to wring even more life out of some of our hardware.

Hardware in question is a bunch of R720xd, each with 2 E5-2660 v2 CPUs.

Workload would be Windows10 guests for our VDI environment.

Has anyone got a real perspective on the risks and performance benefits of using spec-ctrl=no-l1d-flush on XenServer and friends? The directive so far has been to keep things on pre-mitigation firmware and platforms... So I'm looking at running XS 7.1 (don't recall the exact CU and patch level) vs either the latest LTSR or the 8.1 with spec-ctrl=no-l1d-flush
<preemptive rant> Yes it's ugly, no I don't like it, but it's not my call so there's no point in discussing the many levels on which this is a bad idea. Looking for assistance / solutions, not a bunch of criticism or complaints. </preemptive rant>

What I find puzzling / frustrating is that I've tested installing Server2019 and W10 1909 as guests on the same hardware with the same XenTools and get hugely different performance results. My understanding was that they were essentially a shared code-base so I'm at a loss as to why such a performance difference. Specific test case is a huge file transfer, the W10 guest spikes a cpu thread to 95 or 100% while the Server 2019 guest runs a thread up to about 20% and it stays there for the duration of the file transfer.

@moyarich said in How to sync files between a windows and a linux machine?:

@notverypunny I am hoping that I can use "cobian backup" to send files to the linux machine as well, but there isn't much information on the internet about how to do it. For some directories it will be realtime,for others it will be scheduled.

I am also looking for a free/open source application

If cobian can do a 1 way push from your central windows machine to a SMB or other standard network share you should be able to convince it to work against a share on Linux as much as against a share on windows.

I'll agree with the others that SyncThing looks like a great option, just didn't fit my use case since it wouldn't keep file ownership settings.