high bandwidth usage even with qualitymode=low

Hi Simon

The maximum bandwidth consumed is pretty non-deterministic and depends heavily on the workload in question. Of course something like editing a word document where only small portions of the screen are updating is a lot lighter than watching a full-screen video. So we can try and replicate what you're seeing, is there something specific being run on the server? Or it's just regular "desktop" / terminal / support / office applications?

Please make sure to adjust the codec settings on the client computer (in this case, the Mac) - the client will request it's preferred codec, and this will be negotiated with the server at connection time. So ensure you're setting JPEG / Low on the Mac rather than the server. I honestly wouldn't expect the codec itself to make much difference (at low/medium quality we've tuned the compression on JPEG and GFWX to be pretty close), but the quality mode should make a marked difference...

Thanks and kind regards,

Hi

I have already tried setting both server and client to low and JPEG but it makes no difference still uses 450kbps

i am not doing anything major on the remote pc, simply opening up documents or the start menu shows the bandwidth at 450kbps

i have also spotted another weird issue

the is an option to disable the desktop wallpaper in the gui of the server side which I have enabled

but when I connect to the remote pc, the desktop wallpaper never gets removed? It’s still shown (our old remote support before WaykNow always removes the remote wallpaper to make things quicker)

i have also tried setting the DisableWallpaper json variable that’s in the appdata folder in the programdata json cfg but that’s makes no difference either?

a bug with the DisableWallpaper maybe?

regards

simon

Hi Simon

For the desktop wallpaper - can you confirm if you tried setting that on the client (Mac) side of the connection? It's the client who requests that the server hides its wallpaper.

I did some testing on my side with JPEG/Low on a VM running 1920x1080 and saw full-screen updates weighing in at ~150KB. That's in-line with what I'd expect for those compression options and - to be clear - that's only when sending a complete screen. Most updates when just "using" the remote machine are much, much smaller. Again, that's not really deterministic but just to say the compression is in line with what we'd expect to see.

I tried capping my VM upstream bandwidth at 512kbps and notice a slow, progressive drop in performance on the Wayk session. Basically, on the server side, we are pushing updates at a fairly high frame rate - regardless of network speed - and I start to see more and more latency creeping in on the client side of the connection. However I do note that my machine remained pretty usable on the *local* side; responsive to ping, I could surf the net and watch YouTube, etc.

So I would say there's clearly some optimization to be done on our side when operating over slower network links: an initial analysis shows that while the updates are compressed well and efficiently, how we actually dispatch those updates could definitely be improved. Essentially, if the network can't support the frame rate we're trying to push, then we need to back off. We'll look at what we can do to improve things here.

I am not sure how we see such different effects though: under-the-hood, the P2P connection is just a TCP connection and should be backed-off at the network level when congestion is detected - that is, one TCP application should not be able to hog all the bandwidth. I wonder if something else is going on here to amplify the problem - is there anything specific to know about the network connection at this site, other than the speed limitations? How are you measuring the bandwidth used? If Wayk Now is rendering your connection unusable, I suspect something else is wrong but for now a workaround could be to somehow introduce a bottleneck on the Wayk P2P connection. Any further details would help here.

Thanks and kind regards,

Hi

the is nothing special about the site, 3 comps, 1 Linux server and a router

i will check the client side soon but I’m sure I already tried both sides enabling the disable wallpaper option but it made no difference?

the only thing I can think that’s special is im not using p2p connection as we use our own waykden and jetrelay server (both run on same machine but 2 different dns names) and all comps are behind external ip routers so the jetrelay is needed

I monitor the bandwidth on the server itself using iftop and it shows the connection from the sites external IP address to port 8080 and using 450kbps whenever anything is happening onscreen
bit what I did notice is the bandwidth from the jetrelay server to my client external IP address only uses about 100kbps???

i have also opened up task manager remotely and watched the bandwidth of the lan card and that also shows 450kbps being used?

regards

simon

Hi,

i have checked client side and yes enabling 'disablingwallpaper' there, removes the wallpaper! but that still made no difference to the bandwidth, still uses 450kbps :(

i have even unticked the other options, 'show window contents while dragging' and 'animate menus' but no difference, still 450kbps :(

the only thing i have noticed is the NowService.exe is running at 25% cpu usage when connected remotely? (remember the computers have no GPU! its built in graphics only)

Regards

Simon

Hi,

i have done another test, used a totally different computer which has never used wayknow before and at a totally different site (this site has a leased 100mb/100mb line)

i have put a CAP on the machines bandwidth going out on the internet (10mb down/512kb up)

i then installed the wayknow x64 via the msi, changed the waykden to our waykden,

connected to the computer and thats exactually the same too!

the queue in our mikrotik router shows as RED meaning its using almost 90% of its cap
if i look at the firewall connections too thats also showing the single tcp connection to our jetrelay port 8080 as using 450kb and sometimes 510kb...

i have also noticed however tho, when i remove the cap and let it have free roam, it seems to hog nearly alot more of the bandwidth nearly 2mbps from the single tcp connection over 8080?

EDIT: i have changed the waykden server from ours to the normal den.wayk.net, and its the same issue there too,
its using 450kbps whenever anything changes on screen or you do anything?

EDIT: i have tried an old version 2020.1.7.0 and its the same too 450kbps, on either my waykden or yours

Regards

Simon

Hi Simon

I'm happy to hear that setting the "Disable Wallpaper" option client-side did the trick.

With regard to the bandwidth:

For clarification, when I talk about the P2P connection, I just mean the connection between the Wayk Now client and server - it might not be truly peer-to-peer if a relay server is involved.

To give some background, here is how things work underneath: the server system runs an update loop: the screen is captured and we check for updated regions. If any of the screen changed, the updated region(s) are compressed and sent over the wire. The loop will run as fast as possible to a maximum of 30fps. In practice, the speed of that loop is determined largely by two factors: 1. the speed with which we can capture and compress the display image, and 2. the speed with which we can push updates over the network.

It sounds like the computer in your first example is using a software-based capture (you mentioned a lack of dedicated graphics hardware, and that CPU usage is high while sharing). Software-based capture on Windows is quite slow (it's using GDI underneath); in some simple testing on a 1080p VM I could capture at < 5fps. Even at that rate of capture, however, it can easily be enough to swamp your upload bandwidth. Consider that a full screen (1080p) JPEG compressed on low/medium settings will be in the ballpark of 150KB, and since a 512kps link is 64KB/s you'll see that if even 1 of those frames is a fullscreen update then we're already saturated.

(Hardware accelerated capture pretty much doubles the rate at which I could capture frames, although in general usage I see approximately the same amount of traffic - just capturing smaller updates, more often. The difference is more profound with something that really updates the whole screen, like playing videos on a full-screened player).

If your second example (the 100/100 site) is doing hardware accelerated capture, or simply able to capture faster in software, then you'll see more frames and more data - it's not hard to see how bandwidth used can grow to 2mbps and beyond. a 1080p screen fully captured at 4fps and compressed with JPEG can easily reach 5mbps.

So I see a few takeaways here:

First, it seems unlikely - dependent on usage and expectations - that things will be really useable with 512kbps of bandwidth and a 1080p display. Honestly, I'd say you'd need 3-4x the upstream bandwidth to support this properly. We don't support any kind of "adaptive" compression, but even if we did, in this case it would pretty much always be "very, very low". The biggest difference here could be made by capturing at a lower resolution: halving the resolution to 960x540 would make a massive difference. I understand it's not convenient to be changing the resolution of the machines you are connecting to - we already have an open backlog item to allow selecting custom resolutions when connecting to Windows machines.

Second, even once we address that point, it's likely that the reduction in resolution will increase capture performance significantly - putting us back to square one. If we halve the resolution, but that results in a doubling of the frame rate, we'll still be pushing the same amount of data in the same total time. So we additionally will need to add a way to artificially cap the server frame rate - either manually (through some setting or environment variable) or dynamically based on conditions.

I did some testing here and with my remote resolution at 1280 x 720 and a frame rate artificially capped at 3fps, my bandwidth consistently stayed in the 300-400kbps range during "normal" usage of the machine, with acceptable performance for general support workloads.

We'll discuss this internally, and I'll post back here with some updates on what changes we can implement here and on what kind of time frame.

I do find it strange that a single TCP connection can swamp your bandwidth in such a way that it renders the rest of the network unusable. I wonder if that represents a misconfiguration somewhere (perhaps with your ISP) that is preventing the congestion from being managed properly - however, I'm not a TCP expert and it is clear that we need to provide some better consideration for low bandwidth connections.

I am also interested in why the machine would be using software capture - our requirements for capturing with hardware are quite low (and integrated graphics should be sufficient in most cases). If you get chance, we would appreciate if you can run `dxdiag` on the machine and choose the option to "Save all information" and send us the corresponding report.

Please let me know if you have any further questions!

Thanks and kind regards,

Hi,

i will send over some logs when i get chance to connect to the site remotely again,

the specs of the two machines at the 2 different sites are actually very similar but they BOTH HAVE NO GPUS!
they are only integrated graphics!
although the 1920x1080 computer at the site in question is an AMD while the one in the office is an Intel

BUT i have connected to one of the other computers at that site which is an Intel (again NO GPU only integrated) which has a screen resolution of 1280x1024 and that has the same issue, its upload is 400kbps

also the internet at the site is ADSL2+ (UK) which is only 10mb down/512kb up but its an asynchronous circuit, so its only 1 way in a sense, so if the upload is being fully utilized then the is no room for download, hense the issues they have with the internet stop working when i connect into the computer

Regards

Simon

Hi Simon

Thanks for the update, and you solved the question of why full utilization of the upstream link causes knock-on problems.

which has a screen resolution of 1280x1024 and that has the same issue

Right: if you lower the screen resolution, capture performance improves greatly and Wayk is able to send more frames in the same time frame. So the result is the same: large updates / low frame rate or smaller updates / higher frame rate, we ultimately send the same amount of data per second. On an unrestricted link the lower resolution would have a higher frame rate and smoother response.

Here's what we are going to do:

• Add a setting to request a specific resolution for the remote session (this is already in our backlog for an upcoming release, see here)
• Add a setting client-side to control the maximum frame rate of the remote computer

We were thinking to add those settings client-side so you will "request" them when connecting to a remote machine, but the more I think about it, I think we might want to make those overridable on the server-side as well. Then you could "set and forget" it at the remote site.

By configuring a resolution of, say, 1280 x 720, and a max update of 3-4fps, you should be able to get acceptable performance and stay in the 300-350kbps range.

We will see what we can get in place for the next release of Wayk Now, and I'll post back here with some news on that. In the meantime, if you get the chance to run `dxdiag` on the AMD machine particularly, it will be helpful. Let me know if you have any more questions or feedback!

Thanks and kind regards,

Hi,

thank you for your update and i look forward to the new version with these features, always email me to beta test anything!

on another note, the bandwidth issue is becoming a real issue for me as we had another client ring today to ask if i we could help them
(they are working from home due to the covid)
so they downloaded the portable version, ran it, gave me the id and password, i then connected in and wow o wow it was slow!
turns out they also only had ADSL2+ (10mb down, 512k up), and we even verified no exchanges near them support the fttc (40m/10up) so they was stuck with rubbish internet
so it was a challenge trying to setup a printer remotely and it was on a laptop with a HD 1920x1080 screen too

Regards

Simon

Hi Simon

Wayk Now 2020.2.1 will be released later this afternoon, and has some initial improvements here.

On the client side, there is an additional performance setting "MaxFrameRate" that will propose a maximum frame rate to the server.

Additionally, if you use "virtual" sessions (Advanced > Session > Login Session), you can request a specific resolution with "DesktopWidth" and "DesktopHeight".

On a 512kbps upstream connection, I'd recommend a very low frame rate - 1 or 2fps max. Performance will obviously be worse depending on how much / how often the display is updating and a reduced resolution may help further - it really depends on the workload.

Note that the remote machine needs to be updated to support the new settings, and we didn't add these options to the UI yet (you'll need to use the command line - e.g. wayk-now config MaxFrameRate 1 - or modify your .cfg file directly). We'll improve things there in a subsequent release, but hopefully this will start to make things a bit easier for you. Do you use Wayk Now, web UI or RDM as your client?

Thanks and kind regards,

Hi

brilliant thank you!

I will give it a go and see how I get on

i actually use all of the app options

mac app, windows app, iOS app, even the web client, but the iOS/web client is only when I’m out N about or don’t have my laptop hadn’t

regards

simon

Hi,

all our windows computers are now popping up saying the is a new update available every time a user logs in

i got the impression with the auto-update in background option ticked it would upgrade itself without prompting the user to update?

also a few of the comps are in a domain and if the user clicks yes to update, its then asking for the admin user/pass to run a powershell script?

also it wont install the update either via the 'click yes' button, it says run as admin for powershell, which i select yes, the msi window briefly pops up to look like its doing something, then the software opens but click the about button and its the old version, same in the control panel?

Regards

Simon

Hi Simon

We're sorry for the inconvenience: I'll try to unpack everything here.

Wayk Now still runs the UI update check, even though automatic updates are enabled - that's likely an oversight on our part and I've entered a ticket to fix that. The UI update check should be skipped if the unattended service is installed and automatic updates are enabled.

Clicking "Yes" invokes the PowerShell module to run the installer, and yes it will try to elevate at that time. That is unavoidable but I believe we should be badging the "Yes" button with the UAC shield to make it clear what will happen, and we'll look into that.

Note that you can completely disable the interactive update UI with the setting "VersionCheck" - that can be configured as usual via the command-line or .cfg file; it's also in the UI under General > Check for Updates > When opening Wayk Now.

Finally, when you click "Yes" to the prompt and the install doesn't do anything; I'm afraid that's a knock-on effect from the issue you raised here. The install is run using the PowerShell module that was deployed alongside the app and in 2020.2.0, it contains that bug; so the updater tries to install the x86 version and fails. I'm afraid there's nothing more we can do about this than assure you it's already resolved in 2020.2.1.

I apologize again for any inconvenience, let me know if you have any further questions or feedback

Thanks and kind regards,

Hi,

i did notice inside one of the log files of one of our machines, it saying something along the lines of 'cannot update to 2020.20.1 as wayknow.exe was running'
even though the was no live sessions, only the user logged onto the desktop and using the pc ?
(will try and replicate it again if i can)

but weirdly enough, a server 2019 VM we have for testing, automatically updated itself no problem in the background because the administrator user wasnt logged in and wayknow.exe wasnt running

i have also sent you a PM with debug logs as the 'autostartonuserlogon' isnt working still on a fresh VM from microsoft

Regards

Simon

Hello

The updater will attempt to check if Wayk is in use before applying the update - it's possible this is too aggressive (it sounds the case as your server machine updated itself). Is it the case that your user machines will generally always be logged in (and therefore have WaykNow.exe running) and never idling without a logged in user?

I received your PM - can you let me know in this case; does the machine "auto login"? I know that the preconfigured VMs from Microsoft have a password set, but are you prompted to login?

Thanks and kind regards,

Hi Richard

yes in my case, we have a few machines that are always left logged in (although they do lock themselves after screensaver comes on as normal)
but they dont restart the computers unless the computer wants to restart for updates (normally once a month, a week after patch tuesday!)

I have also tried BOTH with a password and without a password

i believe i have found the problem tho (STUPID WINDOWS 10 FAST LOGIN!)

it appears the users desktop is ACTUALLY LOGGED ON and THEN LOCKED BEFORE the wayknow service has chance to notice the logon,
so the wakynow service hasnt noticed the user has logged in, ITS ONLY NOTICING THEY HAVE UNLOCKED the screen?

2020-07-23 19:01:30 NowService::service::callbacks [DEBUG] - den_client_on_state_change successfully finished
2020-07-23 19:01:30 common::logging [DEBUG] - C:\ProgramData\Wayk\branding.zip matches hash uEiBWTJhpzelz_NCQ-iNQTDiB8SnuhJBLB1FA-A4GX2k7dA, nothing to do
2020-07-23 19:02:08 NowService::main [INFO] - Received service event: SessionUnlock(1)
2020-07-23 19:02:46 NowService::main [INFO] - Received service event: SessionLogoff(1)
2020-07-23 19:02:46 NowService::main [DEBUG] - SESSION_LOGOFF(1)
2020-07-23 19:02:46 NowService::main [INFO] - Received service event: SessionDisconnect(1)
2020-07-23 19:02:46 NowService::main [DEBUG] - SESSION_DISCONNECT(1)
2020-07-23 19:02:47 NowService::main [INFO] - Received service event: SessionConnect(2)
2020-07-23 19:02:47 NowService::main [DEBUG] - SESSION_CONNECT(2)
2020-07-23 19:02:54 NowService::main [INFO] - Received service event: SessionLogon(2)
2020-07-23 19:02:54 NowService::main [DEBUG] - SESSION_LOGON(2)
2020-07-23 19:02:54 NowService::service [DEBUG] - process_user_logon(2)
2020-07-23 19:02:54 NowService::service [DEBUG] - Sesion 2 with user IEUser has been logged in
2020-07-23 19:02:54 NowService::service [INFO] - Started WaykNow.exe
2020-07-23 19:02:55 common::logging [DEBUG] - pipe event NNG_PI

Regards

Simon

Hi Simon

You've reached the same conclusion as us: there exist conditions where the user login might occur before the unattended service is "up" and listening for logon events; which might cause us to miss an interactive logon. That could be that the user has no password set, the account is set to automatically login, and / or the system is using Windows fast login.

I've entered tickets to address both the issues in your post and will write back here with an update.

Thanks a lot of the feedback and diagnostics information,

Hi Richard

glad i can help!

i still also have the issue though where i have 'Minimize to notification area' ticked and 'show main window on launch' unticked (set in the wayknow.cfg in programdata)
its still keeps popping up the window after first launch?

tried this with a fresh server 2019 test vm too

Regards

Simon

I believe we should be badging the "Yes" button with the UAC shield to make it clear what will happen, and we'll look into that.

I like this. this is done way to rarely in my opinion when I see software.

Hello

This thread got a number of issues conflated into it, but I'll try to address some of the later points.

Wayk Now 2020.2.3 is now available, and contains some relevant improvements:

• User activity check by the auto updater is now improved - auto updates should execute properly, even if the user has WaykNow.exe open (but as long as they aren't actively sharing or connected to another computer)
• Wayk Now will still prompt the user to update on launch if "When opening Wayk Now" is checked under "General" > "Check for Updates" options. The installer will seek elevated privileges if the user responds with "Yes", but the "Yes" button is now properly badged with the UAC shield. Updates executed in the background already have the necessary privileges as the service runs as SYSTEM. You can control which of the two options (or both) is used in "General" > "Check for Updates".
• The "auto launch on user logon" option has some improved logic that should ensure it works as expected even in fast boot environments. If you still experience issues with this, please let us know.

> i still also have the issue though where i have 'Minimize to notification area' ticked and 'show main window on launch' unticked (set in the wayknow.cfg in programdata)
its still keeps popping up the window after first launch?

I tried this myself with 2020.2.3 on a fresh Windows Server 2019 VM - I installed the application, unlocked the settings and chose:

• Automatically launch application on user logon
• Minimize main window to notification area

And unselected:

• Show main window on application start

Then I rebooted the machine, logged in, and Wayk Now was auto launched but minimized to the system tray.

Can you confirm if you still experience an issue with the latest version? Presumably you are installed Windows Sever with the "desktop experience"?

Thanks and kind regards,

Hi Richard,

some of the computers auto upgraded to 2020.2.3 automatically because they never had the 'wayknow.exe' running which is brilliant :)

some of them, i just re-ran my install script again which just simply installed the latest powershell scripts then ran the install opts for the new version and that all works brilliant too :)

a few of them i clicked the 'install prompt' because it kept popping up and that also seems to work brilliant too :)

as for the auto start, that seems to be fixed as well too! both comps with and without passwords, now autostart the app and minimized to taskbar as expected :)

is the any guides yet for the device registration without user/pass?

ive updated our waykden to latest waykden-ps and i noticed the new 'Machine registration' options in the webpanel hehe...

Regards

Simon

Hi Simon,

We have a guide showing how to use the new enrollment token feature here:
https://github.com/Devolutions/WaykDen-ps/blob/master/docs/deployment-automation.adoc#enrollment

Best regards,

Hi Marc,

shame its not inside the powershell scripts yet :(

all my automation is around installing ONLY the powershell script from the psgallery and then running commands from there

Regards

Simon

Hi Simon,

I still have to wrap it inside WaykNow-ps, but when I do, all it will do is find the Wayk Now executable and call "wayk-now enroll" on it. You can still do the same with your PowerShell script right now by calling the WaykNow.exe excutable, or using the wayk-now.bat wrapper batch file that finds Wayk Now and forwards all parameters to it:

@echo off 
"C:\Program Files (x86)\Devolutions\Wayk Now\WaykNow.exe" %*

This is also a good indicator of where to look for WaykNow.exe, it should be relatively to do the same in PowerShell.

Best regards,

Hi Simon,

I just published WaykNow-ps 2020.2.3 on PowerShell gallery. I did a quick update to the README as well. We now have a single command to deal with machine registration: Register-WaykNowMachine, and it is a wrapper over the "wayk-now enroll" command now exposed by WaykNow.exe. I also added a new Get-WaykNowCommand command that returns the full path to the Wayk Now executable, making it easy to find and call directly in the future.

If you have any questions, please start a new thread, this one has already been used to answer too many different questions.

Best regards,