eValid™ -- Automated Web Quality Solution Browser-Based, Client-Side, Functional Testing & Validation, Load & Performance Tuning, Page Timing, Website Analysis, and Rich Internet Application Monitoring.

Experiment Design
For a specific load driver machine type/class the experiment we will run is outlined as follows:

1. Single large machine, 10 users, 100 BUs per user = 1,000 BUs overall.
2. For 1000 BUs in parallel:
   1. Start at "about:blank"
   2. WaitModMM for next even minute
   3. Download 1 KB file and report elapsed time to $Machine$User$_Track.
   4. WaitModMM for next even minute
   5. Download 10 KB file and report elapsed time to $Machine$User$_Track.
   6. WaitModMM for next even minute
   7. Download 100 KB file and report elapsed time to $Machine$User$_Track.
   8. WaitModMM for next even minute
   9. Download 1,000 KB file and report elapsed time to $Machine$User$_Track.
3. This will result in 1,000 separate SaveRecord files from which we can analyze the degree of simultaneity and the variance in download speed.

We Expect To Show
This experiment will demonstrate the capacity, for a single driver machine, at 1,000 BUs, the ability to simultaneously launch page downloads. Key Question: How simultaneous are the requests?

For 1/10/100/1,000 KB files, we ought to see fairly constant download speeds, but the larger files will have a slower rate because the files are all being served from our machine. Key Question: How constant are the reported download times?

This Experiment Antidote For
This experiment is an antidote for a range of accusations about eValid in LoadTest mode.

Results
Here are results of the experiments so far:

• RUN/STOP Manual Mode at Default Retry Interval (500 msec = 2 Hz).
  • In the setup of 100 wide, using the RUN/STOP page, the BUs achieved simultaneous start within 10 seconds.
  • There appears to be some jitter in the HTTP download times which needs further study.
  • If the default rate of 2 Hz (500 msec) the 100 BUs will take ~5 sec to sync.
• WaitModMM Mode at Default Retry Interval (500 msec = 2 Hz).
  • Using WaitModMM 05 the startup delay ranges from 3-10 seconds for 100 BUs all trying to start at the same time.
  • This stagger appears to be the result of polling sequences in/between the 100 BUs.
  • If the default rate of 2 Hz (500 msec) the 100 BUs will take ~5 sec to sync.
• WaitModMM Mode at Fastest Retry Interval (10 msec = 100 Hz).
  • Now the interval of retry is 10 msec, but the stagger is still there.
  • The starting times range from 3 to 16 sec, average 7.2 seconds, that is, that all 100 of the tests start on average within 7.2/2 = 3.6 secs of one another.
  • Looks like that is the best we can do.
• Conclusion: 100 BUs will sync to within 10 seconds of simultaneous start using the internal sync commands. Or, within 5 seconds of each other -5/+5...