Hacker News Reader

Comment by klabb3 | Hacker News Reader

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

View on HN

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.

Is your HD on one or both of the machines possibly the bottleneck?

Nope. NVMe in both cases...

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.

Why use QUIC in LAN?

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.

Reply on news.ycombinator.com