Conference noted::hackers_v1

    Run more tests per 'startup'.  That is, keep and reuse the processes
    from one test to another.

    You might be able to use $CREPRC to create the (detached) processes.

    If this is important, ask VMS Development.  Most hackers are content
    with just a *few* processes.

    I used to do RTE simulations with Oracle, and I staggered logins
    by five or ten seconds. We did 70+ users this way.
    
    You should do what Gilbert suggests in .1. Run multiple simulations
    within a single session. Alternatively, synchronize everyone for some
    cue. You're probably going to want to still stagger things so everyone
    doesn't hit the first CR at the same time. 
    
    Modifying LOGINOUT to "trim the fat" (whatever that means) generally
    isn't legal in an RTE simulation. 
    
    	Jon

Running more tests per simulation is not applicable.  We have several
workloads that all run in different configurations with different
databases, software, etc.

As a matter of fact, I am a developer on the Oracle project, only
now it's called VAXRTE.  We do indeed stagger logins now, typically
by 5 seconds.  But some of our simulations are getting up to the
1000 user range.  (One 8800 back-end, many MicroVAX II front-ends,
and several RTEs to drive the whole mess).  Obviously, with such
configurations, you're lucky to get ONE run in, never mind many!!

But 1000*5 = 5000 seconds, divided by 3600 gives us 1.4 hours,
just to log in the users!!  You can reduce the stagger, but not
too low or you'll kill the processor with too many simultaneous logins.

Experiment like that might be just the beginning as DEC starts making
inroads in the OLTP market.  Thus the need for creating processes, FAST,
and getting on with the real analysis!!

	Rico

re Note 353.3 by SQM::RICO

You make it sound like all 1000 logins are done sequentially!
(probably not true, since that would be incredibly difficult to achieve)

How many MicroVAXen are we talking about here?  10, 20, 50?
I have seen MVAXen with 24 RS232 lines on them.

960 users / 24 lines = 40 MicroVAXen

That brings your login time down to

24*5 = 120 seconds, divided by 60 gives us 2 minutes.
with 40 simultaneous logins every 5 seconds. (approximate)

If that is too many logins, make it semi-random from 5-15 second delays
and you will still get a reasonable login time.

Playing with similar numbers (more or less MVAXen, lines etc)
gives MUCH better results than the 1.4 hours you quoted.

Scott

RE: < Note 353.4 by CANYON::HESTERMAN "Scott Hesterman" >

    You are oversimplifying and assuming a lot about our environment!

    First of all, we don't even use RS232 lines, we actually use LAT
    connections.  This means that the only required hardware on the
    MicroVAX front ends for terminal connections is a QNA.

    We have already done runs with as many as 150 users on a single
    MicroVAX II, with only 42% of the CPU utilized and no I/O bottleneck.
    In these experiments we had an 8700 RTE, two uVAXen, and a single
    785 back-end (300 user experiment).  MicroVAXen will be heavily
    targeted at such applications in the future as front-end processors,
    with many, many more than 24 simultaneous user sessions.

    Your second point is valid.  We do stagger our logins regardless
    of the number of front end processors involved.  We could rewrite
    scripts so that one login is being done on each MicroVAX simultaneously.
    The reason we haven't done that is because in several instances, we
    have to use multiple RTE processors.  The communication between the
    processors is minimal, and thus it is easier to stay with the one
    at a time method, for now.

    When I said 1000 users, I was looking slightly into the future.
    But only slightly -- we'll be using those sorts on configurations
    next quarter.  Say we use five front-ends and we do five simultanous
    logins at a time.  That's still 200*5 = 1000 seconds = 16.67 minutes.

    There are other reasons why my original idea is not too feasible
    which I hadn't considered at first; I won't go into detail here.
    
    Thanks for the replies...

            Rico