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
