- This topic has 13 replies, 5 voices, and was last updated 10 years, 10 months ago by
.
-
Posts
-
My Setup:
Client Machine (Work):
Windows 7
Nomachine 4.0.366Server Machine (Home):
OSX Mavericks
Nomachine 4.0.360
Dual Screens (I turn on mirroring when i connect from work)Connection:
I am connecting from my Work (windows) to my Home(Mavericks) over SSH port forwarding (Putty). My router is catching port 4000 and forwarding it to my Mavericks machine. I am using the NX protocolProblem:
There seems to be a continuous freezing and unfreezing that happens every few minutes. It doesn’t freeze in my Home machine as all my keystrokes and movements show as soon as it unfreezes( I also tested it with my wife who confirmed continuous activity on the Home machine). I have reduced the display settings to the utmost minimum and this doesn’t seem to help.Have you tried disabling UDP from the Advanced connection settings?
Also please paste the statistics after a freeze occurred.
You can take them clicking on the Connection icon of the toolbar.This is the stats immediately after a freezing had occurred. I have attached the log file to this post.
I turned off UDP and no difference. The freezes actually seem longer.
There doesn’t seem to be anything abnormal in the stats.
Can you attach also client-side logs? You can find them in the .nx directory in the user’s home.
Ang, again the logs don’t show anything strange. If possible, can we send you a debug version for you to install? Let us know: issues[at]nomachine.com
BG
The client and server keep exchanging ping packets every 5 seconds. If no reply is received in 10 seconds, the client or server will print a warning in the session log. This warning has the form “No data received since…”. If you don’t see these logs, this means that client and server are communicating fine and the network is not the problem. Additionally, when no communication is possible, you should see the client screen ghosting until the communication is restored. If the duration of the freeze is shorter than 10 second, though, you won’t see anything in the logs. But this doesn’t mean that a freeze of 1 or 2 seconds is less annoying. What we want to rule out is that it is a NoMachine problem and not a network problem. If you see the logs, it’s for sure a network problem. If you don’t see the logs, it may be still a network problem but of a different kind, involving the available bandwidth.
Consider that the quality of the link is extrememly important for this kind of applications. It is not a matter of bandwidth (every residential customer having a ADSL link has enough bandwidth to run NoMachine comfortably) and not even latency (although the lowest it is, the best will be the user experience, with also a round-trip time >50 ms becoming noticeable). For quality of the link I mean the ability of the ISP to give to all users a equal share of the network, something current ISPs are very bad at doing. So all it takes is a user on the same network segment that starts a bittorrent download to cause a network congestion and packet retransmission that can take seconds to settle down.
Quick follow-up. This report rang a bell, since it was the second specifically targeting Maverick and because in both cases there was no indication in the logs that may signal a network problem. Hence we put people on trying until it could be reproduced. And it was reproduced. The problem is that it is reproduced randomly and very rarely, here and at another customer’s site, only after many hours the session is running. On the other hand, when the system enters in such state, the problem starts to appear regularly, after every few minutes.
Since it is not easy to reproduce (it can be a combination of network jitter and some other condition, tied or not to the fact it is Mac and specifically Maverick), we would be extremely grateful if you or other people would be so kind to help us finding the bug, by running a version of the software with logs enabled. Let us know if you are interested.
Yes, i did notice it works fine for a while but once it starts, it goes on for the whole work day.
I am interested! Nomachine is the only consistent solution i have had through the years.
Follow-up: we resolved a resource leak bug affecting Mac OS X, all versions, that MAY have caused your problem.
For sure it solves this crash:
https://www.nomachine.com/TR12K04134
We can’t be sure it also solves your problem. There is the theoretical possibility it does, since, after a while, the server started to behave inconsistently. Anyway we were able to reproduce it here only once and since updating the code we have not reproduced it anymore, so there is some hope. Another user experiencing the same problem received the fix yesterday. He has not provided his feedback yet. The new code should ship as part of the 4.1 on next Monday.
Similar problem here.
Client: winxp-work
server:mac os x mavericks-home
network jitter begins after some minutes in a fresh connection, then connection lost, internet lost. Have to reebot my DSL router at home.
Hope the 4.1 release fix the problem
It doesn’t look the same problem. This is more likely a problem with the UDP traffic overwhelming your router. Quite uncommon indeed. There is congestion control in the NX protocol aimed at preventing this. The only cases where we encountered a similar problem was during development, due to some bug that prevented the congestion control to work correctly, and only with some routers. What the router should do, in these cases, is just throwing away packets, not certainly drop the Internet connection. Try disabling UDP in Edit -> Advanced settings.
I still have the same problem even with the latest versions. I believe i emailed the logs (i am using the debug version). Pretty frustrating though, id take general slow movement over freeze and unfreeze movement any day.
One thing i have noticed is that restarting my home machine relieves the behavior for a while. I also noticed i get the same freeze behavior connecting from other locations directly (without the ssh forwarding)
This topic was marked as solved, you can't post.