Experimental Results

The primary measurement in my experiments was latency. Latency was measured during puzzle piece drag operations. It was calculated as the elapsed time from the user’s initiation of a cursor movement while holding a piece, until the first draw

operation corresponding to that user action was executed. Each measured latency corresponded to moving the piece a few pixels, not to the entire drag of the piece. Thus, there were many measurements for one drag of a piece. See Section 6.7, and Figure 6.58 in particular, for more details.

The introduced network delays simulated the delays of a Local Area Network (LAN) (0 ms), intranet (50 ms), and Wide Area Network (WAN) (100 ms). Latency in a pure centralized system was demonstrated, as expected, to be O(2 * network transmission time) (Figure 1.25). Latencies with the migrating architecture were confirmed to be similar to those of the replicated architecture (Figure 1.26). This is the single most important result of my experiments.

Entity migration was confirmed to be O(4 * network transmission time), as ex- pected (Figure 1.27). (Look at the data near the middle of each plot, after most pieces have been moved from the server to a client, and before contention for pieces begins to take over.)

Predictive migration techniques based on telegraphed user intentions were com- pared with prediction based on past interaction history. The prediction algorithm used was cursor vectoring (migrating puzzle pieces toward which the cursor is mov- ing). Prediction based on past interaction history was implemented by simply leaving each piece where it was last used. Figures 1.28 and 1.29 show the advantage of using telegraphed user intentions as a prediction mechanism. The migration hit ratio is the probability that a piece is already migrated to the user’s client when he picks it up to move it. (The former graph includes only completely migrated pieces, while the latter includes pieces that have begun but not completed migration.) The advantage decreases as the number of users increases, due to contention over pieces. This type of prediction is enabled by the speed of Concur’s lightweight entity migration.

Figure 1.27: Migration Latency over Time

1.32 show that latencies typically increase and task completion times typically de- crease with an increase in the number of users, for all architectures and introduced latencies. Network bandwidth utilization during interaction was better with migra- tion than without (N messages per interaction, where N is the number of participants in a collaborative conference, instead of N+1 in centralized case, per Figure 1.33). This is significant when N is small, which true of most collaborative sessions. (See Figure 1.34, which only shows messages received by clients.) CPU utilization for both server (Figure 1.35) and client (Figure 1.36) were similar for all three architec- tures6_{. However, both server CPU and network utilization can be reduced to zero for}

the migrating architecture in the fairly common case where only a single user is view- 6_{The replicated architecture’s server CPU utilization is artificially high, because the replication} algorithm synchronized replicas through the central server.

Figur e 1.2 8: Adv an tage of P re dict ion based o n T eleg raphed Use r In ten tions

Figur e 1.2 9: Adv an tage of P re dict ion based o n T eleg raphed Use r In ten tions when P art ial M ig rat ion is Included

Figure 1.30: Latency and Task Duration By User Count, Latency 0ms

ing a particular entity at a particular point in time. For example, if multiple users are collaborating on a large puzzle, any puzzle pieces viewable by only one user (due, for example, to scrolling of a large workspace or document) can migrate to that user’s client, and any interactions with those pieces need not use any network bandwidth or central CPU cycles. This optimization was not implemented in the prototype.

There was one important and dramatic scalability result, shown in Figures 1.37 and 1.38. These figures show that the migrating architecture scales as well as the replicated architecture, and much better than the centralized architecture, in terms on user-perceived latency as the number of users increases.

Task completion time varied a great deal due to the small size of the puzzle, the random placement of the puzzle pieces, and the independent and randomized be- havior of the per-user solvers. Figure 1.39 shows the average task completion time

Figure 1.31: Latency and Task Duration By User Count, Latency 50ms

for each architecture, with separate averages for the migrating architecture with and without migration prediction. While average task completion time for the migrating experiments was lower than for the centralized architecture, it was higher than ex- pected. This was due to the migrating architecture tending toward the performance of the centralized architecture toward the end of the puzzle solution when contention for pieces increases (Figure 1.40), and the short length of the experiments. In longer experiments this tendency toward centralized performance would be amortized over a longer period. The migrating architecture can also thrash on piece migrations to- ward the end of the solution. This effect was more pronounced in the predictive experiments due to the length of time between predictive migration and actual use of a piece (Figure 1.41). This effect could be diminished by increasing hysteresis in the migration algorithm and by migrating the piece to the physical center in order

Figure 1.32: Latency and Task Duration By User Count, Latency 100ms

Figure 1.34: Message Counts by Architecture

to diminish thrashing. (The experiments included some degree of hysteresis, but did not migrate pieces to the center.)

Example program code is presented as evidence of the ease of construction of applications for my infrastructure. The text editor, drawing editor, and jigsaw puz- zle were implemented in 322, 394, and 965 lines of code, respectively, as shown in Figure 6.2. This code was implemented for a centralized architecture, and is collaboration-unaware.

The usability of the system is argued from two standpoints. First, I demonstrated that the more complex user mental model required for replicated systems is unnec- essary for my architecture, because it is fundamentally centralized. Second, I have demonstrated the utility of the entity classification with respect to identifying and implementing useful divergence scenarios.

Figure 1.35: Server CPU Utilization

In sum, the most dramatic result of this work is to show that predictive, lightweight entity migration based on telegraphed user intentions reduces latency to near repli- cated architecture levels in what is still fundamentally a centralized architecture.