Tiểu luận môn học Tính toán khắp nơi Đo và chèn độ chễ vào trong ứng dụng Web

1

Phụ lục
1. Mục tiêu và nền tảng 2
2. Existing Tools – công cụ hiện có 3
2.1. Đo độ trễ 3
2.1.1. RUI (Penn State) 4
2.1.2. VIA (Rensselaer) 4
2.1.3. X11 + Record extension (Ghi mở rộng) 4
2.1.4. Wireshark 5
2.2. Độ trễ Injecting 5
2.2.1. Tầng ứng dụng 5
2.2.2. Tầng mạng 6
3. Công cụ 7
3.1. Bàn phím, chuột và tiêu đề log. 7
3.2. Trễ tầng ứng dụng và lưu log. 13
3.3. Delay mạng. 14
3.4. log network 14
4. Hợp chuẩn 14
4.1. Thiết lập thử nghiệm 14
4.2. Phân tích 15
4.3. Kết Quả 18
5. Acknowledgements 20
2

1. Mục tiêu và nền tảng
Trong điện toán di động và các ngữ cảnh khác, độ trễ thường gây ra nhiều
trở ngại hơn là băng thông. Sự ảnh hưởng của hiệu năng dựa trên đáp ứng trễ thấp
đến người dung. Vì vậy câu hỏi đặt ra là bao nhiêu hiệu năng là cần thiết khi mà
ứng dụng vẫn mở.
Ngày nay thì trọng tâm của ảnh hưởng hiệu năng của các trang web, ví dụ

như Galletta thấy được hiệu quả của độ trễ trong hiệu năng, thái độ và ý định
người dung. Kể từ thời điểm Galletta làm việc, một loại tương tác mới được nhúng
vào trong web, kết hợp với các xử lý nội bộ cộng với nền tảng truyền thông của
máy chủ. Một vài cái tên cho phương pháp tương tác mới này bao gồm Web 2.0,
AJAX, và các ứng dụng Rich Internet.
Trong ứng dụng web 2.0, có rất nhiều nguồn tiềm năng của độ trễ. Chúng
bao gồm:
 Trễ xử lý nội bộ
 Trễ từ xa
 Trễ do mạng
Các nguồn này có các biểu hiện khác nhau và với điều kiện khác nhau. Khi
thiết kế hệ thống cho framework web 2.0, nó cung cấp biện pháp quan trọng trong
việc đo độ trễ tồn tai như việc mô phỏng độ trễ mới, qua tất cả các phần của hệ
thống.
Trong phiên bản mới trong thử nghiệm 8A về việc xây dựng một mô hình
tương quan của hiệu năng người dung với giao diện hiện đại. Người dùng thừa
hưởng các phím tắt để điều khiển qua website và dòng text và mô hình phỏng
đoán có hiệu năng chậm hơn so với quan sát trực tiếp. Sauk hi kiểm tra mô hình
hệ thống tương quan (mô hình dựa trên một phần kết quả của thử nghiệm 8A), giả
3

thuyết rằng kết quả thử nghiệm được tạo ra năm 1983 không phỏng đoán chính
xác máy tính người dùng ngày nay.
Trong phiên bản mới của thử nghiệm xây dựng năm 2008, và thử nghiệm
này đang chạy, không có hệ thống log chính xác đủ để sử dụng. Trong một vài
tình huống, bộ log chậm hơn máy tính nên cần nhân đôi thời gian thử nghiệm.
Mục đích để tạo ra bộ log tốt và chính xác hơn cho Card, Moran và Newell sử
dụng trong việc kiểm thử nghiện nam 1983. (Thử nghiệm ban đầu chỉ rõ độ cho
phép của một log là 33ms. Cho đến khi ta đưa hệ thống vào trong báo cáo, vẫn
chưa tìm được một hệ thống log chính xác và có thể chạy cho thử nghiệm này.

2. Existing Tools – công cụ hiện có
Đối với dự án này, trước tiên chúng ta đánh giá một số công cụ cho cả hai
đo lường và tiêm chích độ trễ. Một số công cụ rất có ích với một số thay đổi, và
những người khác đã có thể sử dụng trực tiếp
2.1. Đo độ trễ
Độ trễ có thể được đo bằng cách lấy chênh lệch thời gian giữa các hành động
người dùng và hệ thống phản ứng. Đối với công việc của chúng tôi, chúng tôi
muốn ghi lại hoạt động của bàn phím và chuột ở độ phân giải thời gian cao (trong
vòng 10 ms của jitter). Mức độ phân giải là cần thiết vì điều thú vị trong nhận
thức con người xảy ra ở khoảng thời gian này.
Ban đầu, chúng tôi muốn để có thể đo độ trễ trên cả hai hệ điều hành
Windows và Mac. Vì lý do này, đầu tiên chúng tôi tìm hiểu về RUI [8] và VIA
[7].


4

2.1.1. RUI (Penn State)
RUI [8] (Recording User Input), có sẵn tại
/, được phát triển cho Windows và Mac OS để
ghi và phát lại đầu vào bàn phím và chuột.
2.1.2. VIA (Rensselaer)
VIA [7] (Visualization Interaction Architecture), có sẵn tại
/ cogworks /? view = modules.research.spec & id = 63,
là một cơ chế dựa trên mạng để đăng nhập. Một phần nhỏ của mã được viết cho
mỗi nền tảng trong sự kiểm tra mà kết nối đến một máy chủ phải đăng nhập qua
giao thức TCP / IP. Mục tiêu của nó tương tự như RUI: là một công cụ tương tác
mạnh mẽ để đăng nhập của con người.
2.1.3. X11 + Record extension (Ghi mở rộng)
Mặc dù ban đầu chúng tôi muốn có một hệ thống đăng nhập làm việc trên

Windows và Mac OS, chúng tôi nhận ra rằng nó đã có thể nới lỏng hạn chế này.
Bởi vì chúng ta đã quan tâm đến thử nghiệm người dùng tương tác với một ứng
dụng web (Google Calendar), chúng ta có thể làm tốt bằng cách sử dụng trình
duyệt Firefox trên một hệ thống dựa trên Linux với hệ thống cửa sổ X11. Sự linh
hoạt của hệ thống này cho phép chúng ta cấu hình con chuột và bàn phím để làm
việc như họ làm trên một trong hai máy Mac hoặc PC: một cân nhắc quan trọng
cho người sử dụng ngay cả khi sử dụng một ứng dụng đa nền tảng như một trình
duyệt.
Một công cụ khác mà chúng tôi đã xem xét là PyKeylogger [5]. Trong khi
nó tốt hơn Xnee theo cách nào đó, nhưng nó đã không nắm bắt được các định thời
chính xác cho các thao tác bàn phím và di chuyển chuột. Mặc dù nó sẽ có thể để
tùy chỉnh PyKeylogger làm việc như chúng tôi cần, Xnee làm việc đủ tốt cho đến
5

bây giờ mà chúng tôi đã không dành những nỗ lực của các tuỳ biến vào thời điểm
này.
2.1.4. Wireshark
Wireshark [3] là một chương trình chụp và phân tích các gói mạng. Nó rất
hữu ích trong đăng nhập lưu lượng mạng mà đi giữa các máy tính địa phương và
bất kỳ máy chủ từ xa. Lọc gói dữ liệu tinh xảo và phân tích đều có sẵn. Mặc dù
chúng tôi đã không hẳn sử dụng chức năng tiên tiến này, nó có thể sẽ hữu ích
trong tương lai.
2.2. Độ trễ Injecting
Phần thứ hai của hệ thống liên quan đến độ trễ Injecting vào hệ thống. Điều
này cho phép chúng ta kiểm tra giả thuyết về tâm lý liên quan đến phản ứng của
người sử dụng để thay đổi thời gian đáp ứng của hệ thống. Bởi vì độ trễ trong các
phần khác nhau của hệ thống sẽ thể hiện theo những cách khác nhau, chúng ta cần
phải có độ trễ Injecting ở những nơi khác nhau.
2.2.1. Tầng ứng dụng
Để độ trễ Injecting ở mức ứng dụng, người ta phải đánh chặn và trì hoãn sự

kiện đến từ người sử dụng hoặc trì hoãn việc hiển thị thông tin sẽ tới người sử
dụng.
Trong một nghiên cứu hiện tại [6], chúng tôi nhận thấy độ trễ đã được
Injecting sử dụng các trang web tuỳ chỉnh với một chức năng chậm trễ viết bằng
JavaScript. Công việc này khi một thử nghiệm (như của Galletta) có toàn quyền
kiểm soát tất cả các nội dung, nhưng nó không hoạt động khi chúng ta không kiểm
soát các máy chủ cũng như các trang (như Google Calendar). Trong phần tiếp
theo, chúng tôi thảo luận về giải pháp của chúng tôi về vấn đề này.

6

2.2.2. Tầng mạng
Có rất nhiều cách để độ trễ Injecting ở cấp độ mạng, cả trong phần mềm và
phần cứng. Chúng tôi sẽ xem xét hai công cụ hiện có mà chúng ta đã quen thuộc
với: NetEm [10] và công nghệ Linktropy 4500 [1]. Cả hai làm việc trên cùng một
nguyên tắc, bằng cách làm chậm hoặc hạn chế các gói dữ liệu mạng, độ trễ mạng
có thể được mô phỏng. Sự khác biệt là trong việc thực hiện: NetEm là phần mềm,
nhúng vào trong hạt nhân Linux, và Linktropy là một thiết bị phần cứng mà ngồi
độc lập trong một rack.
Với NetEm, cách tiêu chuẩn của độ trễ Injecting là một lệnh như thế này: “
tc
qdisc add dev eth0 root netem delay 100ms”
. Điều này sẽ dẫn đến một sự chậm
trễ đi 100 ms để các thiết bị mạng
eth0
. Nhiều hơn các thiết lập phức tạp có sẵn,
bao gồm giới thiệu gói tin bị mất, sao chép, và sắp xếp lại. Tất cả những sự kiện
được tạo ra bởi các bản phân phối thống kê tùy biến, cho phép cho các mô phỏng
rất thực tế. NetEm không có vấn đề với mô phỏng mới hơn các mạng vô tuyến
dựa trên (UMTS, WiMAX, và những cái khác), nhưng công việc đang được triển

khai đến địa chỉ này [4].
Các Linktropy 4500 về cơ bản gói gọn các chức năng của NetEm vào một
thiết bị phần cứng với một giao diện người dùng đơn giản dựa trên web. Một trong
những công cụ này có thể làm việc để độ trễ Injecting, mặc dù NetEm có thể hữu
ích hơn cho nhanh chóng và tự động thay đổi các thông số (ví dụ, giữa các trường
hợp thử nghiệm), và ra các quyết định cho mỗi gói tin về làm thế nào để áp dụng
cài đặt mô phỏng.



7

3. Công cụ
Như đã đề cập trong phần trước, chúng ta bắt đầu với ý tưởng sử dụng các
phần mềm hỗ trợ đa nền tảng cho việc lưu log. Kinh nghiệm sử dụng các nền tảng
web, chúng ta có thể sử dụng nền tảng Linux chạy X11. Nó cho phép chúng ta
mềm dẻo trong việc log và thêm độ trễ.
3.1. Bàn phím, chuột và tiêu đề log.
Để log bàn phím và chuột, chúng ta giải quyết sử dụng Xnee với bản ghi mở
rộng X. Máy mục tiêu sử dụng Fedora 10 trên máy tính ThinkPad. Một vấn đề
quan trọng với việc sử dụng thiết lập này là, mặc định, Fedora vô hiệu hóa bản
ghi mở rộng trong X11. Cần thiết biên dịch lại X Server để thiết lập chức năng.
Chỉ khi chúng ta kết thúc, Xnee làm việc hoàn hảo.
Dưới đây là một ví dụ lưu vết log sử dụng công cụ. Đầu ra được sinh ra bởi
Xnee và một máy khách X đã được sửa đổi sử dụng xev tool. Với các dòng, chúng
ta không bắt đầu với thời gian, trường thứ 8 là thời gian. Bỏ qua các trường không
được tài liệu hóa như dưới đây
Starts with Meaning
0,2 Key down, 6th value is keycode given by xmodmap -pk
0,3 Key up, 6th value is keycode given by xmodmap -pk

0,4 Mouse down, 5th value is mouse button
0,5 Mouse up, 5th value is mouse button
0,6 Mouse motion: next two values are (x; y) position
[timestamp] Active window (given by hex value) or titlebar has changed
8

Trong các dòng với dấu “,”, số lượng đưa ra cột cuối cùng trong mili giây,
và hiển thị xung của server X. Số này thì là điển hình số mili giây kể từ khi nhân
được khởi chạy. Kết quả từ Xnee. Trong các dòng mà bắt đầu với dấu ngoặc, thời
gian đầu tiên và sau nó là id của cửa sổ hiện hành và tiêu đề. Kết quả này từ tool
đã thay đổi của chúng ta.
Log dưới chỉ ra người sử dụng đang di chuyển từ cửa sổ terminal tới trình
duyệt Firefox. Người sử dụng nhập vào www.cmu.edu trong thanh địa chỉ, nhấn enter
và nhấn vào đường link. Cuối cùng người sử dụng đóng tab. Một vài thông số
chuột.
0,6,664,537,0,0,0,1041338
0,6,665,537,0,0,0,1041350
0,6,666,537,0,0,0,1041386
[1041667] 0x2c00007 agoode@localhost:˜/xnee-3.02
0,6,662,533,0,0,0,1041772
0,6,661,532,0,0,0,1041785
0,6,657,528,0,0,0,1041802
0,6,649,520,0,0,0,1041816
0,6,648,519,0,0,0,1041831
Mẫu chuột
0,6,667,347,0,0,0,1043375
0,6,679,347,0,0,0,1043392
0,6,701,349,0,0,0,1043407
Chuột thì di chuyển đến cửa sổ window,
[1043408] 0x4600121 Mozilla Firefox

9

0,6,711,351,0,0,0,1043423
0,6,729,355,0,0,0,1043440
0,6,737,357,0,0,0,1043449
0,6,743,359,0,0,0,1043462
0,6,744,359,0,0,0,1043527
Người sử dụng click để đưa firefox lên phía trước, mouse down, mouse up
0,4,0,0,1,0,0,1043552
0,5,0,0,1,0,0,1043625
0,6,743,359,0,0,0,1043764
0,6,743,358,0,0,0,1043789
0,6,741,357,0,0,0,1043802
0,6,735,349,0,0,0,1043813
0,6,719,327,0,0,0,1043833
0,6,709,307,0,0,0,1043847
thông số chuột
0,6,615,157,0,0,0,1044800
0,6,615,155,0,0,0,1044830
0,6,614,155,0,0,0,1044845
0,6,614,154,0,0,0,1044858
Người sử dụng click thanh địa chỉ
0,4,0,0,1,0,0,1045009
0,6,614,155,0,0,0,1045039
0,5,0,0,1,0,0,1045097
10

0,6,614,154,0,0,0,1045147
0,6,614,153,0,0,0,1045275
Vàgõ vào www.cmu.edu và nhấn enter.

0,2,0,0,0,25,0,1045693
0,3,0,0,0,25,0,1045757
0,2,0,0,0,25,0,1045851
0,3,0,0,0,25,0,1045907
0,2,0,0,0,25,0,1046010
0,3,0,0,0,25,0,1046089
0,2,0,0,0,60,0,1046146
0,3,0,0,0,60,0,1046295
0,2,0,0,0,54,0,1046296
0,2,0,0,0,58,0,1046391
0,3,0,0,0,54,0,1046429
0,3,0,0,0,58,0,1046488
0,2,0,0,0,30,0,1046540
0,3,0,0,0,30,0,1046619
0,2,0,0,0,60,0,1046755
0,3,0,0,0,60,0,1046843
0,2,0,0,0,26,0,1046879
0,2,0,0,0,40,0,1046935
0,3,0,0,0,26,0,1047014
0,2,0,0,0,30,0,1047038
11

0,3,0,0,0,40,0,1047076
0,3,0,0,0,30,0,1047148
0,2,0,0,0,36,0,1047229
0,3,0,0,0,36,0,1047317
[1047911] 0x4600121 Carnegie Mellon University - Mozilla Firefox
0,6,614,154,0,0,0,1048341
0,6,613,154,0,0,0,1048450
0,6,613,155,0,0,0,1048529

0,6,612,155,0,0,0,1049238
0,6,611,155,0,0,0,1049263
0,6,610,155,0,0,0,1049265
0,6,608,156,0,0,0,1049282
0,6,600,156,0,0,0,1049292
0,6,597,156,0,0,0,1049309
0,6,594,156,0,0,0,1049323
Thông số chuột
0,6,473,684,0,0,0,1056114
0,6,474,683,0,0,0,1056154
0,6,475,683,0,0,0,1056177
0,6,475,682,0,0,0,1056188
0,6,476,681,0,0,0,1056203
0,6,476,680,0,0,0,1056218
0,6,477,680,0,0,0,1056231
12

0,6,476,680,0,0,0,1056890
0,6,475,680,0,0,0,1057088
0,6,474,680,0,0,0,1057226
Click vào một link
0,4,0,0,1,0,0,1057903
0,5,0,0,1,0,0,1057984
0,6,474,681,0,0,0,1057995
[1058634] 0x4600121 Alice 3 Software - Carnegie Mellon University -
Mozilla
0,6,474,680,0,0,0,1060027
0,6,475,679,0,0,0,1060057
0,6,477,671,0,0,0,1060089
0,6,478,669,0,0,0,1060103

0,6,480,657,0,0,0,1060116
0,6,484,647,0,0,0,1060130
0,6,488,623,0,0,0,1060143
0,6,490,607,0,0,0,1060158
0,6,490,593,0,0,0,1060175
0,6,494,563,0,0,0,1060186
Thông số chuột
0,6,362,249,0,0,0,1061363
0,6,362,250,0,0,0,1061375
0,6,363,251,0,0,0,1061575
13

0,6,363,252,0,0,0,1061596
0,6,364,253,0,0,0,1061615
0,6,364,254,0,0,0,1061703
0,6,364,255,0,0,0,1061871
Click vào đóng cửa sổ
0,4,0,0,1,0,0,1061962
0,6,365,255,0,0,0,1061972
0,5,0,0,1,0,0,1062037
[1062195] 0x4600121 Mozilla Firefox
0,6,365,256,0,0,0,1062659
0,6,367,256,0,0,0,1062671
0,6,369,257,0,0,0,1062684
Đó là các log ra mà chúng ta có thể đọc và phân tích nó.
3.2. Trễ tầng ứng dụng và lưu log.
Để tạo độ trễ trong ứng dụng web, chúng ta thực hiện đơn giản dùng
javascript Greasemonkey framework. ĐOạn mã được trèn vào trong trang web
khi load trong trình duyệt và chạy bất kể khi nào phím được bấm hoặc chuột được
click. Lý thuyết, với cơ chế này, tất cả các xự kiện có thể được làm trễ trong các

người sử dụng tới ứng dụng web. Nhưng không may, javascript không cung cấp
cách nào để đồng bộ thực thi. Cách làm khác có, nhưng thường thất bại. Mặc dù
cơ chế này làm thỉnh thoảng làm việc, nó thường làm đơ trình duyệt, làm mất sự
tương tác với người sử dụng. Một cơ chế khác có thể tìm được nếu tầng ứng dụng
trễ là được yêu cầu.
14

Đoạn script Greasemonkey cũng có thể log lại các sự kiện bị delay khi kết
nối tới log server chạy trên máy local. Bởi vì Greasemonkey không thể truy cập
file hệ thống, log phải thực hiện thông qua GM_xmlhttpRequest. Một log server
đơn giản viết trên Python để nắng nghe sự kiện logs.
3.3. Delay mạng.
Giới thiệu về trễ mạng, chúng ta sử dụng NetEm, chạy trên máy local. Với
thiết lập này, chúng ta có thể nhanh chóng thay đổi tham số độ trễ thường xuyên
khi cần thiết, và có thể chọn lọc các gói trễ và các thứ khác.
3.4. log network
Để log gói, chúng ta sử dụng wireshark, mô tả trong 2.1.4
4. Hợp chuẩn
Chúng tôi đã không làm bất kỳ loại phân tích về độ trễ. Để đo độ trễ, chúng
tôi thực hiện kiểm chứng thực với sự giúp đỡ của một micro đặc biệt, một máy
quay phim, và phần mềm được gọi là ELAN [12].
4.1. Thiết lập thử nghiệm
Để xác minh chất lượng của từng logger, chúng tôi quyết định để đo các âm
thanh của tổ hợp phím với một micro nhạy cảm và sau đó tương quan với các
dạng sóng đầu ra của logger. Máy tính xách tay là một máy ThinkPadT61. Micro
là một loại cốc hút, đặc biệt là một Peterson Signalflex SF20 Guitar Tuner đón
micro (xem Hình 1). Micro được đặt trên trackpad của máy tính xách tay, cung
cấp tín hiệu tốt từ các âm thanh bấm phím và click chuột (xem hình 2). Một máy
quay video được đặt trên một chân máy và nhằm vào máy tính xách tay.
Microphone kết nối với máy quay video thông qua một dây.

15

4.2. Phân tích
Phần mềm được sử dụng để xác nhận là ELAN [12]. Mục đích sử dụng của
nó là để chú thích video xử lý ngôn ngữ. Trong trường hợp của chúng ta, chúng
ta sử dụng nó để đánh dấu các đỉnh núi của các phím bấm / phát hoặc chuột







Hình 1:The Peterson Signalflex FL20 Guitar Tuner Pickup.

Hình 2: Cận cảnh của ThinkPadT61 với trackpad đính kèm microphone
16

bấm / phát và sau đó lưu ý những gì đã được ép, có phải đó là báo chí hay phát
hành, và những nhiệm vụ đã được, hiện đang được thực hiện bởi người sử dụng.
(Xem hình 3).
ELAN làm cho nó di chuyển rất dễ dàng một cách cẩn thận thông qua các
video và âm thanh để đảm bảo rằng các chú thích đã được đặt đúng chỗ. Mặc dù
video và âm thanh đều bị bắt, đoạn video không có độ phân giải đủ thời gian như
âm thanh (NTSC video chạy ở 60Hz, một khung hình mỗi 16.67ms), và chỉ được
sử dụng như một hướng dẫn. Tất cả các phân tích được thực hiện độc quyền với
âm thanh. Một khi chú thích xong, các chú thích được xuất từ ELAN trong định
dạng CSV.
Sau khi dữ liệu được xuất, một "điểm số không" trường hợp được xác định

phù hợp với một điểm dữ liệu trong cả dữ liệu đăng nhập và các chú thích ELAN.
Sự khác biệt được tính toán từ tất cả các điểm tiếp theo. Nó được tính bằng cách
trừ đi thời gian ELAN từ thời điểm logger. Sự khác biệt tuyệt đối cũng được tính
toán. Từ đó, sự khác biệt có ý nghĩa và có ý nghĩa của sự khác biệt tuyệt đối được
tính toán. Một ví dụ về dữ liệu này cho Xnee được thể hiện trong bảng 1. RUI 1.0
được thể hiện trong bảng 2 và RUI 2.03 được thể hiện trong bảng 3. Các điểm
không (thể hiện trong dòng 3 cho Xnee, dòng 9 cho RUI 1.0, và dòng 1 cho RUI
2.03) phải bỏ ra ngoài không được sử dụng trong mức trung bình hay bất kỳ tính
toán khác để xác nhận.





17

Hình 3: Âm thanh và video trong giao diện ELAN
Eventtype
Xneetime(ms)
ELANtime(ms)
Diff.(ms)
Abs.Diff.(ms)
Mouse down
−2865
−2863
−2
2
Mouse up
−2724
−2730

6
6
Key down
0
0
0
0
Key down
234
229
5
5
Mouse down
2567
2688
−121
121
Mouse up
2687
2708
−21
21
Mouse down
3996
3987
9
9
Mouse up
4155
4149

6
6
Mouse down
7085
7073
12
12
Mouse up
7225
7179
46
46
Mouse down
8235
8225
10
10
Mouse up
8365
8365
0
0
Bảng 1: Số liệu để xác minh của Xnee. Vì đánh dấu điểm trong ELAN là một
quá trình thủ tẻ nhạt, chỉ có 12 điểm được xác định (bao gồm cả điểm số không).
18

4.3. Kết Quả
Phân tích được thực hiện trên ba logger: RUI 2.03, RUI 1.0, và Xnee. 2 Các
kết quả được tóm tắt trong bảng 4. Đối với mỗi trường hợp quan sát, một sự khác
biệt thời gian được tính. Đối với mỗi logger, giá trị trung bình của sự khác biệt và

có ý nghĩa của sự khác biệt tuyệt đối được thể hiện trong các kết quả.
Eventtype
RUI1.0time(ms)
ELANtime(ms)
Diff.(ms)
Abs.Diff.(ms)
Keydown
12499
12490
9
9
Keydown
12733
12730
3
3
Mousedown
22186
22320
−134
134
Mousedown
33983
34130
−147
147
Mousedown
47983
48170
−187

187
Mousedown
71108
71260
−152
152
Mousedown
73842
74000
−158
158
Mousedown
82936
83100
−164
164
Keydown
84030
84030
0
0
Keydown
84358
84350
8
8
Keydown
85217
85210
7

7
Mousedown
86936
87080
−144
144
Keydown
87670
87710
−40
40
Keydown
87967
87950
17
17
Mousedown
100327
100500
−173
173
Mousedown
102749
102920
−171
171
Mousedown
109545
109700
−155

155
Mousedown
117499
117670
−171
171
Mousedown
122186
118020
4166
4166
19

Mousedown
127592
127740
−148
148
Keydown
131108
131270
−162
162
Keydown
131264
131350
−86
86
Bảng 2: Số liệu để xác minh của RUI 1.0.
Eventtype

RUI2.03time(ms)
ELANtime(ms)
Diff.(ms)
Abs.Diff.(ms)
Mousedown
22226
22226
0
0
Keydown
25461
25508
−47
47
Mousedown
27206
26666
540
540
Mousedown
28023
28034
−11
11
Mousedown
30742
30756
−14
14
Mousedown

31539
31428
111
111
Mousedown
32882
32778
104
104
Keydown
34711
34770
-59
59
Mousedown
36366
35694
672
672
Mousedown
36757
36630
127
127
Mousedown
37226
37242
−16
16
Mousedown

38736
38598
138
138
Mousedown
40054
39972
82
82
Bảng 3: Số liệu để xác minh của RUI 2.03
20

Logger
MeanDifference(ms)
MeanofAbsoluteDifferences(ms)
#Events
RUI2.03
136.00
160.00
12
RUI1.0PC
92.00
291.00
21
VIA
N/A
N/A
N/A
Xnee
−4.55

21.64
11
Bảng 4: Kết quả phân tích của bốn người khai thác gỗ. VIA không có kết
quả bởi vì phương pháp của nó thu thập dữ liệu không tối ưu phù hợp với nhiệm
vụ của chúng ta
Chúng ta có thể thấy rằng các giải pháp Xnee là một thứ tự cường độ chính
xác hơn trong việc đo lường sự kiện người sử dụng hơn các công cụ khác, và được
gần gũi hơn với khả năng chịu đựng của các thử nghiệm ban đầu: "Độ chính xác
của thời gian đóng dấu được trong vòng 33 mili giây của thời gian thực tế của sự
kiện tại các thiết bị đầu cuối. "[2, tr. 154] Trong khi hệ thống của chúng ta là trên
đường để trở thành một công cụ hữu ích, nó vẫn cần một số công việc để đạt được
mức độ chính xác nhìn thấy trong năm 1983. Đảm bảo việc sử dụng các giờ tốc
độ cao và áp dụng một số điều chỉnh hạt nhân để giảm rung pha có thể giúp loại
bỏ các vấn đề chính xác còn lại. Những vấn đề này là một phần của hệ điều hành
liên tục nghiên cứu [11].
5. Acknowledgements
Nghiên cứu này được tài trợ bởi Quỹ Khoa học Quốc gia (NSF) theo cấp số
CNS-0.833.882. Bất kỳ ý kiến, phát hiện, kết luận, đề xuất trong tài liệu này là
của các tác giả và không nhất thiết phản ánh quan điểm của NSF hoặc Đại học
Carnegie Mellon.