Hi We add the calculation back. Before doing the calculation we do:
- expected_downtime intial value is max_downtime. Much, much better intial value than 0. - we move when we measure the time. We used to measure how much it took "before" we really sent the data. - we introduce sleep_time concept. While we are sleeping because we have sent all the allowed data for this second we shouldn't be accounting that time as "sending". - last patch just introduces the re-calculation of expected_downtime. It just changes the stats value. Well, patchs 2 & 3 change the bandwidth calculation for migration, but I think that we were undercalculating it enough than it was a bug. Without the 2 & 3 patches, the "expected_downtime" for an idle gust was calculated as 80ms (with 30 ms default target value), and we ended having a downtime of around 15ms. With this patches applied, we calculate an expected downtime of around 15ms or so, and then we spent aroqund 18ms on downtime. Notice that we only calculate how much it takes to sent the rest of the RAM, it just happens that there is some more data to sent that what we are calculating. Review, please. Later, Juan. The following changes since commit 73d4dc71f3a41131541c73b3ac2a8b160a51842b: gtk: suppress accelerators from the File menu when grab is active (2013-02-21 16:34:49 -0600) are available in the git repository at: git://repo.or.cz/qemu/quintela.git stats.next for you to fetch changes up to 90f8ae724a575861f093fbdbfd49a925bcfec327: migration: calculate expected_downtime (2013-02-22 10:12:52 +0100) ---------------------------------------------------------------- Juan Quintela (4): migration: change initial value of expected_downtime migration: calculate end time after we have sent the data migration: don't account sleep time for calculating bandwidth migration: calculate expected_downtime arch_init.c | 1 + include/migration/migration.h | 1 + migration.c | 15 +++++++++++++-- 3 files changed, 15 insertions(+), 2 deletions(-)