First of all, I need everybody to carefully qualify the builds they are
testing, or we'll get very confused.
SRSS 4.2 (and all of SRS 5) was finally released this morning!
o Sun Ray Software 5
------------------------------------------------------------------------------------------------
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/viewproductdetail-start?productref=srs-5-sp-lx-...@cds-cds_smi
o PC/SC-lite 1.2
------------------------------------------------------------------------------------------------
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/viewproductdetail-start?productref=pcsc-lite-1.2-sp-...@cds-cds_smi
o Sun Desktop Access Client 1.0
------------------------------------------------------------------------------------------------
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/viewproductdetail-start?productref=sdac-1.0-w-...@cds-cds_smi
So you can't have been testing with 4.2. I believe you were testing 4.2
EA2 release, correct? The 4.2 release doesn't require many workarounds
at all (other than adding the packages required that are not in the base
LiveCD distribution, and perhaps some workarounds if you're running an
older OSol build e.g. OS2009.06). I'll try to get to updating or adding
a TWiki page on the SunRay-Users website today.
Secondly, I appreciate your enthusiasm here but as OSol isn't yet
supported, I have to prioritize the work we're doing to get it to work.
At the moment I'm focusing on IPS delivery, since any bug fixes we want
to deliver post-4.2 won't be applicable any other way (i.e. patchadd is
not supported on OpenSolaris). Another way to look at that is, even if
we found and fixed a performance problem now it's too late for 4.2, so
it would have to be delivered in an update. Therefore, first we need to
build the mechanism to deliver updates :). That's IPS. Please don't get
impatient when we can't address your concerns immediately.
It might be a bit before we can get to any deep-dives regarding
performance on OSol. We will get there and appreciate your patience.
Please test with 4.2!
-Bob
marty scholes wrote:
В вт, 03/11/2009 в 12:08 +0300, Alexander Pyhalov пишет:
I have also noticed, that SRSS 4.2 is terribly slow on OpenSolaris build
126.
I have done a little work to try to narrow down the subjective redraw slowness
that I am seeing from 4.1 to 4.2.
* Fresh install of Osol 126.
* Fresh install of 4.2, I had to perform many of the hacks listed to get NSCM
running. Fresh install of 126 and 4.2 made no difference.
* Installing old 4.1 firmware made no difference.
* Turned on XRENDER, which seems to make Firefox a little faster.
I am more than a little stumped because CPU and network utilization are slower
under 4.2 than 4.1. Xterm is much faster than gnome-terminal on redraws.
Maybe this is some weirdo font issue?
I am running a Turion L2 which has a 512KB L2 cache, presumably shared between
the two cores.
I am starting to wonder if Xnewt's working set grew in size between 4.1 and
4.2, causing cache misses on smaller machines. I have never used cputrack
before, so I could be way off base here. I ran the following against the
primary Xnewt in the triple-head setup running Osol 126 and SRSS 4.2.
$ pfexec cputrack -T 1 -N 30 -c PAPI_l2_ich,PAPI_l2_icm -p 7598 > Xnewt.cputrack
During the sampling period I moved around virtual desktops causing lots of
redraw operations.
The output follows.
time lwp event pic0 pic1
1.015 1 tick 35595 15686
2.016 1 tick 13477 9830
3.015 1 tick 21318 12312
4.016 1 tick 137168 27670
5.015 1 tick 21838 7717
6.016 1 tick 22706 4294
7.018 1 tick 55755 6231
8.016 1 tick 90467 30179
9.016 1 tick 103697 39992
10.016 1 tick 162279 43373
11.016 1 tick 358338 65504
12.017 1 tick 47725 20075
13.016 1 tick 229462 35378
14.017 1 tick 227653 32036
15.017 1 tick 164112 35157
16.016 1 tick 27118 3689
17.017 1 tick 25974 4751
18.016 1 tick 21923 2158
19.017 1 tick 309315 44520
20.017 1 tick 189400 44045
21.017 1 tick 328216 45172
22.017 1 tick 234171 32971
23.017 1 tick 196143 30683
24.017 1 tick 79192 30028
25.008 1 tick 84344 32607
26.017 1 tick 68979 28282
27.017 1 tick 120616 28368
28.018 1 tick 18613 4769
29.017 1 tick 25599 5077
30.018 1 tick 22877 4436
Then I calculated the instruction hit ratio of the L2 cache.
$ cat Xnewt.cputrack | sed "s/ */ /g" | sed -n "2,$ p" | cut -d" " -f5,6 | sed "s/ / d
/" | sed "s/$/ 4 k +\/p/" | dc
I received what appears to be a pretty bad hit ratio over the period.
.6941
.5782
.6338
.8321
.7388
.8409
.8994
.7498
.7216
.7890
.8454
.7039
.8664
.8766
.8235
.8802
.8453
.9103
.8741
.8113
.8790
.8765
.8647
.7250
.7211
.7092
.8095
.7960
.8344
.8375
It is entirely possible, if not probable, that my sampling and math are wrong on this.
If correct, this says Xnewt's L2 instruction hit ratio hovers between 70% and 90%. I
don't know what a "good" hit ratio is, but I would imagine that it would
consistently exceed 95%.
Given the horrid memory latency/throughput that Turions are known for, would
this explain the drop in performance?
I am a little hesitant to fall back to 4.1 and rerun the tests, but if it would
help, I will try to do so this coming weekend.
All feedback appreciated.
Sincerely,
Marty
_______________________________________________
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
