× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Nathan,

Il giorno mar 7 apr 2020 alle ore 07:47 Nathan Andelin <nandelin@xxxxxxxxx>
ha scritto:

Hello Patrik,

Please see my responses to your questions below.

On Mon, Apr 6, 2020 at 9:33 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello Nathan,

Am 06.04.2020 um 16:30 schrieb Nathan Andelin <nandelin@xxxxxxxxx>:

My understanding is that Windows RDP only supports a single session,
while I suspect the Linux products support multiple.

What exactly is a "session" according do your definition? When I open up
a
RDP Client and connect to a Windows Terminal Server, there may be
multiple
users active at once, plus mine.


Marco did not say that he was testing with Windows Terminal Server. I did
not assume that he was referring to such. Rather it seemed more likely that
he was speaking of testing with a couple of PCs running Windows Remote
Desktop. Perhaps Marco can clarify what he was using to test performance?


Both of them. The Server is in production and the single Pc is not a normal
one but a workstation. The results are similar, the Server one is slower,
but absolutely usable.



In regard to to "sessions", my understanding is that the resource
requirements are fairly comparable on the host, whether you're connecting
to a remote PC, or whether you're connecting to a Windows Terminal Server.
Microsoft recommends 2GB memory - Kernel plus 2GB per application per
terminal server session, which seems comparable to the recommendations for
individual PCs.


Indeed we planned 4GB per client.




https://support.microsoft.com/en-us/help/186572/terminal-server-walkthrough-startup-connection-and-application


Similarly, Microsoft suggests that the number of CPU cores be proportional
to the number of "sessions" that Windows Terminal Server needs to support.


https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/remote-desktop/session-hosts#selecting-the-proper-hardware-for-performance


For Linux on Power (both Red Hat and Ubuntu) we assigned 5 cores and we
didn't stress them at all. Our tests were single connections, I think the
highest number was 4 concurrent virtual desktops. But what we saw is
that even a single session brings the CPU usage to 100% for seconds and the
result is that the application in the browser lags.





Frank Soltis has remarked on numerous occasions that *nix was
fundamentally designed as a single-user operating system.

Maybe you're referring to https://en.wikipedia.org/wiki/History_of_Unix

"At this stage [around 1970], the new operating system was a single
tasking operating system, not a multitasking one such as Multics."

Apparently, it's not clear when UNIX adopted multi-tasking and multi-user
capability. But if Frank refers to this 50 year old roots, to me it's the
same when people in here rage that IBM i on POWER is not the AS/400.


No, Frank Soltis was not referring to single-tasking. On the other hand, he
didn't view Unix task-switching capability to be server class. He also
noted that Unix was designed for workstations. And he made a point that
task-switching within IBM i was superior. I see tens of thousands of
processes supported under IBM i with time-sharing and task-swapping that
appear to be unequaled in any other platform.


The IBM i part is reliable, scalable and runs without a glitch everyday.
As usual.



Perhaps your testing confirms that.

No. His testing confirms either that the conversion of the XServer's
remote protocol abilities to Remote Desktop Protocol sucks, or that the
Browser's Code isn't really fast in PPC, as described in a former
message.
If I remember right, the RDP Server components (for Xrdp) use VNC as a
translational common protocol, and VNC *is* very slow. It's good because
of
platform independence and for remote service but I can't imagine to do
serious work with it as transport protocol.


I think you have a point about the communication protocols, which are used
primarily for screen, keyboard, and mouse sharing. But I was referring to
the resource requirements of multiple sessions vs. single sessions, again
thinking that Marco was likely referring to testing performance with a
single remote desktop session, rather than multiple sessions being handled
by Windows Terminal Server.


I think the problem is not single vs multi but basically the virtualization
itself. Yvan's post is (sadly) enlightening.




Just consider the overhead of hosting multiple Linux sessions on a
single server.

It's less overhead than using multiple servers with single users. It's
mostly the same as with Windows Terminal Services. What overhead are you
referring to?


I was referring to the resource requirements for hosting remote terminal
services sessions, whether Windows or Linux. Compare that to the minimalist
resource requirements of tradition web interfaces per session. The
comparison is probably something like 1,000 to 1.


I fully agree but latency plays a considerable role when the data exchange
is sustained. Pages load faster but data came slower.

Thanks again


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.