Posted by: Anonymous Coward
on April 15, 2005 10:53 AM
I only supported a small group of users, but I can tell you that mixing traffic types can make a terrible dent in desktop performance. Unless you are using the NX compression software, video display performance over a network is far more subject to ping times than it is to raw bandwidth. I could support about 10 users with plain X support on a 10 MBit network --IF-- I did NOT have any traffic that responded better to bandwidth than to ping times. For example, running Samba file shares over the same segment would kill the workstation updates, because the updates would be slowed down too much.
Now NX is totally different. I have tested it over long distances with ping times on the order of 1-2 seconds, and still had a reasonably performing desktop.
Now let me put a qualifier in here. My testing has all been done with "business" type applications such as web browsers, office suites, and other non-media type applications. I do use linux heavily for media, but I heve never done it with a thin client type environment.
"Do you have any way of reducing network bandwidth consumption while still keeping decompression (and hence, local CPU overload) to a minimum?"
Again, take a look at NX or NoMachine.com. 90 percent opf their performance improvement comes from data caching so that the display terminal doesn't actually have to send a message over the network to get a screen re-draw. It doesn't take much CPU horsepower to plop a bitmap in a specific spot, and it doesn't take much network bandwidth to look display station side first to see if the required data is already in hand. I know they also use some other tricks to minimize both the bandwidth and the round trips, but these are the ones that stuck in my mind as being the basic ideas that they seem to have worked from.
Learn about Linux
Download Linux
Get Linux help
Re:I do this for a living.
Posted by: Anonymous Coward on April 15, 2005 10:53 AMNow NX is totally different. I have tested it over long distances with ping times on the order of 1-2 seconds, and still had a reasonably performing desktop.
Now let me put a qualifier in here. My testing has all been done with "business" type applications such as web browsers, office suites, and other non-media type applications. I do use linux heavily for media, but I heve never done it with a thin client type environment.
"Do you have any way of reducing network bandwidth consumption while still keeping decompression (and hence, local CPU overload) to a minimum?"
Again, take a look at NX or NoMachine.com. 90 percent opf their performance improvement comes from data caching so that the display terminal doesn't actually have to send a message over the network to get a screen re-draw. It doesn't take much CPU horsepower to plop a bitmap in a specific spot, and it doesn't take much network bandwidth to look display station side first to see if the required data is already in hand. I know they also use some other tricks to minimize both the bandwidth and the round trips, but these are the ones that stuck in my mind as being the basic ideas that they seem to have worked from.
#