Transferring video files between laptops saturates bandwidth and kills running session

[joe]

9-laptops testbed (build 708), mesh collaboration "under the tree".

An attempt to record a video and transfer it to collaborating machines kills the system, requiring a reboot to resume operations. The part of the video file is indeed tranferred (a blurred image appears on several XOs before those machines become dead).

Seems as the video activities in the collaboration environment (not in the individual machine) are impossible.

[carrano]

Replying to joe:

9-laptops testbed (build 708), mesh collaboration "under the tree". An attempt to record a video and transfer it to collaborating machines kills the system, requiring a reboot to resume operations. The part of the video file is indeed tranferred (a blurred image appears on several XOs before those machines become dead). Seems as the video activities in the collaboration environment (not in the individual machine) are impossible.

Apparently this activity is supposed to run on joyride (since it needs a newer version of telepathy-glib). Can you give the steps that you use to install it on 708?

Would you also please clarify what makes you feel that this is a network problem and not an application crash?

[joe]

This activity was included in the build provided to QA by Michael Stone, so I didn't need to install it myself.

A network problem - because the stand-alone application does work; it's only when the collaboration between several laptops is established to share the video, and the file tranfer starts, then laptops "die" - require rebooting.

[Charlie]

If the laptops themselves require rebooting and not just the Record activity then the issue may not just be a network problem. It could be an application crash exacerbated or caused by a network problem, but it sounds more like an application crash to me.

Saturated bandwidth is not something that I would consider the network to be 'at-fault' for -- IMNSHO, that is normally the user's problem, but in our particular case it's just a side-effect of being in the middle of Cambridge and having 9 XOs all trying to transfer files with each other at the same time.

I don't know exactly how the transfer process works in this case, but at a guess the XO that the video is coming from is trying to send it to all of the XOs requesting it simultaneously, instead of in a queue, or some sort of 'distributed' manner where laptops that have the file seed what they have to other laptops who are connected (like BitTorrent).

[erikg]

Is the laptop completely locking up? What continues working? Does the mouse move? Can you reach the virtual terminal? Can you kill/restart Sugar/X via control+alt+erase? Can you ssh into a laptop when it's in that state?

If you can ssh into the system or reach the virtual terminal, what kind of information can you gain from the results of 'top' (which shows you process statistics such as memory usage and cpu usage). Can you use a command like 'watch ifconfig' to take a rough estimate of the network bandwidth usage?

This is a typical set of questions which I try to answer when I find a lockup-type bug. They will help ascertain where the problem lies so that anyone working on this bug can have a head-start in resolving it.

[joe]

Due to special attention, I will run this test again, making sure that developers (Erik, etc.) will get access to failing laptops for postmortem investigation.

[gnu]

Was this test running the standard "Record" activity to record a short video clip? Or was it using some different "Video Chat" activity? I think there's some confusion about this.

[joe]

It was the "Record" activity.

[kimquirk]

Release note that video sharing is not supported. Photo sharing is.

Not a blocker for 8.2. Will reconsider video sharing in future release.