--- Comment #3 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-10-25 23:29:30
I collected PEV events and time data for different kinds of sync modes and many
usage scenarios and got below conclusions:
1) The highest time cost is network transport. In all of these scenarios, they
take about 70~90% of total time based on my network conditions. It may varies
under different environments. But it should be the highest one, not sync modes.
2) Based on the 1st truth, all of them could be partitioned into 3 big steps:
session init, data preparation, send and receive, session end. In a widely
common usage scenario(such as two-way sync without errors, others sync mode are
the same), each step contains one send/receive of syncML message. Another
reason to adopt this partition is that each step has a decided started/ended
PEV command so we can easy to track.
3) Here are detailed descriptions for 3 steps:
Session init step: clients prepares auth info and device info, set up
connection and send them to server and server returns auth result and its
Data preparation, send and receive: client prepares its backend data(if has)
and sends them to server. Server receives them and sends status and its own
data items to client(if has and needed).
Session end: client parses server's data items and stores them in backend
and send a message to end the session.
4) The temporal distribution is not equal for 3 steps statically. And also step
1 and step2 don't know what percent they will take. Reasons could be summarized
as: each step may not have only one send/receive messages
5) Major possible reasons to affect progress: sync errors and the number of
6) Possible time factors in each step:
Session init step: transport connection setup, authencation(zyb could make us
send 3 times authencation info)
Data preparation, send and receive: the number of data items, which could
increase the number of message sending and receiving; reading data from backend
Session end: data writing to backend
7) Based on the above description, my proposal is that progress calculation
should be based on 3 big steps and networks transports since there are the most
important. Though in step1 and step2, we can't know what extractly progress we
are, but I'd like to change percentages dynamically according to current step
information. For example, in the step2, if we find many data items to be sent
in many messages, we'd increase percentage of step2 and reduce percentages of
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.