Discussion:
Mesh power save mode peering
Jordi Riera Ayala
2014-04-22 04:32:56 UTC
Permalink
Hello,

I have established a simple mesh network with two Raspberry Pi using
Raspbian 3.10.25+ and each one uses a Wi-Pi adapter RT2870 with the
rt2800usb driver.

I am testing the speed and losses of the network using jperf, a Java GUI
for iperf. It was running well without power mode, but when one or both
nodes are set in light or deep sleep mode they ping succesfully at the
beginning but the connection gets broken somehow soon when they have to
exchange TCP or UDP frames (sometimes it works for a few seconds). After
that, ping just looses all packets or says Host Unreachable.

However if I just let the ping go eventually (maybe around 3 min) the
connection gets broken too, doing station dump still sees the nodes as
ESTAB and I realized that if I switch one of the two nodes (sometimes is
one and sometimes the other) back to active mode then immediatly the ping
is succesful and then I can go back to sleep mode but soon or later it will
happen the same.

I tried changing parameters like awake window and dtim period but I am not
sure if they affect this issue at all. Does anyone has succesfully used
power save mode with another device or can help me with that?

Thanks in advance
Jordi

PS: Reading the Mesh Power Implementation Notes.. how can I measure the
power or current consumption of the usb?
Michel Stam
2014-04-22 04:50:43 UTC
Permalink
Hello Jordi,

Not sure if it is of importance, but I have seen slow connections, lost packets etc on that particular radio card while using a regular station association to a Linksys accesspoint using wpa_supplicant.

What worked for me was-
iw dev sta0 set power_save off

Apparently, it saves power a bit too aggressively.

Maybe that helps?

Cheers,

Michel Stam
Post by Jordi Riera Ayala
Hello,
I have established a simple mesh network with two Raspberry Pi using Raspbian 3.10.25+ and each one uses a Wi-Pi adapter RT2870 with the rt2800usb driver.
I am testing the speed and losses of the network using jperf, a Java GUI for iperf. It was running well without power mode, but when one or both nodes are set in light or deep sleep mode they ping succesfully at the beginning but the connection gets broken somehow soon when they have to exchange TCP or UDP frames (sometimes it works for a few seconds). After that, ping just looses all packets or says Host Unreachable.
However if I just let the ping go eventually (maybe around 3 min) the connection gets broken too, doing station dump still sees the nodes as ESTAB and I realized that if I switch one of the two nodes (sometimes is one and sometimes the other) back to active mode then immediatly the ping is succesful and then I can go back to sleep mode but soon or later it will happen the same.
I tried changing parameters like awake window and dtim period but I am not sure if they affect this issue at all. Does anyone has succesfully used power save mode with another device or can help me with that?
Thanks in advance
Jordi
PS: Reading the Mesh Power Implementation Notes.. how can I measure the power or current consumption of the usb?
_______________________________________________
Devel mailing list
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
Marco Porsch
2014-04-22 08:03:25 UTC
Permalink
Hello Jordi,
Post by Jordi Riera Ayala
Hello,
I have established a simple mesh network with two Raspberry Pi using Raspbian 3.10.25+ and each one uses a Wi-Pi adapter RT2870 with the rt2800usb driver.
Please mind that the actual 'power saving' mode (the doze state) is not implemented in upstream Linux. You can find the corresponding commits at github [1], but the driver-side is only implemented for ath9k, not for rt2800!
What is implemented in upstream Linux is the power mode setting, announcements and tracking as well as packet buffering and release.
Post by Jordi Riera Ayala
I am testing the speed and losses of the network using jperf, a Java GUI for iperf. It was running well without power mode, but when one or both nodes are set in light or deep sleep mode they ping succesfully at the beginning but the connection gets broken somehow soon when they have to exchange TCP or UDP frames (sometimes it works for a few seconds). After that, ping just looses all packets or says Host Unreachable.
However if I just let the ping go eventually (maybe around 3 min) the connection gets broken too, doing station dump still sees the nodes as ESTAB and I realized that if I switch one of the two nodes (sometimes is one and sometimes the other) back to active mode then immediatly the ping is succesful and then I can go back to sleep mode but soon or later it will happen the same.
What I expect is happening here, is that the Mesh Peer Service Period got 'stuck': one node is forever waiting for the other to end the MPSP, because it missed the corresponding frame earlier.
Post by Jordi Riera Ayala
I tried changing parameters like awake window and dtim period but I am not sure if they affect this issue at all. Does anyone has succesfully used power save mode with another device or can help me with that?
Could you please check if your kernel contains this commit [2]? If not please manually apply it and report back.
Post by Jordi Riera Ayala
Thanks in advance
Jordi
PS: Reading the Mesh Power Implementation Notes.. how can I measure the power or current consumption of the usb?
The most simple approach is to measure the power using a lab multimeter in line on the USB's ground or VCC line. You may cut open an old USB extender cable for that.
But mind that you won't measure any power savings on the rt2800usb device, as it misses the corresponding driver implementation.

Best regards,
--Marco


[1]
https://github.com/cozybit/open80211s/commits/ft-powersave

[2]
https://github.com/cozybit/open80211s/commit/e339d0a1f41e76f2695c7d47c16e69382feac0f1
Jordi Riera Ayala
2014-05-27 10:19:58 UTC
Permalink
Thanks for your help and time Marco and Michel.

Sorry for the huge delay, I could not put too much time into this recently
and I had some problems crosscompiling a new kernel because I am kinda
newbie. I compiled the rpi-3.13y that contained that commit.

Once the connection is established it seems pretty stable, however
establishing the connection in power save between 2 nodes it can be a real
struggle (and with 3 even worse), they often crash or become stuck in the
OPN_SNT / LISTEN.. states and I have to reboot and configure them again. I
tried changing the default power mode when entering the mesh and also
changing the peer power mode being in active but the result is the same.

Does the other commit called mac80211: mesh power save doze
scheduling<https://github.com/cozybit/open80211s/commit/28140ecb1c91aeb33bd63edd3a4d55a491922ab7>
or another one solve some issues?
Also I did some TCP and UDP tests changing the Awake Window parameter in
iw, but it seems it is not doing anything and I think it should be
relevant. I would also like to vary the beacon interval and I see it can be
changed when joining a mesh but I don't know the default value.

Would it help if I use another device that uses the ath9k_htc driver?

All the best

Jordi
Michel Stam
2014-05-27 08:51:54 UTC
Permalink
Hello Jordi,

I've tested here with ath9k cards, that works. Although I must say I
have not used power save mode.
Same goes for the rt2800usb driver, that works too (with the comments I
gave before). Not the best of speeds though, but that seems more likely
to be a bug with transmit timeouts.

ath9k_htc I tried once when I just started out with this, but I could
not get it to work very well. I can't remember anymore why this was, and
if I solved the bug after it. It was not the device I intended to use,
so I did not investigate any further. ath9k has my focus.

As far as the kernel goes I've seen meshing working with both 3.12.1 and
linux 3.10.32 and up. No special patches needed as far as getting it
operational is concerned.

Power saving seems to be of some importance to you, could you try
without to see if that works stable for you?

I have little experience with the power saving part so I am not sure if
I can be of much use here.

Cheers,

Michel
Post by Jordi Riera Ayala
Thanks for your help and time Marco and Michel.
Sorry for the huge delay, I could not put too much time into this
recently and I had some problems crosscompiling a new kernel because I
am kinda newbie. I compiled the rpi-3.13y that contained that commit.
Once the connection is established it seems pretty stable, however
establishing the connection in power save between 2 nodes it can be a
real struggle (and with 3 even worse), they often crash or become
stuck in the OPN_SNT / LISTEN.. states and I have to reboot and
configure them again. I tried changing the default power mode when
entering the mesh and also changing the peer power mode being in
active but the result is the same.
Does the other commit called mac80211: mesh power save doze scheduling
<https://github.com/cozybit/open80211s/commit/28140ecb1c91aeb33bd63edd3a4d55a491922ab7>or
another one solve some issues?
Also I did some TCP and UDP tests changing the Awake Window parameter
in iw, but it seems it is not doing anything and I think it should be
relevant. I would also like to vary the beacon interval and I see it
can be changed when joining a mesh but I don't know the default value.
Would it help if I use another device that uses the ath9k_htc driver?
All the best
Jordi
_______________________________________________
Devel mailing list
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
Jordi Riera Ayala
2014-05-27 13:14:33 UTC
Permalink
Hello Michel

Without power save mode it also works for me for previous kernels, I tested
it with 4 nodes without problems. I also experience some kind of
fluctuations where some periods it is fairly good and then there are a
period of long outages.

I am interested in power save mode because I am doing the final project for
my bachellors degree in telecommunications and it is about mesh networks
using UAVs, so since their source of energy will be limited the mesh should
consume as less as possible. I am not developing I just would like to test
how the mesh behaves in power save mode.
Since 802.11s is recent, to learn how it works the first part of the
project is about doing some tests using Raspberry Pi, which might be
interesting too due to its reduced size so this is why I want to test the
power save mode on them.

All the best

Jordi
Post by Michel Stam
Hello Jordi,
I've tested here with ath9k cards, that works. Although I must say I have
not used power save mode.
Same goes for the rt2800usb driver, that works too (with the comments I
gave before). Not the best of speeds though, but that seems more likely to
be a bug with transmit timeouts.
ath9k_htc I tried once when I just started out with this, but I could not
get it to work very well. I can't remember anymore why this was, and if I
solved the bug after it. It was not the device I intended to use, so I did
not investigate any further. ath9k has my focus.
As far as the kernel goes I've seen meshing working with both 3.12.1 and
linux 3.10.32 and up. No special patches needed as far as getting it
operational is concerned.
Power saving seems to be of some importance to you, could you try without
to see if that works stable for you?
I have little experience with the power saving part so I am not sure if I
can be of much use here.
Cheers,
Michel
Thanks for your help and time Marco and Michel.
Sorry for the huge delay, I could not put too much time into this recently
and I had some problems crosscompiling a new kernel because I am kinda
newbie. I compiled the rpi-3.13y that contained that commit.
Once the connection is established it seems pretty stable, however
establishing the connection in power save between 2 nodes it can be a real
struggle (and with 3 even worse), they often crash or become stuck in the
OPN_SNT / LISTEN.. states and I have to reboot and configure them again. I
tried changing the default power mode when entering the mesh and also
changing the peer power mode being in active but the result is the same.
Does the other commit called mac80211: mesh power save doze scheduling<https://github.com/cozybit/open80211s/commit/28140ecb1c91aeb33bd63edd3a4d55a491922ab7>
or another one solve some issues?
Also I did some TCP and UDP tests changing the Awake Window parameter in
iw, but it seems it is not doing anything and I think it should be
relevant. I would also like to vary the beacon interval and I see it can be
changed when joining a mesh but I don't know the default value.
Would it help if I use another device that uses the ath9k_htc driver?
All the best
Jordi
_______________________________________________
_______________________________________________
Devel mailing list
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
Marco Porsch
2014-05-27 19:21:48 UTC
Permalink
Hello Jordi,

sorry to hear about your issues with peering in power save mode. As a workaround you might just let them peer up in active mode and change the power mode afterwards.

In theory the peering in PS mode works as follows:
1) one peer receives a beacon of the other (might initially be tricky when both already have a periodic non-overlapping doze/wakeup schedule)
2) as it starts the peering process, it temporarily goes to active mode
3) it sends a peering (mgmt) frame into the awake window of the other node
4) the node receiving the peering frame also goes to active mode
5) <peering continues as usual>

That being said, I assume you are using a vanilla kernel without any additional mesh patches? - Then your nodes do not actually have a doze/wakeup schedule. So no chance of missing peering frames. Ruling this out, I could only guess what goes wrong after that.

The commit for doze/wakeup scheduling does not solve any existing issues. It just adds additional functionalities (saving power).

Changing the awake windows does only effect the doze/wakeup scheduling - if implemented.

Changing the beacon interval definitely does influence the performance of links in PS mode. You should be able to test that without doze/wakeup scheduling. If you look into the kernel sources [1] you should find the default value of 1000TU.

When I was kernel hacking more actively, I tested PS mode on ath9k_htc devices. But I experienced unreliable and irrational behaviour concerning connectivity and power consumption and gave up without access to the firmware. The firmware is open-sourced by now and maybe you feel interested enough to have a shot at mesh PS mode in the ath9k_htc driver and firmware.

I can privately send you some publications of mine on the effects of mesh power save mode if you are interested.


Cheers,
--Marco


[1]
http://lxr.free-electrons.com/source/net/wireless/mesh.c#L48
Post by Jordi Riera Ayala
Hello Michel
Without power save mode it also works for me for previous kernels, I tested it with 4 nodes without problems. I also experience some kind of fluctuations where some periods it is fairly good and then there are a period of long outages.
I am interested in power save mode because I am doing the final project for my bachellors degree in telecommunications and it is about mesh networks using UAVs, so since their source of energy will be limited the mesh should consume as less as possible. I am not developing I just would like to test how the mesh behaves in power save mode.
Since 802.11s is recent, to learn how it works the first part of the project is about doing some tests using Raspberry Pi, which might be interesting too due to its reduced size so this is why I want to test the power save mode on them.
All the best
Jordi
Hello Jordi,
I've tested here with ath9k cards, that works. Although I must say I have not used power save mode.
Same goes for the rt2800usb driver, that works too (with the comments I gave before). Not the best of speeds though, but that seems more likely to be a bug with transmit timeouts.
ath9k_htc I tried once when I just started out with this, but I could not get it to work very well. I can't remember anymore why this was, and if I solved the bug after it. It was not the device I intended to use, so I did not investigate any further. ath9k has my focus.
As far as the kernel goes I've seen meshing working with both 3.12.1 and linux 3.10.32 and up. No special patches needed as far as getting it operational is concerned.
Power saving seems to be of some importance to you, could you try without to see if that works stable for you?
I have little experience with the power saving part so I am not sure if I can be of much use here.
Cheers,
Michel
Post by Jordi Riera Ayala
Thanks for your help and time Marco and Michel.
Sorry for the huge delay, I could not put too much time into this recently and I had some problems crosscompiling a new kernel because I am kinda newbie. I compiled the rpi-3.13y that contained that commit.
Once the connection is established it seems pretty stable, however establishing the connection in power save between 2 nodes it can be a real struggle (and with 3 even worse), they often crash or become stuck in the OPN_SNT / LISTEN.. states and I have to reboot and configure them again. I tried changing the default power mode when entering the mesh and also changing the peer power mode being in active but the result is the same.
Does the other commit called mac80211: mesh power save doze scheduling <https://github.com/cozybit/open80211s/commit/28140ecb1c91aeb33bd63edd3a4d55a491922ab7> or another one solve some issues?
Also I did some TCP and UDP tests changing the Awake Window parameter in iw, but it seems it is not doing anything and I think it should be relevant. I would also like to vary the beacon interval and I see it can be changed when joining a mesh but I don't know the default value.
Would it help if I use another device that uses the ath9k_htc driver?
All the best
Jordi
Loading...