Sharing problems with Salut

[gdesmott]

On #6483 was discussed some sharing issues with Read and Salut.

I did lot of tests and sharing almost never works with Salut on XO's (but works pretty well with sugar-jhbuild with my stream tubes fix (see #6483)). Though disable Read's suspend policy (by creating this file /etc/inhibit-ebook-sleep) really improve results. So I think something goes wrong in Read's suspend code.

Would be cool if a Read developper could explain us how it's supposed to manage suspend.

[gdesmott]

See #6538 for another suspend problem with Read.

[bemasc]

After looking at the code, the problem is that Read suspends so aggressively that it will not even receive the "Join" notification when someone else joins the activity and requests the file. The sleep code may even interrupt the transfer. This is a major bug in Read. Fundamentally, Read must never suspend once it is shared, because it must receive multicast notifications in order for sharing to work.

[gdesmott]

Well, the real problem is in the wifi firmware which doesn't wake up when receiving multicast packets.

[gnu]

You can make the wifi firmware wake up on multicast packets (that this laptop is interested in) by doing this command: "ethtool -s eth0 wol um". The "u" in the last argument is unicast, "m" is multicast, (you can also add "b" to wake on broadcasts, though I don't recommend it). I suggest testing with this change and seeing if it is really the only problem, or whether we have other problems in Read or sharing that should also be addressed.

[cjb]

We wouldn't stay asleep for very long if we turned on wake on multicast, though, which would probably remove the point of these suspends. I agree it's still an interesting test.

[gdesmott]

I did some tests and multicast wake *does* improve things. Sharing was working fine without /etc/inhibit-ebook-sleep.

[gregorio]

Milestone Never Assigned deleted