Ticket #6467 (new defect)

Opened 7 years ago

Last modified 6 years ago

Suspend/resume makes icons flash in the mesh view

Reported by: yani Owned by: Collabora
Priority: high Milestone: 9.1.0-cancelled
Component: presence-service Version:
Keywords: 8.2.0:- 9.1.0:? Cc: kim, tomeu, marco, carrano, mbletsas, cjb, cscott, mstone, ypod
Action Needed: design Verified: no
Deployments affected: Blocked By:
Blocking:

Description

After the XO resumes(probably after beinng suspended for several minutes) all the icons in the mesh view vanish, except the mesh circles.

Slowly the AP start to reappear, and some time later the other XOs as well.

Some times(perhaps it is related to the time of suspension), only a few icons vanish at resume.

Once, an XO in the view was instantly replaced by another(it switched color)

This situation occurs almost every time after resume!

I dont whether it is a UI issue as well, but the avahi cache has cleared at resume(no XOs show in the avahi list) Of course the other XOs in the list have suspended as well, but normally avahi takes 30min to discover that. So the suspend/resume affects the process.

This bug might be the correct interpretation of #6157, which discribes a 4470 similar situation.

Change History

  Changed 7 years ago by yani

build 692 ofw Q2D13 MP machine

  Changed 7 years ago by carrano

  • cc carrano added

During a suspend, the avahi data stops being updated. After some time the cache entries expire. So when the XO finally resumes, it may be empty.

Does it account for the effects you are observing?

  Changed 7 years ago by carrano

1. A disconnected mesh relies on salut for collaboration AND Salut relies on multicast.

2. A suspended XO will ignore multicast frames AND an XO suspends every few minutes.

1 + 2 = no usable disconnected mesh!

  Changed 7 years ago by carrano

  • cc mbletsas added

follow-up: ↓ 6   Changed 7 years ago by yani

  • cc cjb added

Ricardo,

The strange thing is that when the XO resumes, his OWN cache list is cleared.

As i mentioned in the email, i believe that a possible explanation for this is that perhaps the XO resumed without my intervention, and cleared its cache before suspending again. So when i resumed it, i noticed that the XO had an empty list.

There must be a way to check the exact time ranges that the XO is suspended.

I will ask chris.

Also, as u commented, the current situation makes the mesh unusable, if suspend is frequent and long.

in reply to: ↑ 5   Changed 7 years ago by carrano

Replying to yani:

Ricardo, The strange thing is that when the XO resumes, his OWN cache list is cleared.

It makes sense. Since he couldn't keep this data updated and it expired.

follow-up: ↓ 8   Changed 7 years ago by yani

But, he is suspended. He doesnt have the chance to keep/not keep the data updated.

Naturally, at resume the situation should be exactly the same as before.

in reply to: ↑ 7   Changed 7 years ago by carrano

Replying to yani:

But, he is suspended. He doesnt have the chance to keep/not keep the data updated. Naturally, at resume the situation should be exactly the same as before.

Yanni, The clock keeps ticking. Avahi has entries on its cache. They will expire after some time (Tx). The XO suspends and stays in that mode for a time > Tx. Your entries will be cleaned. When the XO resumes, that is nothing there!

  Changed 6 years ago by marco

  • keywords 8.2.0:? added
  • milestone changed from Never Assigned to 8.2.0 (was Update.2)

  Changed 6 years ago by mstone

  • cc cscott, mstone, ypod added
  • next_action set to never set

This seems to me to be a design conflict between spending most of our time suspended and trying to maintain presence information about our neighbors. Punting to 9.1.0, where we can begin to properly study it.

  Changed 6 years ago by mstone

  • keywords 8.2.0:- 9.1.0:? added; 8.2.0:? removed
  • next_action changed from never set to design
  • milestone changed from 8.2.0 (was Update.2) to 9.1.0
Note: See TracTickets for help on using tickets.