| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3361.1 | What happens? | TOOK::MINTZ | Erik Mintz, dtn 226-5033 | Wed Jul 15 1992 08:51 | 2 |
| I don't know of anyone else who has tried this experiment.
What happens when you try to start the 8'th iconic map?
|
| 3361.2 | 8 at once is OK ! | WARNUT::PURNELLR | Life, it's not what I thought it was ! | Wed Jul 15 1992 10:19 | 17 |
|
The DECsystem seems to have plenty of memory free, the CPU is balanced
45% each between the users and the system with just over 10% idle.
This process takes approximately 6/7 minutes.
Initially I was firing the displays one after the other, I found that
by firing all 8 at once....low and behold thay all initiated within 90
seconds.
I shall now up the number of displays.
:*(
Rex
|
| 3361.3 | Benchmark - more data | WOTVAX::PURNELLR | Life, it's not what I thought it was ! | Thu Jul 16 1992 09:55 | 66 |
|
Further to .1
The DECsystem is now firing displays alternately to one of either 2
DECstations or a VAXstations. We are using the ROOT account for the exercise. There are 4 entities in
the top domain & notification is disabled.
The domain structure is this;
.TOP
-----------------|---------------
.ip .node4 .uk_decnet
| | |
1 entity 700 entities 30 entities & 78 domains
|
700 entities
We fire a display, time the arrival off the map on the target workstation
(ie. all entities displayed) and then monitor the continued activity of
the mcc processes until the CPU is idle - then the next display was
fired.
We found that once the map was live, the processor could still be busy for
some time running both the iconic map and domain still clocking time.
When we started the mcc_domain_fm process was using 70-80% of the cpu,
by the time we have the eigth display - we are down to 9% whilst the
cpu is still flat out. We are the only users on this system.
The timings are as follows (all in seconds);
Display fired - | 1 2 3 4 5 6 7 8
-----------------|-----------------------------------------
Time to complete | 17 14 15 17 27 39 52 220
map on screen |
-----------------|-----------------------------------------
mcc_domain_fm |
processing time | 38 48 60 80 115 180 468 1200* still
for each new | running
display |
-----------------|-----------------------------------------
mcc_iconic_map |
processing time | 11 12 14 19 25 37 80
for each new |
display process |
|
What is the mcc_domain_fm process doing all this time (whilst there is
no operator intervention) ?
Why does each map initialisation take significantly longer ?
Why are maps that are initialised but not touched using cpu time ?
NB. Each map seems to use 10000 virtual pages (SZ field on "ps -u"), but
the mcc_domain_fm process sticks at 2092. The RSS field values are 5404
and 1400 respectively.
&*)
Rex
|
| 3361.4 | more data from today's tests | BAHTAT::BOND | | Mon Jul 20 1992 13:41 | 39 |
| Hi,
More Data to Help you. I don't confess to understand the significance
of it but I hope it helps. We created an empty domain to try to
eliminate some of the heavy processing seen by the DOMAIN FM to see if
we could get 'smaller' maps to fire up more consistantly. Notification
was enabled. The results are even more suprising.
With 7 maps displayed, notification enabled, but no events arriving, no
user action on the maps, the cpu is all but used. The iconic_map
processes continue to clock up cpu time although 'apparently' nothing
is happening. I could understand them using some small background
amount of cpu time, but 7 should not swamp a 5000-240.
We repeated the 'empty domain' test on a VAX/VMS 4000-300. We got very
consistent results here with each new map taking a little bit longer to
fire up than the last until we ran out of memory. We got to 22.
CPU used with no maps active was just a few percent. This is what we
would expect. Actual cpu used was between 21 and 25 seconds to start
the maps and elapsed time between 33 and 41 seconds.
Here are the figures for the Ultrix test:
Map 1 Map 2 3 4 5 6 7
Map elapsed 15 17 20 25 35 75 280
Map Cpu 9 11 14 19 27 57 138
Interrupts 260 260 263 265 265 272 270
Sys Calls 2157 4072 5850 7646 9327 10228 10915
Cont Switch 255 506 760 1005 1248 1450 1638
Us Mod CPU 0 0 1 1 4 12 51
Sys Mod CPU 1 2 3 4 6 44 45
Idle CPU 99 98 96 95 90 44 4
All measurements come from vmstat and ps -u.
The Interrupts through Idle CPU figures are taken AFTER the map has
been displayed on the screen, ie they are quiescent figures. There is
no operator activity on the map. Whilst the map is actually
initialising, the cpu is 100% used and the INT/SYS/CS figures are
higher. There is no paging or swapping occuring (according to vmstat).
|
| 3361.5 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Jul 30 1992 10:36 | 13 |
| This is under investigation. We can reproduce the problem here.
Unfortunately the initial signs point to the kludges we had
to implement to get X dispatching to work with threads. We have
to poll the X event queue since an Xevent wait will normally block
the process and this seems to be where the time is spent (in fact
the problem can be seen if you kill off all MMs other than the maps -
it has nothing to no with domains, notifications, or anything like
that).
What we don't understand yet is why this works on VMS since the same
hack is employed there. Something in the underlying implementation
of our poller daemon is very different on the 2 systems.
|