poor performance of the PC104 ATOM in network transmission

[reafrancesco]

Please fill in the following two sections and then remove any comment and/or remark become unnecessary:

Description of the failure

Together with @barbalberto I have noticed an high variability of the transmission rate of packets from a pc104 atom (talking head) and the rest of standard iCub network.
We focused on "yarpdev --device test_grabber --width 320 --height 240" as reference test.
Whereas the test_grabber prints out the following messages
Read [152] frames in 5[s], average period 33.11[ms], min 33.25[ms], max 33.44[ms]
any yarpview (running on any other machine in the iCub network), once connected to the /grabber (in both tcp and udp) reports framerate that spans from ~3fps to ~30fps.

Also with IPERF we noticed that the transmission rate drops down to 500Mbit/s when the IPERF client runs on the PC104.

@allPC104ATOMusers: can you check if you have the same poor performance with IPERF

We tried with a point to point connection and we change also the eth cable.
The pc104 atom is demanding less than 10% in this condition (measured with top).

More importantly if we boot the PC104 atom with an ubuntu 16.04 the transmission rate is normal and in both the direction (from and to PC104 atom) restores back to 900Mbit/s (desired throughput)/

This issue is related to robotology/yarp#1232

[randaz81]

More importantly if we boot the PC104 atom with an Ubuntu 16.04 the transmission rate is normal

Which other OS are you using when the problem occurs?

[barbalberto]

@randaz81 The images for PC104 are based on Debian (see http://wiki.icub.org/wiki/The_Linux_on_the_pc104). Ubuntu is used on laptop side

[reafrancesco]

I can add it is realtime version of Debian in fact what "uname" shows is that we now have kernel 3.2.0-4+icub.2-rt-amd64 on the PC104 atom.
The kernel 3.2.0 currently on the PC104 atom is very old and goes back to a version of January 2012.
I don`t know how many commits Debian has backported but for sure the driver rtl8196 has changed a lot!
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/net/ethernet/realtek/r8169.c)

Concerning this I would kindly like to ask @mbrunettini whether we can prepare a new pendrive with never kernels.

[EliseiFrederic]

Hi,
Is there an easy fix-solution for this issue ? Can we patch the driver on the USB key,
or should we wait for a new release and go trough the full update process ?
Thanks in advance,
Frédéric & the Grenoble team (with lost video and audio packets on the talking head)

[mbrunettini]

A new release of iCub Live image (based on latest debian stable) has been created and it fixes this issue.
It is currently in testing and will be released soon.
There is no easy-fix but using the new kernel packed with the new release, I am afraid.

[EliseiFrederic]

Hi,
No news for the new image ? We got criticisms in our last HCII paper submission that we should have 30 fps with our iCub... that we did not reach in our stats because of this bug !
Cheers, Frédéric for the Grenoble team

[mbrunettini]

It is ready and it will be released in a few days!

[mbrunettini]

Here you can find the new release.
Let us know about

[EliseiFrederic]

Thanks for this release ! Should I follow the instructions from here : http://wiki.icub.org/wiki/The_Linux_on_the_pc104#How_to_create_the_bootable_USB_drive_with_the_live_image i.e. Fat32, unzip, makeboot.sh ? Cheers, Frederic

…

-- Frederic ELISEI http://www.gipsa-lab.fr/~frederic.elisei/ (33-4) 76574539 mailto:/Frederic.Elisei@gipsa-lab.grenoble-inp.fr

[mbrunettini]

Correct, the instructions are the same as last release

[EliseiFrederic]

Hi,

On Tue, Dec 05, 2017 at 03:23:19AM -0800, Matteo Brunettini wrote: Correct, the instructions are the same as last release

Thanks, I now have my bootable 8Gb FAT32 usb key with the new release. But the instructions give no clue about how we can modify the /etc files on the live before we put the key in the robot (so that we don't loose internet connectivity). Is there a specific mount flag/procedure from another computer ? Normal mount does not show this files directly : eliseif@desktop-098:/media/KINGSTON$ ls autorun.inf dists g2ldr md5sum.txt setup.exe VERSION boot efi g2ldr.mbr persistence syslinux win32-loader.ini [BOOT] efi.img install pool tools ChangeLog firmware live README utils Should I *boot* rather than mount this key on another computer ? We did that with our previous update (that had the previous 2 structures, where persistence files were directly visible) and it ended in the live memorizing eth0 for this computer, and then a new eth1 for the robot interface, that did not use the configuration files :-( Thanks in advance for your help, Maybe this should be in the wiki or the README file on the key ? Cheers, Frederic

…

-- Frederic ELISEI http://www.gipsa-lab.fr/~frederic.elisei/ (33-4) 76574539 mailto:/Frederic.Elisei@gipsa-lab.grenoble-inp.fr

[mbrunettini]

Why do you need to modify the network configuration?
It is standard and all iCub PC104 are on 10.0.0.2

[gsaponaro]

Why do you need to modify the network configuration?
It is standard and all iCub PC104 are on 10.0.0.2

Well, in Lisbon we have to customize the network configuration[*] and other files on the PC104 USB pen drive. So, we would also benefit from having the instructions that @EliseiFrederic was mentioning.

[*] the reason why we must customize the network is that 10.0.0.2 is assigned to the DNS server of our institute, and we want to access that server + the external internet from PC104. Usually we have proceeded by customizing some files (e.g., /etc/network/interfaces, /etc/fstab, /etc/hosts). Related issue robotology/community#136

[mbrunettini]

The persistence file can be mounted as a partition to read files from. It is a standard live persistence file, the modified files are hosted in the rw folder.
Writing files directly to the persistence file (or partition) has never been tested here.
The live USB can be used in any other computer (it is a modified Debian live system, but it will take a while to boot up) where you can modify your network configuration file /etc/network/interfaces.

A note : usually the iCub is used with a laptop (or a server) that acts as gateway and segregate the iCub subnet from the rest of the world; this helps network bandwith performances.

[EliseiFrederic]

Hi, As a summary for the procedure : I started from http://wiki.icub.org/wiki/The_Linux_on_the_pc104#How_to_create_the_bootable_USB_drive_with_the_live_image [1] i.e. Fat32, unzip, makeboot.sh ... * the README at the root of the image does not have only good hints to seek and replace the 10.0.0.1 occurences. I found it more useful to rely on : http://wiki.icub.org/wiki/ICub_PC104_Linux_Image_-_Detailed_info * to modify these files, I directly connected pc104 and icubsrv (direct link), let icubsrv pretend he has the original configuration (change /etc/network/interfaces back to 10.0.0.1 and the like, issue sudo service networking restart) and I could connect to 10.0.0.2 to update pc104 files in situ. sudo service networking restart was useful there too * I had to correct ONE ERROR in the new distro : in /etc/rc/iCub.d/mounts.lists 10.0.0.1:/exports/code /usr/local/src/robot nfs soft,rerty=1,timeo=60,_netdev,auto should have "retry" instead of "rerty" * in case of error (copy paste is not always your friend...) one can mount the persistence file read-only with : mkdir /tmp/live sudo mount -o loop /media/KINGSTON/persistence /tmp/live Hope it helps ! I'm now trying to rebuild yarp (our old version...) with the new linux ;-) Best regards, Frederic

…

-- Frederic ELISEI http://www.gipsa-lab.fr/~frederic.elisei/ (33-4) 76574539 mailto:/Frederic.Elisei@gipsa-lab.grenoble-inp.fr Links: ------ [1] http://wiki.icub.org/wiki/The_Linux_on_the_pc104#How_to_create_the_bootable_USB_drive_with_the_live_image

[EliseiFrederic]

Le 05-12-2017 10:57, Matteo Brunettini a écrit :

Here [1] you can find the new release. Let us know about -- You are receiving this because you commented. Reply to this email directly, view it on GitHub [2], or mute the thread [3].

With this distribution, yarp compiles fine. But icub-main fails to find : libcfw002.h when building the Cfw2Can :-( I see the new distribution has the library and include file included directly : ./modules/4.9.0-3-rt-amd64/iCubDrivers/cfw002/LinuxDriver/API/libcfw002.h This might because of our outdated yarp/icub versions though :-(

…

-- Frederic ELISEI http://www.gipsa-lab.fr/~frederic.elisei/ (33-4) 76574539 mailto:/Frederic.Elisei@gipsa-lab.grenoble-inp.fr Links: ------ [1] http://www.icub.org/download/pc104-images/icub-live_7.9-17.12.04-rt-amd64.zip [2] #494 (comment) [3] https://github.com/notifications/unsubscribe-auth/AO6K9qyLJxMyRuWQ20pJjW-OCyA3KhI_ks5s9ROdgaJpZM4OGxVA

[EliseiFrederic]

Hi, I'm really sorry to have to report than with a freshly installed new icubsrv laptop, with up to date sources from the master branch for icub/yarp, I still have the ame compilation problem : Scanning dependencies of target cfw2can [ 3%] Building CXX object src/libraries/icubmod/cfw2Can/CMakeFiles/cfw2can.dir/yarp_plugin_icubmod_cfw2can.cpp.o In file included from /usr/local/src/robot/icub-main/build-pc104/src/libraries/icubmod/cfw2Can/yarp_plugin_icubmod_cfw2can.cpp:10:0: /usr/local/src/robot/icub-main/src/libraries/icubmod/cfw2Can/Cfw2Can.h:38:23: fatal error: libcfw002.h: No such file or directory #include "libcfw002.h" Can I get help from IIT gurus to finish the update/install ? Thanks in advance, Frédéric (& the Grenoble team)

…

-- Frederic ELISEI http://www.gipsa-lab.fr/~frederic.elisei/ (33-4) 76574539 mailto:/Frederic.Elisei@gipsa-lab.grenoble-inp.fr

[julijenv]

can we close this issue?