In our laboratory, we have a pretty good environment, except unfortunately the network. It just happened that the network is administered by someone else and to Lab get garbage. Old routers, switches etc even older. etc.. At the moment in which our entire department went on thin terminals , we began to feel the wild fluctuations that ultimately brought to the widespread, quite accidentally, unfasten the PCoIP session. Diagnosis of the problem is very difficult, it often happened that the one terminal run for hours without a problem, and the outlet next door, could not work, restart every minute session. The session logs often appeared the message: No PCoIP date received in the past 3 seconds (to peer connection might be lost). And in the course of intensive work and a virtual machine!
At this point I really want to commend the author of the PVoIP Log Viewer , brilliant tool, literally drags to light all the parameters of our PCoIP session.
With the graph of delays, we can easily tell how big problems we have in the network.
In our case, in addition to the launch of the project reconstruction of LAB ( PCoIP Network Design Checklist ), has helped more flexible PCoIP session. First of all, has been extended dynamically determine the quality of transmitted image frames to the value of 30 to 100% (ie the acceptable range). In addition, the parameter is enabled Disable Build It Lossless (may be possible to send an image of lower quality than the reference (created on the machine)). And the most important parameter, ie Lost Session Timeout:
This is exactly the value that determines the moment at which the terminal recognizes that the network connection was lost. Even if you find that you experience a temporary “freeze” session, if we do not exceed 10 seconds, the session will resume without logging off the user (and not log off the terminal session on a virtual machine). I described setting increased user experience, however, did not prevent accidental rozpięciom. He had found even such information , and in fact, in my log also appeared appropriate messages (MGMT_CMI: Failed multiple attempts to contact the SOAP server!)
Unfortunately, giving a fixed IP address does not resolve the problem. But it led me to the solution (as always darkest under the lamp), the time in which the terminal “start up” with fixed IP address … almost immediately rebooted and got the address from the DHCP! After consulting the documentation , it turned out that should restart the terminal is the option activates the permanent configuration. New batch of terminals which reached us, had set the default password to initialised sequence worked (enabling -> dhcp -> profile), automatic configuration settings, we added a password and password … momentum that was entered in our profile! Thus, according to a warning from the 4.3.4 documentation (Persistent AutoConfig: WARNING: ENABLING THIS FEATURE MAY RESULT IN DEVICES BEIGN RESET WHILE USERS ARE IN SESSION), such a setting appropriate options (including passwords), it is VERY BAD setting:
Turn off DHCP Option Matching and Persistent AutoConfig instead profiles can distribute in accordance with the schedule, eg the user experience. And the problems will be much less
Was this information is helpful? Tell me, please leave a comment!
