Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"ShortReply" error when running on Windows #13

Closed
sgissi opened this issue May 29, 2018 · 9 comments
Closed

"ShortReply" error when running on Windows #13

sgissi opened this issue May 29, 2018 · 9 comments

Comments

@sgissi
Copy link

sgissi commented May 29, 2018

Not sure Windows is a supported platform or not but compiles without issues. When running I always get from the client:

Terminated due to receive error: [ShortReply] received short reply (44 bytes)

Server doesn't have much information other than "NewConn" and "CloseConn" logs. Enabling HMAC increases the packet size in the error from 44 to 60 bytes but still has the same error.

Packet capture shows (bytes refers to UDP payload not the entire packet):
Client->Server: 25 bytes
Server->Client: 33 bytes
Client->Server: 60 bytes
Server->Client: 44 bytes
Client->Server: 12 bytes
@heistp
Copy link
Owner

heistp commented May 29, 2018

Thanks for the feedback! I'll try to support it, but I also saw strange problems on 32-bit Win 10 (only Windows I currently have, on VMWare) when I was testing during development that appeared to be issues with Go on Windows. A few questions:

  • I assume it's Win 10 (let me know if not), and is it 32 or 64-bit?
  • Which version of Go?
  • If you add --tstamp=midpoint to the client, does it change anything?

@sgissi
Copy link
Author

sgissi commented May 29, 2018

I compiled on Win10 64-bits using Go 1.9.4, will try with go 1.10. Adding "--tstamp=midpoint" does work as intended.

@heistp
Copy link
Owner

heistp commented May 29, 2018

Ok, that sounds like the same problem I saw before on 1.9. I'll also try it with 1.10 on 32-bit and if it still reproduces I'll try to work around it somehow. First, a Win 10 "feature update" to finish...

@heistp heistp closed this as completed in fe49e48 May 29, 2018
@heistp
Copy link
Owner

heistp commented May 29, 2018

The good news is that with Go 1.10.2, I no longer see the strange issue I was seeing in 1.9.

The issue you were seeing was actually because I was making an assumption that the system timer is accurate enough to measure the server's processing time. For Windows, it appears not to be. At least irtt handles that case now.

Additionally the one-way receive delay when client and server are on the same Windows machine seems to often be zero (but not always). This appears to also be due to Windows' timer and process scheduling and probably not something I can do anything about, but at least it should still be accurate enough for millisecond scale RTTs, hopefully.

I also see a new issue on Windows where the first second of round-trip times seems to always be zero, so I'll file an issue for myself and see if I can figure that one out.

Let me know if you see any other problems.

@sgissi
Copy link
Author

sgissi commented May 29, 2018

Indeed, just upgraded to 1.10.2 and it works as expected. My first roundtrip is not zero:

[Connecting] connecting to localhost
[127.0.0.1:2112] [Connected] connection established
seq=0 rtt=1.01ms rd=0s sd=1.01ms ipdv=n/a

I haven't looked at the code too much yet but if there is any low hanging fruit that you need help with, please let me know.

@heistp
Copy link
Owner

heistp commented May 29, 2018

Ok, would you mind trying the client more times in a row? I actually found that the first RTT is zero only about 50% of the time I run it. The fact that I'm running on VMWare could affect this.

@sgissi
Copy link
Author

sgissi commented May 29, 2018 via email

@heistp
Copy link
Owner

heistp commented May 29, 2018

Ouch, ok, I can also reproduce this especially if I lower the interval:

irtt client -i 10ms localhost

I can even see slightly negative RTTs. Thanks for testing. We can continue this over here.

@heistp
Copy link
Owner

heistp commented May 30, 2018

Hi Silvio, would you mind trying again on Windows with the latest code and reporting any results in issue #14?

The negative RTTs were solved and I suppose it should help with artificially low times on a LAN as well (can't subtract the server processing time in Windows because its timer isn't accurate enough). Although what you're seeing in your data center looks different, where send delay and receive delay are equal but opposite, and all RTTs of zero. I haven't seen that.

I still see RTT jumps on VMWare, but those go away on a physical Windows box at the office. Zero RTTs are also still possible when below the precision of the Windows timer, but I haven't decided how to handle that yet.

A re-test on your LAN would be good, and if you want to try a server on the Internet:

irtt client --hmac=flentusers irtt.eventide.io

Thanks...

heistp added a commit that referenced this issue Jun 8, 2018
@heistp
Fix issue on platforms with timer resolution not accurate enough
da6c5b1 
to measure elapsed server processing time (closes #13).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@sgissi @heistp