lacop

3 ms·

1. 1.▲
   by lacop 1y ago

   That seems to work, thank you! Now latency is just RTT + server time + payloadsize/bandwidth, not multiple times RTT: https://github.com/grpc/grpc-go/issues/8436#issuecomment-311... I was not aware of th
2. 2.▲
   by lacop 1y ago

   Yeah that was my understanding too, hence I filed the bug (actually duplicate of older bug that was closed because poster didn't provide reproduction). Still not sure if this is linux network configuration issue or grpc issue, but some
3. 3.▲
   by lacop 1y ago

   Doesn't initcwnd only apply as the initial value? I don't care that the first request on the gRPC channel is slow, but subsequent requests on the same channel reuse the TCP connection and should have larger window size. This works
4. 4.▲
   by lacop 1y ago

   Somewhat related, I'm running into a gRPC latency issue in https://github.com/grpc/grpc-go/issues/8436 If request payload exceeds certain size the response latency goes from network RTT to double that, o
5. 5.▲
   by lacop 1y ago

   I got some empirical data on this! Effingo file copy service does application-layer strong checksums and detects about 4.5 corruptions per exabyte transferred (figure 9, section 6.2 in [1]). This is on top of TCP checksums, transport layer
6. 6.▲
   by lacop 2y ago

   Unfortunately I don't think browsers handle opening MHTML well out of the box. At least last time I checked in only worked for local paths (file://) and only some browsers. Otherwise it would either try to download or just sh