[net.unix] vax 785 vmstat

salmi@dicomed.UUCP (salmi) (01/22/86)

i have just recently brought up ultrix 1.1 on a vax 785.  after running the
recently distributed dhrystone benchmarks on the new system, i was appalled at
the outcome, somethint like 50000 passes in 102 seconds! (480 stones/sec?)

running vmstat on the system gives the following results, with one user on the
system...


# vmstat 2
 procs     memory                       page      disk  faults          cpu
 r b w   avm  fre  re at  pi  po  fr  de  sr r0 x1 x2 x3  in  sy  cs us sy id
 1 0 0   445 7769   0  0   0   0   0   0   0  3  0  0  04994  18   4  1 82 17
 1 0 0   445 7769   0  0   0   0   0   0   0  0  0  0  05156 163   5  0 83 17
 1 0 0   445 7769   0  0   0   0   0   0   0  0  0  0  05170 107   3  0 83 17
 0 0 0   423 7746   0  0   0   0   0   0   0  0  0  0  05178  73   1  0 81 19
 0 0 0   423 7746   0  0   0   0   0   0   0  0  0  0  05183  49   0  0 84 16
 0 0 0   476 7742   0  0   0   0   0   0   0  2  0  0  05179  35   0  0 81 18
 0 0 0   476 7742   0  0   0   0   0   0   0  0  0  0  05182  26   0  1 78 21
 0 0 0   476 7742   0  0   0   0   0   0   0  0  0  0  05187  20   0  1 84 15
 0 0 0   157 7742   0  0   0   0   0   0   0  0  0  0  05190  16   0  1 82 17
 0 0 0   157 7742   0  0   0   0   0   0   0  0  0  0  05192  13   0  0 84 16
 0 0 0   375 7742   0  0   0   0   0   0   0  0  0  0  05201   8   0  0 82 18

the interupts per second are averaging more the 5000 on an 'idle' system.  our
loaded up vax 750 running 4.2 gives the following results from vmstat...


# vmstat 2
 procs     memory                       page      disk  faults          cpu
 r b w   avm  fre  re at  pi  po  fr  de  sr h0 r0 u0 f0  in  sy  cs us sy id
 2 0 0  1139 3207   0  1   0   0   0   0   0  3  0  1  0   4  68  20 18 25 57
 1 0 0   911 3185   0  0   0   0   0   0   0  0  0  0  0   3 239  18  6 19 74
 1 0 0   911 3185   0  0   0   0   0   0   0  0  0  0  0   2 180  14  3 14 83
 1 1 0   868 3176   0  0   0   0   0   0   0 20  1  0  0  10 133  13  5 22 73
 1 1 0   868 3176   0  0   0   0   0   0   0  0  0  0  0   6 111  10  4 13 83
 0 0 0   629 3173   0  0   0   0   0   0   0  0  0  0  0   4  96   8  4 19 77
 0 0 0   629 3173   0  0   0   0   0   0   0  0  0  0  0   2  88   8  3 15 82
 0 0 0   629 3173   0  0   0   0   0   0   0  0  0  0  0   2  88   9  6 16 77

all of the ports had been shut off on the 785, thinking that a runaway getty
may have been the culprit, but no change was evident.  another thought was the
DEC ethernet board may be the bad guy.

anyone got any clues/ideas?  the 785 must be fast, as the response time was
fairly fast even with the 5000+ interupts/second running rampant.

any/all ideas would be appreciated.  please respond directly to me at:

ihnp4!dicomed!salmi

john salmi
dicomed corporation
minneapolis, mn
612/885-3000

and, as always, thanks in advance :-)

lrr@princeton.UUCP (Larry Rogers) (01/24/86)

In article <710@dicomed.UUCP> salmi@dicomed.UUCP (salmi) writes:
>i have just recently brought up ultrix 1.1 on a vax 785.  after running the
>recently distributed dhrystone benchmarks on the new system, i was appalled at
>the outcome, somethint like 50000 passes in 102 seconds! (480 stones/sec?)
>
>running vmstat on the system gives the following results, with one user on the
>system...
>
>
># vmstat 2
> procs     memory                       page      disk  faults          cpu
> r b w   avm  fre  re at  pi  po  fr  de  sr r0 x1 x2 x3  in  sy  cs us sy id
> 1 0 0   445 7769   0  0   0   0   0   0   0  3  0  0  04994  18   4  1 82 17
> 1 0 0   445 7769   0  0   0   0   0   0   0  0  0  0  05156 163   5  0 83 17
> 1 0 0   445 7769   0  0   0   0   0   0   0  0  0  0  05170 107   3  0 83 17
> 0 0 0   423 7746   0  0   0   0   0   0   0  0  0  0  05178  73   1  0 81 19
> 0 0 0   423 7746   0  0   0   0   0   0   0  0  0  0  05183  49   0  0 84 16
> 0 0 0   476 7742   0  0   0   0   0   0   0  2  0  0  05179  35   0  0 81 18
> 0 0 0   476 7742   0  0   0   0   0   0   0  0  0  0  05182  26   0  1 78 21
> 0 0 0   476 7742   0  0   0   0   0   0   0  0  0  0  05187  20   0  1 84 15
> 0 0 0   157 7742   0  0   0   0   0   0   0  0  0  0  05190  16   0  1 82 17
> 0 0 0   157 7742   0  0   0   0   0   0   0  0  0  0  05192  13   0  0 84 16
> 0 0 0   375 7742   0  0   0   0   0   0   0  0  0  0  05201   8   0  0 82 18
>
>the interupts per second are averaging more the 5000 on an 'idle' system.  our
>loaded up vax 750 running 4.2 gives the following results from vmstat...
>
>
># vmstat 2
> procs     memory                       page      disk  faults          cpu
> r b w   avm  fre  re at  pi  po  fr  de  sr h0 r0 u0 f0  in  sy  cs us sy id
> 2 0 0  1139 3207   0  1   0   0   0   0   0  3  0  1  0   4  68  20 18 25 57
> 1 0 0   911 3185   0  0   0   0   0   0   0  0  0  0  0   3 239  18  6 19 74
> 1 0 0   911 3185   0  0   0   0   0   0   0  0  0  0  0   2 180  14  3 14 83
> 1 1 0   868 3176   0  0   0   0   0   0   0 20  1  0  0  10 133  13  5 22 73
> 1 1 0   868 3176   0  0   0   0   0   0   0  0  0  0  0   6 111  10  4 13 83
> 0 0 0   629 3173   0  0   0   0   0   0   0  0  0  0  0   4  96   8  4 19 77
> 0 0 0   629 3173   0  0   0   0   0   0   0  0  0  0  0   2  88   8  3 15 82
> 0 0 0   629 3173   0  0   0   0   0   0   0  0  0  0  0   2  88   9  6 16 77
>
>all of the ports had been shut off on the 785, thinking that a runaway getty
>may have been the culprit, but no change was evident.  another thought was the
>DEC ethernet board may be the bad guy.
>
>anyone got any clues/ideas?  the 785 must be fast, as the response time was
>fairly fast even with the 5000+ interupts/second running rampant.
>
>any/all ideas would be appreciated.  please respond directly to me at:
>
>ihnp4!dicomed!salmi
>
>john salmi
>dicomed corporation
>minneapolis, mn
>612/885-3000
>
>and, as always, thanks in advance :-)

I also have Ultrix 1.1 running on a VAX-11/785 with the ports disabled and
the Deuna enables and I get:

 procs    memory            page                  disk        faults     cpu   
 r b w  avm    fre   re at  pi  po  fr  de  sr r0 r1 r2 r3  in  sy  cs us sy id
 2 3 0 66367  58438   0  0   0   0   0   0   0  0  0  1  0   2   7  13 92  2  6
 2 3 0 66367  58438   0  2   1   0   0   0   0  0  0  3  0  19 341  29 96  4  0
 2 3 0 66367  58438   0  1   0   0   0   0   0  0  0  0  0  15 277  26 96  4  0
 2 3 0 66367  58438   0  0   0   0   0   0   0  0  0  0  0  12 226  23 98  2  0
 2 0 0 66291  58408   0  0   0   0   0   0   0  0  0  0  0   9 185  21 98  2  0
 2 0 0 66291  58408   0  0   0   0   0   0   0  0  0  0  0   7 153  19 97  3  0
 2 0 0 66291  58408   0  0   0   0   0   0   0  0  0  2  0   6 129  19 92  8  0
 2 0 0 66291  58408   0  0   0   0   0   0   0  0  0  0  0   7 113  19 93  7  0
 2 0 0 66291  58408   0  0   0   0   0   0   0  0  0  0  0   8 101  19 95  5  0
 2 0 0 66366  58398   0  0   0   0   0   0   0  0  0  0  0   9  97  19 96  4  0
 2 0 0 66366  58398   0  0   0   0   0   0   0  0  0  1  0   8  83  19 95  5  0
 2 0 0 66366  58398   0  0   0   0   0   0   0  0  0  0  0   8  74  19 94  6  0
 2 0 0 66366  58398   0  0   0   0   0   0   0  0  0  1  0   9  68  19 93  7  0
 2 0 0 66366  58398   0  0   0   0   0   0   0  0  0  0  0   8  62  19 94  6  0
 2 0 0 66344  58394   0  0   0   0   0   0   0  0  0  0  0   9  62  20 98  2  0
 2 0 0 66344  58394   0  0   0   0   0   0   0  0  0  0  0   7  55  19 94  6  0
 2 0 0 66344  58394   0  0   0   0   0   0   0  0  0  0  0   9  55  19 95  5  0
 2 0 0 66344  58394   0  0   0   0   0   0   0  0  0  1  0  10  53  19 95  5  0

Only a normal number of interrupts.  If you look at the output
carefully, you may get the impression that this machine has (66344+58394)K
of memory, roughly 124M.  This is indeed correct as we have 128M on this
baby.  We don't page much.


Larry Rogers
Princeton University
Department of Computer Science
Engineering Quadrangle Building, Room C334
Princeton, NJ 08544

UUCP:	princeton!lrr
CSNET:	lrr%princeton@CSnet-relay
PHONE:	609 452 6483

wls@astrovax.UUCP (William L. Sebok) (01/25/86)

In article <1202@princeton.UUCP> lrr@princeton.UUCP (Larry Rogers) writes:
>...   If you look at the output
>carefully, you may get the impression that this machine has (66344+58394)K
>of memory, roughly 124M.  This is indeed correct as we have 128M on this
>baby.  We don't page much.

But when they do page ... wowee!
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,vax135}!astrovax!wls