I am going to reply to myself so that maybe I can save someone else the
headache of chasing down this performance issue.
All of my 9 Sun Ray terminals are now operating at full speed.
The difference is NIGHT AND DAY.
I already had "hires_tick=1" but today enabled flow-control on the switch to
the server. No change.
On a hunch, I disabled all encryption and authentication on the theory that
these would add overhead to the DTUs and cause them to be overwhelmed.
Remember, I am running the original CoronaP2 DTUs which were made a long, long
time ago.
I might put authentication back, but in a home setting, it doesn't really
matter.
After starting a session, the DTUs are in a low-bandwidth mode (blocky and slow
refreshes) for a few minutes, then they go back into lightning mode where a
full-screen 1280x1024 Windows session under VirtualBox feels almost as if I am
sitting in front of a decent-spec PC.
Hope it helps someone down the road.
Cheers,
Marty
Marty Scholes wrote:
> Bob Doolittle wrote:
>> I would look into the packet loss differences
>> between these DTUs, and if
>> found, investigate differences in the networking
>> infrastructure for them.
> Thanks again for the info. I can say wtih confidence
> in my case (two sets of triple head Series 1 and a
> single 150) that the packets are being dropped by
> the DTU and not the network.
> Tell me what to capture and I will provide it.
>> The blocky updates only happen when the
>> network drops packets.
> Again, I have to disagree. I see it even when neither
> the network nor the DTU reports drops packets.
>> Except for things like video, you should not
>> be able to notice differences in speed between
>> these units, given equivalent networking
>> infrastructure.
> I would add to that list switching virtual screens,
> loggin in, output scrolling in gnome-terminal, scrolling
> in firefox, scrolling in evince, scrolling in OpenOffice,
> or scrollin in anything plus anything flash.
> Also add in another OS via virtualbox and pretty
> much anything else reasonable office worker would
> do outside of xterm with compression mode and
> the response screams that this is slow and you
> are better off using a local box.
> All of those limitations are ok if we accept that the
> DTU is incapable, the network is incapable, the
> server is incapable or there is some massive benefit
> to tolerating the pain. At this point I would wager
> that a Linux-based X terminal would outperform
> SRSS right now, and that's sad, because I got
> away from X stations to move to SRSS.
> At least tell me there is an obscure debug mode
> where SRSS logs, "Switching to compression mode
> because XXX detected" so that I can pin down its
> rationale.
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
