How is performance not using uttsc?
Devin Nate wrote:
Hi Folks, William;
I've just tried a totally different manchine. My home WinXP Pro 32-bit machine.
Yes we'd tried some, but they were IBM/Lenovo, whereas mine has a totally
different CPU /Networking /Video /etc. Ping rtt's are small ... performance of
SDAC is just as bad.
Ping times attached. Sample utcapture output attached, showing poor perf (the
long tokenID is that of SDAC). Second utcapture showing a sun ray DTU, with
good times. Finally, another ping capture to show that MTU's up to and
including 1300 are usable (and the client is set to 1133 for this test).
This is going to kill the project for a few hundred users, and more importantly
it's driving me nuts. I suspect either a bug in SDAC or an incompat for SDAC
with RHEL. Every other app works great across this network, even the native Sun
DTU's work great across this network.
Very frustrating.
Dare I ask, any more suggestions?
Is anyone here from the Sun SDAC devel team? If so, maybe we could arrange
something? [email protected].
Thanks,
Devin
1. Ping time RTT.
C:\Documents and Settings\nated>ping 204.12.xx.yy
Pinging 204.12.xx.yy with 32 bytes of data:
Reply from 204.12.xx.yy: bytes=32 time=25ms TTL=57
Reply from 204.12.xx.yy: bytes=32 time=15ms TTL=57
Reply from 204.12.xx.yy: bytes=32 time=14ms TTL=57
Reply from 204.12.xx.yy: bytes=32 time=14ms TTL=57
Ping statistics for 204.12.xx.yy:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 25ms, Average = 17ms
C:\Documents and Settings\nated>
2. utcapture of BAD performance using SDAC.
r...@srs1(/root)
# /opt/SUNWut/sbin/utcapture -r -s srs2 b976bba2338c4fcccf61d1c162ff1697
# TERMINALID TIMESTAMP TOTAL PACKET TOTAL LOSS BYTES SENT PERCENT LOSS
LATENCY
b976bba2338c4fcccf61d1c162ff1697 20100301201048 2963 0
1557314 0.000 501.000
b976bba2338c4fcccf61d1c162ff1697 20100301201103 2963 0
1557314 0.000 501.000
3. utcapture of GOOD performance using Sun Ray DTU (model 270).
r...@srs1(/root)
# /opt/SUNWut/sbin/utcapture -r -s srs2 00144fd354cc
# TERMINALID TIMESTAMP TOTAL PACKET TOTAL LOSS BYTES SENT PERCENT LOSS
LATENCY
00144fd354cc 20100301201152 4744 21 483326 0.000
15.823
4. ping showing that mtu up to and including 1300 is usable without
fragmentation.
C:\Documents and Settings\nated>ping -l 1300 -f 204.12.152.133
Pinging 204.12.152.133 with 1300 bytes of data:
Reply from 204.12.152.133: bytes=1300 time=56ms TTL=57
Reply from 204.12.152.133: bytes=1300 time=16ms TTL=57
Reply from 204.12.152.133: bytes=1300 time=22ms TTL=57
Reply from 204.12.152.133: bytes=1300 time=29ms TTL=57
Ping statistics for 204.12.152.133:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 56ms, Average = 30ms
________________________________________
From: [email protected] [[email protected]] On
Behalf Of William Yang [[email protected]]
Sent: Monday, March 01, 2010 5:40 PM
To: 'SunRay-Users mailing list'
Subject: Re: [SunRay-Users] EXTERNAL:Re: EXTERNAL: Sun Desktop AccessClient
(SDAC / soft client) poor performance
Maybe try Windows XP if you haven't already (sorry if I missed that you
already tried). I'm on XP and performance is great.
William Yang
-----Original Message-----
From: [email protected] [mailto:sunray-users-
[email protected]] On Behalf Of Devin Nate
Sent: Monday, March 01, 2010 7:25 PM
To: SunRay-Users mailing list
Subject: Re: [SunRay-Users] EXTERNAL:Re: EXTERNAL: Sun Desktop
AccessClient (SDAC / soft client) poor performance
Thanks Bob for the followup.
I've been up and down over mtu ... that was my guess at first too. I can
confirm by packet capture that SDAC is using a mtu no larger than the
slider in the client is set to for udp packets. Tcp packets appear to be
using pmtud and getting an fine mtu also.
I'm spinning up a host in our data center to test... but so far, no good
solutions have come out of this.
I suspect I'm going to need to get Oracle/Sun to open a case.. this is
frustrating enough that I'd like to get folks with access to the source
code involved. Where every other app works...?
I may get a Solaris SRS running here as well for comparative testing.
Anyhow, if anyone has any more ideas, let me know.
Thanks,
Devin
-----Original Message-----
From: [email protected] [mailto:sunray-users-
[email protected]] On Behalf Of Bob Doolittle
Sent: Monday, March 01, 2010 3:43 PM
To: SunRay-Users mailing list
Subject: Re: [SunRay-Users] EXTERNAL:Re: EXTERNAL: Sun Desktop
AccessClient (SDAC / soft client) poor performance
MTU settings sound more plausible than uttsc to me.
uttsc should not affect latency as measured by utcapture - that's purely
a metric measured between the X server and the client.
-Bob
Nishimura, Scott L (IT Solutions) wrote:
Devin,
I'll have to defer to more knowledgeable members of this list. The
performance you describe, however, is suspiciously similar to what we
experienced a few years back before we had tuned our MTU settings [we
ultimately settled on 1470]: when going through a PowerPoint stack,
we'd get 5-second delays in screen redraw.
The only other time I've seen something like this was when I was using
PCSC [PC Smart Card] 1.0 and when I got a normal workload on the SRS,
pcscd started taking up 6% of the CPU and users would see many 5-second
delays during their session.
Scott
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Devin Nate
Sent: Monday, March 01, 2010 2:27 PM
To: SunRay-Users mailing list
Subject: Re: [SunRay-Users] EXTERNAL:Re: EXTERNAL: Sun Desktop
AccessClient (SDAC / soft client) poor performance
Ahh, now that's something we haven't done yet... packet capture of the
uttsc data. So far we've done a packet capture of the dtu<-->srss and
compared with sdac<-->srss, and we couldn't see any difference there.
I'll report observations asap.
That said, would a difference in uttsc traffic to the terminal servers
cause utcapture to indicate a higher latency?
Thanks,
Devin
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Nishimura, Scott
L (IT Solutions)
Sent: Monday, March 01, 2010 3:16 PM
To: SunRay-Users mailing list
Subject: Re: [SunRay-Users] EXTERNAL:Re: EXTERNAL: Sun Desktop Access
Client (SDAC / soft client) poor performance
Devin,
How about if you run a truss or pstack or similar troubleshooting tool
on uttsc and compare the results between the actual DTU and SDAC?
Does your sniffer test show excessive retransmissions?
Also, what MTU size is being used? Too large [> 1470?] could lead to
fragmentation; too small [< 500] could lead to "laggy" performance
[we've run into that before on a physical DTU before].
Scott
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Devin Nate
Sent: Monday, March 01, 2010 2:06 PM
To: [email protected]; SunRay-Usersmailing list
Subject: EXTERNAL:Re: [SunRay-Users] EXTERNAL: Sun Desktop Access Client
(SDAC / soft client) poor performance
Hi Lars;
I completely agree... the problem is, the DTU and SDAC clients are on
identical networks... in fact, I've taken the cable out of a perfect DTU
and put it into a PC. I was thinking perhaps QoS or something tagging
the udp packages.
The PCs have Intel nic's. I'm tracking down totally different
architectures. Our core is all Cisco networking gear. We're looking to
setup a host on the same LAN directly connected to the core, that said
we had some hosts in the datacenter getting latency of 500.000, gig
connected but on a different subnet.
All that aside, the Sun DTU's work perfect on the same network. We're
going through everything with a fine tooth comb, but I'm not optimistic.
More thoughts?
Thanks,
Devin
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Lars Tunkrans
Sent: Monday, March 01, 2010 2:36 PM
To: SunRay-Users mailing list
Subject: Re: [SunRay-Users] EXTERNAL: Sun Desktop Access Client (SDAC /
soft client) poor performance
2010-03-01 20:31, Devin Nate skrev:
I'm really appreciating the ideas, please keep them coming?
Thanks,
Devin
Hi,
When I experience laggy screen updates on a DTU ist is usually
becase there is
a problem with the network .
As the list can testify:
One returning problem is Low end flaky L2 switches with a
gigabit input from the CORE switch
and 100Mbit link out to the DTU. These L2 switches drops UDP packets
and forces the DTU
to ask for them again . Hence the Laggy screen updates.
Now heres a long shot.....
if you are using mainly the same brand pc , do they all have the
same LAN Card / CHipset ?
There are many kinds of problems with Chinese wierdo combines of
PHY / MAC chipsets.
They come up with new combinations every week just to be able to
produce the motherboard 5 cents
cheaper.
Should you try an Intel Pro1000 GT Desktop adaptor ? I think
so.
http://www.intel.com/products/desktop/adapters/pro1000gt/pro1000gt-overv
iew.htm
This is probably the the most stable ethernet card today, since
3COM stopped making
ethernet cards.
Did you try to attach the PC directly to core switch yet ?
//Lars
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
--
Craig Bender
1-877-255-1537
Sun Ray Engineering
Sun Microsystems
A Wholly Owned Subsidiary of Oracle Corporation
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
