---- Reported by jingke.zhang@intel.com 2010-04-13 02:27:44 +0000 ----

This is from http://bugzilla.moblin.org/show_bug.cgi?id=7134

   Description  From  yongsheng zhu   2009-10-20 23:12:27 PST   (-) [reply]

'Progress' calculation is much more complex. Open this bug entry to track
discussions on how to calculate 'progress' smartly and precisely.

A reference bug entry is https://bugs.meego.com/show_bug.cgi?id=2229.

------- Comment #1 From yongsheng zhu 2009-10-20 23:14:18 PST (-) [reply] -------

Here is a comment from Patrick's mail, posted here:
Perhaps we can turn the float constants above into an array of variables,
indexed by ProgressState, which get set (and updated) depending on what kind of
sync is detected?

------- Comment #2 From pohly 2009-10-22 05:07:56 PST (-) [reply] -------

*** https://bugs.meego.com/show_bug.cgi?id=2413 has been marked as a duplicate of this bug. ***

------- Comment #3 From yongsheng zhu 2009-10-25 23:29:30 PST (-) [reply] -------

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
device info.
   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
network transport. 
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
step3 dynamically.

------- Comment #4 From yongsheng zhu 2009-10-25 23:40:01 PST (-) [reply] -------

Created an attachment [details]
time and progress event data

The data for time and progress event is uploaded, which is used to track time
distribution for different usage scenarios. If interested, you could have a
look

------- Comment #5 From yongsheng zhu 2009-10-26 20:42:34 PST (-) [reply] -------

Each syncML message sending/receiving could use much time. This could make some
*big* jumps of percentages,. For example, before sending, progress percentage
is 5%, however, after many seconds, progress percentage jumps to 40% and there
is no update since there is no event between sending and receiving. so we may
have to update percentage in the sending/receiving.

------- Comment #6 From yongsheng zhu 2009-10-29 02:12:07 PST (-) [reply] -------

(In reply to comment #5)
> Each syncML message sending/receiving could use much time. This could make some
> *big* jumps of percentages,. For example, before sending, progress percentage
> is 5%, however, after many seconds, progress percentage jumps to 40% and there
> is no update since there is no event between sending and receiving. so we may
> have to update percentage in the sending/receiving.
I'd like to add one timer to update progress info to dbus-client in the
processing of sending/receiving and send signals at regular intervals. This
prevents client's progress bar changed dramatically. This could be done through
time estimation of send/receive for the first time.

------- Comment #7 From pohly 2009-10-29 03:28:25 PST (-) [reply] -------

(In reply to comment #6)
> (In reply to comment #5)
> > Each syncML message sending/receiving could use much time. This could make some
> > *big* jumps of percentages,. For example, before sending, progress percentage
> > is 5%, however, after many seconds, progress percentage jumps to 40% and there
> > is no update since there is no event between sending and receiving. so we may
> > have to update percentage in the sending/receiving.
> I'd like to add one timer to update progress info to dbus-client in the
> processing of sending/receiving and send signals at regular intervals. This
> prevents client's progress bar changed dramatically. This could be done through
> time estimation of send/receive for the first time.

I'd prefer to get the sync-UI working with the new progress implementation
before tuning it further. Then it will be easier to literally *see* how it
behaves in practice.

The current implementation can be merged into master as it is without the
message send/receive part, once you declare it ready for merging.

If you don't know what to work on next, there are several more urgent issues
(https://bugs.meego.com/show_bug.cgi?id=6376, #6548, #7555). Also, having comprehensive test coverage of the new
D-Bus API is critical now. We should be sure that it works before Jussi spends
too much time debugging it when he could work on the sync-UI instead.

------- Comment #8 From pohly 2009-11-10 08:20:32 PST (-) [reply] -------

(In reply to comment #7)
> The current implementation can be merged into master as it is without the
> message send/receive part, once you declare it ready for merging.

Merged.

We can tweak the implementation later on.

------- Comment #9 From jku 2009-11-16 13:10:05 PST (-) [reply] -------

(In reply to comment #7)
> I'd prefer to get the sync-UI working with the new progress implementation
> before tuning it further. Then it will be easier to literally *see* how it
> behaves in practice.


This is now possible in jku-dbus-update branch.



---- Additional Comments From jingke.zhang@intel.com 2010-04-13 02:29:23 +0000 ----

Created attachment 190 [details] [review]
time and progress event data

Add the attachment of BMO#7134



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 698 at https://bugs.meego.com/show_bug.cgi?id=698
Imported an attachment (id=64879)