5 ms·

Just tested this between my MacBook Pro (Max with 64GB RAM) and my main workstation, GodBoxV3 (Dual 20 Core Xeon, 256GB RAM, and lots of SSD/NVMe storage). The

Just tested this between my MacBook Pro (Max with 64GB RAM) and my main workstation, GodBoxV3 (Dual 20 Core Xeon, 256GB RAM, and lots of SSD/NVMe storage). The MacBook has a 10GbE link and GodBoxV3 has 2x10GbE Links... Tried sending a file from the Mac to GodBoxV3 and it didn't top out at more than 40MB/s. The Windows client also crashed about halfway through. Mind you, when I restarted it, it did recover the transfer. Going the other direction, I seem to be getting around the same kind of speed. One thing I want to test is whether it works over a VPN. Interesting concept and easy to use. lets see if it can get even better.

klabb3 4y ago
Thanks a ton for trying out! I get >100 MB/s between my M1 and Windows machine (with significantly worse specs than yours) so this was a cold shower. Can I ask: - Did you transfer a large e.g. a large directory (I haven't optimized for large amount of files) or just a single file? If so, was that file large enough to let the speed ramp up? - Did you happen to notice high CPU or memory usage during the transfer? Expected memory usage of payload-agent.exe is ~7-20 Mb. CPU can sometimes be a bottleneck if Payload decides to use Quic (but it should prefer TLS/TCP under normal conditions and 40 MB/s is still too slow). ..or free to file a bug report at https://github.com/betamos/payload https://github.com/betamos/payload
- blahgeek 4y ago
  Why use QUIC in LAN?
  - klabb3 4y ago
    Good Q. I wanted to have QUIC for future NAT traversal plans, so I put it in the net stack to keep my architecture in check and not overfit to TCP. Today, Quic is just a fallback though.
- tiernano 4y ago
  in both cases, I transferred a single ISO. one was 1.7GB (Mac -> PC) and back it was 6.5Gb (Win -> Mac). CPU seems to be quite low... PC is hovering around 11-14%, it's usually at 10% (got some VMs running in the background). Agent on the mac is around 4-5. Just ran a second test today, and got less than 5MB/s from Windows -> Mac. The numbers for CPU and RAM above are from that run. 6.5GB ISO is being sent again... [Edit] There is a pending reboot on that Windows box I need to do, at some stage, and I will retest it then. I double-checked that it wasn't sent data over Zerotier or Tailscale (both installed on both machines) and nope. It's just over the standard LAN. Both boxes are on the same subnet, so nothing between them. I will do a bit more digging and open a ticket with my findings. Thanks.
  - scumola 4y ago
    Is your HD on one or both of the machines possibly the bottleneck?
    - tiernano 4y ago
      Nope. NVMe in both cases...
  - klabb3 4y ago
    For people reading this: tiernano has been super helpful on github & discord. Early triaging shows payload chose quic over TCP despite firewall disabled. Quic is a fallback and not yet CPU optimized, and struggles on windows (looks like a single threaded bottleneck - one core was at 100%). It appears payload jumps to the fallback too quickly, without giving TCP a fair chance first.

klabb3 4y ago

Thanks a ton for trying out! I get >100 MB/s between my M1 and Windows machine (with significantly worse specs than yours) so this was a cold shower. Can I ask: - Did you transfer a large e.g. a large directory (I haven't optimized for large amount of files) or just a single file? If so, was that file large enough to let the speed ramp up? - Did you happen to notice high CPU or memory usage during the transfer? Expected memory usage of payload-agent.exe is ~7-20 Mb. CPU can sometimes be a bottleneck if Payload decides to use Quic (but it should prefer TLS/TCP under normal conditions and 40 MB/s is still too slow). ..or free to file a bug report at https://github.com/betamos/payload https://github.com/betamos/payload

blahgeek 4y ago
Why use QUIC in LAN?
- klabb3 4y ago
  Good Q. I wanted to have QUIC for future NAT traversal plans, so I put it in the net stack to keep my architecture in check and not overfit to TCP. Today, Quic is just a fallback though.
tiernano 4y ago
in both cases, I transferred a single ISO. one was 1.7GB (Mac -> PC) and back it was 6.5Gb (Win -> Mac). CPU seems to be quite low... PC is hovering around 11-14%, it's usually at 10% (got some VMs running in the background). Agent on the mac is around 4-5. Just ran a second test today, and got less than 5MB/s from Windows -> Mac. The numbers for CPU and RAM above are from that run. 6.5GB ISO is being sent again... [Edit] There is a pending reboot on that Windows box I need to do, at some stage, and I will retest it then. I double-checked that it wasn't sent data over Zerotier or Tailscale (both installed on both machines) and nope. It's just over the standard LAN. Both boxes are on the same subnet, so nothing between them. I will do a bit more digging and open a ticket with my findings. Thanks.
- scumola 4y ago
  Is your HD on one or both of the machines possibly the bottleneck?
  - tiernano 4y ago
    Nope. NVMe in both cases...
- klabb3 4y ago
  For people reading this: tiernano has been super helpful on github & discord. Early triaging shows payload chose quic over TCP despite firewall disabled. Quic is a fallback and not yet CPU optimized, and struggles on windows (looks like a single threaded bottleneck - one core was at 100%). It appears payload jumps to the fallback too quickly, without giving TCP a fair chance first.