Just some bikeshedding here:
Quasi-synchronising the avahi peer still there? queries so that they all
happen together - say, within a 1-minute period every 10 minutes - was
proposed as a solution so that laptops could wake up in anticipation
(Benjamin Schwartz). The fact that this solution did
I dropped a note to Bernard Aboba at Microsoft (a friend of a friend),
coauthor of that RFC, who brought some clarity to the situation. His
note is appended. What precedes it is my interpretation, and my
question to him. Unfortunately, it appears to me to be an ugly situation.
RFC 4795 does
RFC 4795 does not cover mdns.
http://www.multicastdns.org/ covers stuff regarding mdns; it is far from
ideal for a mesh network as well. Several of us are reading the ID at
the moment.
- Jim
On Thu, 2008-02-21 at 04:01 -0800, John Gilmore wrote:
Can you
Jim Gettys [EMAIL PROTECTED] wrote on 02/21/2008 10:38:46 AM:
RFC 4795 does not cover mdns.
http://www.multicastdns.org/ covers stuff regarding mdns; it is far from
ideal for a mesh network as well. Several of us are reading the ID at
the moment.
- Jim
OK, children of the world, please calm down. There are a few too many
bugs and egos flaring up to come to a reasonable resolution. This is
an interdisciplinary problem that crosses too many architectural
boundaries for any of us to be comfortable seeing the whole picture.
I filed a bug report
John,
I believe what is discussion here is the choice between waking on multicast
(and then keep MDNS working) or don't wake on multicast (and then saving
more power). Or if there is a way out of this compromise.
Are you cutting to the chase or just changing the movie? (Forgive me for the
joke
I believe the most important issue here is that, the way it is now,
suspend/resume will make a disconnected mesh unusable.
On Feb 17, 2008 4:11 AM, Giannis Galanis [EMAIL PROTECTED] wrote:
There are a couple of important issues/bugs regarding Salut and
Suspend/Resume.
FIRST, there is a
It does feel like we should turn off suspend for some of our testing.
I've experienced similar problems.
Chris, do you recommend removing ohm? Or is there something else we should try?
Kim
On 2/19/08, Ricardo Carrano [EMAIL PROTECTED] wrote:
I believe the most important issue here is that,
Hi,
It does feel like we should turn off suspend for some of our
testing. I've experienced similar problems.
Chris, do you recommend removing ohm? Or is there something else we
should try?
I recommend fixing the bug. :) We know that we intend to have the CPU
turned off most
Hi Ricardo,
A mesh will always rely to some degree in multicast/broadcast
traffic. This is not a bug.
I was asking whether it would help to have the wireless module wake us
on multicast packets instead of only unicast. Are you saying that it
would?
Avahi entries will expire after
Chris,
A mesh will always rely to some degree in multicast/broadcast traffic. This
is not a bug.
Avahi entries will expire after some time. Suspend will prevent it to update
its cache.
On Feb 19, 2008 11:13 AM, Chris Ball [EMAIL PROTECTED] wrote:
Hi,
It does feel like we should turn off
The partitioning we made between the network processor and the
main processor was pretty clean. Unfortunately, it doesn't support
low power operation. I suggest rethinking the partition for Gen2.
wad
On Feb 19, 2008, at 10:04 AM, Chris Ball wrote:
Hi Ricardo,
A mesh will always rely to
We ALWAYS have multicast traffic. Blindly waking on each
received multicast packet will ensure that we only sleep for
milliseconds.
wad
On Feb 19, 2008, at 9:13 AM, Chris Ball wrote:
Hi,
It does feel like we should turn off suspend for some of our
testing. I've experienced similar
On Tue, Feb 19, 2008 at 09:13:29AM -0500, Chris Ball wrote:
It does feel like we should turn off suspend for some of our
testing. I've experienced similar problems.
Chris, do you recommend removing ohm? Or is there something else we
should try?
I recommend fixing the bug.
On Feb 19, 2008 10:13 AM, Ricardo Carrano [EMAIL PROTECTED]
wrote:
I was asking whether it would help to have the wireless module wake us
on multicast packets instead of only unicast. Are you saying that it
would?
It seems so, though it would, as John points out, make resumes far more
Yanni,
As I posted in the bug, I believe that you are observing the entries on the
avahi cache expiring.
So, your first scenario would happen when the suspend time is longer than
the time it takes for all entries to expire.
The second scenario would happen when the suspend time is not long
On Tue, 2008-02-19 at 12:29 -0500, Giannis Galanis wrote:
The avahi works is that every several minutes(a predetermined timeout)
each host will send multicast request for all peers in its list.
Then all peers receiving this request will send a multicast reply.
The packets are multicast
On Tue, 2008-02-19 at 10:02 -0500, John Watlington wrote:
We ALWAYS have multicast traffic. Blindly waking on each
received multicast packet will ensure that we only sleep for
milliseconds.
What is all this multicast traffic?
If I am sitting idle on the network, why is there constant
If the time between a resume and a suspend is shorter than the time
period between consecutive presence updates (which is several minutes),
then the presence service should not even know that a suspend happened
in between. Then why are icons disappearing?
p.
Sjoerd Simons wrote:
It's avahi
For the protocol to be healthy,
not only you have to wake every 10min to send your request,
but you have to be awake to receive the others' requests.
These are again 10min, but have different offsets. Thats why I believe the
only way would be to have 10off - 10on.
Still, due to bug 5501, if you
Gianni,
Giannis Galanis wrote:
In fact the although the requests are every 10min, the icon will hold
for 30min in total until it is deleted.
Bug 5501, however, will delete the entry if within the timeframe, a
new host arrives.
Are you saying that you can have stale icons on screen for as
The list expires in 10min-30min.
But we cant wait 30min before suspending, it is way too long.
On Feb 19, 2008 11:37 AM, Ricardo Carrano [EMAIL PROTECTED]
wrote:
Yanni,
As I posted in the bug, I believe that you are observing the entries on
the avahi cache expiring.
So, your first
On Feb 19, 2008 12:55 PM, Benjamin M. Schwartz [EMAIL PROTECTED]
wrote:
On Tue, 2008-02-19 at 12:29 -0500, Giannis Galanis wrote:
The avahi works is that every several minutes(a predetermined timeout)
each host will send multicast request for all peers in its list.
Then all peers receiving
Yanni,
Timeout is a value, not a range. The effects brought by the timeout may
manifest in a period (a range).
I believe everyone will agree that 30 minutes is a long time to wait (and
like Polychronis added) defeat the whole idea of a presence service.
But, what I want to stress is that we are
On Feb 19, 2008 2:48 PM, Ricardo Carrano [EMAIL PROTECTED] wrote:
Yanni,
Timeout is a value, not a range. The effects brought by the timeout may
manifest in a period (a range).
Did a use it otherwise? Because of the effects of xmas tree, the timeout for
a failed XO until it's icon is
Yanni,
Did a use it otherwise? Because of the effects of xmas tree, the timeout
for a failed XO until it's icon is removed is 10-30min.
I am talking about the time it takes for an avahi entry to expire. For what
you said, is 10 minutes.
Ricardo, do you have anwers to the questions I
On Feb 19, 2008 4:10 PM, Ricardo Carrano [EMAIL PROTECTED] wrote:
Yanni,
Did a use it otherwise? Because of the effects of xmas tree, the timeout
for a failed XO until it's icon is removed is 10-30min.
I am talking about the time it takes for an avahi entry to expire. For
what you
]
Subject
Re: Salut and Suspend/Resume issues
The partitioning we made between the network processor and the
main processor was pretty clean. Unfortunately, it doesn't support
low power operation. I suggest rethinking the partition for Gen2.
wad
On Feb 19, 2008, at 10:04 AM, Chris Ball
There are a couple of important issues/bugs regarding Salut and
Suspend/Resume.
FIRST, there is a sugar issue, (or at least it seems so).
When an XO resumes after long suspends, all icons(APs, XOs, but not the
meshes) instantly vanish*(#6467)*. Then they slowly reappear. Although with
the APs the
29 matches
Mail list logo
