maemo.org - Talk - [Fremantle Maemo5] Tox for N900

maemo.org - Talk (https://talk.maemo.org/index.php)

- Applications (https://talk.maemo.org/forumdisplay.php?f=41)

- - [M5] Tox for N900 (https://talk.maemo.org/showthread.php?t=93647)

Hi
Tox is an open-source and secure instant messenger.
Can someone port it to N900?

Re: Tox for N900

OSS code review FTW!

Re: Tox for N900

Quote:

Originally Posted by usr (Post 1437540)

Bump this topic.

look at my previous post in the thread. in case it is not clear - calling that main loop at least 20 times per second would mean that battery will get flat in a matter of few hours. If we are to believe to that comment (and I see no reason to not), there is something wrong with the design of that SW if it needs to poll for events instead of waiting for them.

BTW is there any port to another mobile OS?

Re: Tox for N900

You can find Tox for Android, I tried it in the Nexus 5 and the Jolla but some nasty bugs still exist, not very usable at this stage.

You fill find it here : https://github.com/Astonex/Antox

Tox is certainly the more secure messaging application (P2P/hash table), I'm eagerly waiting for a Sailfish port.

Re: Tox for N900

Information:

Tox is on my mer repository for SailfishOS (Jolla).

https://build.merproject.org/package...e:nielnielsenl

You can add this repository with

Code:

# zypper ar -G http://repo.merproject.org/obs/home:...latest_armv7hl sailfish_latest_armv7hl

You need toxcore-master, toxcore-master-ntox and libsodium

No native GUI, but nTox -commandline version, see https://wiki.tox.im/NTox is avaliable.

Edit: I now only need a few friends :P
Edit: Added myself as a friend (YEAH) see pic (GUI is from my Debian Box, shell window is Jolla CLI)

Re: Tox for N900

nieldk: and how's the CPU/battery usage when the client is active?

Re: Tox for N900

Quote:

Originally Posted by freemangordon (Post 1437591)

It doesn't surprise me if it's really P2P and uses a DHT.

As usual I have to wonder what they found out to be so wrong with Jabber to warrant yet another incompatible network.

Re: Tox for N900

Quote:

Originally Posted by freemangordon (Post 1437701)

nieldk: and how's the CPU/battery usage when the client is active?

Hmm better to evaluate once q Qt/QML frontend is done, since nTox is commandline only.
But, I enclose htop of the process running

Re: Tox for N900

Quote:

Originally Posted by nieldk (Post 1437704)

Hmm better to evaluate once q Qt/QML frontend is done, since nTox is commandline only.
But, I enclose htop of the process running

as suspected, it keeps cpu woken up (judging by the fact this is the second process after htop itself). I will be glad to be proven wrong, but I think this is unusable for mobile device in its current shape. no matter if it uses CLI or GUI.

Re: Tox for N900

I made a test with Tox, Mitakuuluu (Whatsapp for Sailfish) and Wechat (Tencent) running together, here is the result with Crest.

It seems Tox is not eating too much battery as the CPU usage of Mitakuuluu is always higher (and Mitakuuluu does not eat too much battery unless the CPU bug appears...).

Re: Tox for N900

Quote:

Originally Posted by Jordi (Post 1437774)

well, it seems that my criteria for "too much" differs a lot, because in my book anything but nothing is too much, when a piece of SW is doing nothing.

anyway, I'll try to compile tox for n900 and launch oprofile against it once I am back from holiday (wednesday that is). that will give us a clear picture of what is really going on and if it makes any sense to waste time on writing GUI.

Re: Tox for N900

Quote:

Originally Posted by freemangordon (Post 1437777)

Thanks in advance!

Re: Tox for N900

Retroshare seems like it is a more what we want, more decentralized and still OSS.
http://retroshare.sourceforge.net/

Re: Tox for N900

Quote:

Originally Posted by freemangordon (Post 1437777)

With light usage, the Jolla can last 2 or 3 days between 2 battery charges. With or without Mitakuuluu running, it's not very different. That is why I said that Mitakuluu doesn't eat to much battery :)

Re: Tox for N900

Quote:

Originally Posted by freemangordon (Post 1437777)

well, it seems that my criteria for "too much" differs a lot, because in my book anything but nothing is too much, when a piece of SW is doing nothing..

As the Android piece of hardware the Jolla is, it suspends, so they do no care about stupidity caused useless timers. :(

Re: Tox for N900

As mentioned by freemangordon it will be a lot of battery consumer app, and starting from scratch on this app, why dont anyone make GUI of telegram cli client made by NerdKnight? Just curious, coz it is a perfect multi-platform IM app in my opinion.

Re: Tox for N900

@Jordi you looking at harbour-mitakuuluu2 which is just GUI, look at harbour-mitakuuluu2-server, which is actually process talking with whatsapp server ;)

Re: Tox for N900

Concerning tox.. Have you looked at amount of network traffic that this app generates continuosly also when it is supposed to be almost idle?

Re: Tox for N900

Doesn't look good :(

Code:

Mem: 216116K used, 19136K free, 0K shrd, 1812K buff, 56808K cached

CPU:  8.6% usr  6.3% sys  0.0% nice 84.7% idle  0.0% io  0.0% irq  0.3% softirq

Load average: 1.15 0.41 0.19

  PID  PPID USER     STAT   RSS %MEM %CPU COMMAND

18812 18621 root     S     2312  0.9  3.9 ./nTox 192.81.133.111 33445 8CD5A9BF0A6CE358BA36F7A653F99FA6B258FF756E490F52C1F98CC420F78858 

   10     2 root     SW       0  0.0  2.4 [omap2_mcspi]

  564     2 root     SW       0  0.0  1.5 [wl12xx]

16383  1296 user     S    12584  5.3  1.1 /usr/bin/osso-addressbook                                                  

18844 18839 root     R      740  0.3  1.1 top

powertop confirms it:

Code:

~/tox # powertop

Powertop 1.13.3

status: Unknown job: pmtrackerdaemon

Sleeping for 11 seconds before sampling

Collecting data for 30 seconds

Sample interval was 00m 30s 20996us



C#      | Ratio  | Avg/dura | Frequency | Ratio

--------+--------+----------+-----------+--------+

     C0 |  23.7% |          |  1150 MHz |   nan% |

     C1 |   0.2% |    0.8ms | 

     C2 |  42.4% |    8.0ms | 

     C3 |  33.7% |   39.8ms | 

     C4 |   0.0% |    7.4ms | 



IRQ#    | Activity   | Type           | Name

--------+------------+----------------+---------------------------

     12 |       8044 |           INTC | DMA

     37 |       1894 |           INTC | gp

     11 |       1324 |           INTC | prcm

    202 |        585 |           GPIO | wl1251

     56 |        400 |           INTC | i2c_omap

     86 |        332 |           INTC | mmc1

     83 |         53 |           INTC | mmc0

     57 |         39 |           INTC | i2c_omap

    225 |          4 |           GPIO | omap2-onenand



PID#    | Activity   | Name           | Function Entry (Expire)

--------+------------+----------------+---------------------------

      0 |       1120 |  <kernel core> | tick_nohz_restart_sched_tick (tick_sched_timer)

  18812 |        549 |           nTox | schedule_hrtimeout_range (hrtimer_wakeup)

    564 |        218 |         wl12xx | schedule_timeout (process_timeout)

      0 |        207 |  <kernel core> | hrtimer_start (tick_sched_timer)

    564 |        184 |         wl12xx | queue_delayed_work (delayed_work_timer_fn)

     38 |         98D|            awk | cpufreq_governor_dbs (delayed_work_timer_fn)

   1502 |         91 |       wlancond | ieee80211_ioctl_siwpower (ieee80211_dynamic_ps_timer)

    564 |         63 |         wl12xx | schedule_timeout (process_timeout)

     10 |         32 |    omap2_mcspi | sk_reset_timer (tcp_delack_timer)

    597 |         13 |          mmcqd | queue_delayed_work (delayed_work_timer_fn)

     10 |          9 |    omap2_mcspi | neigh_add_timer (neigh_timer_handler)

    597 |          8 |          mmcqd | schedule_timeout (process_timeout)

    723 |          7 |           dsme | __enqueue_rt_entity (sched_rt_period_timer)

    935 |          6 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)

    580 |          5 |          mmcqd | queue_delayed_work (delayed_work_timer_fn)

   8506 |          4 |        pdflush | ubifs_wbuf_write_nolock (wbuf_timer_callback_nolock)

      1 |          3D|  <kernel core> | queue_delayed_work (delayed_work_timer_fn)

     30 |          3 |          mount | setup_wb_timer (wb_timer_fn)

   1816 |          3 |         modest | sk_reset_timer (tcp_write_timer)

   1818 |          3 |         modest | sk_reset_timer (tcp_write_timer)

    580 |          3 |          mmcqd | schedule_timeout (process_timeout)

    935 |          2 |      bme_RX-51 | sys_timer_settime (posix_timer_fn)

    935 |          2 |      bme_RX-51 | do_nanosleep (hrtimer_wakeup)

    935 |          2 |      bme_RX-51 | schedule_timeout (process_timeout)

    761 |          2D|<kernel module> | queue_delayed_work (delayed_work_timer_fn)

    723 |          2 |           dsme | do_nanosleep (hrtimer_wakeup)

  18262 |          2 |telepathy-gabbl | sk_reset_timer (tcp_write_timer)

   1820 |          2 |         modest | sk_reset_timer (tcp_write_timer)

   1820 |          2 |         modest | journal_get_write_access (commit_timeout)

   1799 |          2 |         modest | schedule_hrtimeout_range (hrtimer_wakeup)

    580 |          2 |          mmcqd | schedule_timeout (process_timeout)

  18812 |          2 |           nTox | sk_reset_timer (tcp_write_timer)

  18821 |          1 |           sshd | sk_reset_timer (tcp_write_timer)

    985 |          1 |           hald | schedule_hrtimeout_range (hrtimer_wakeup)

      1 |          1 |  <kernel core> | inet_initpeers (peer_check_expire)

  14960 |          1 |         mebook | schedule_hrtimeout_range (hrtimer_wakeup)

      0 |          1 |  <kernel core> | queue_delayed_work (delayed_work_timer_fn)

   1818 |          1 |         modest | schedule_timeout (process_timeout)

     10 |          1 |    omap2_mcspi | fib6_add (fib6_gc_timer_cb)

   1816 |          1 |         modest | schedule_timeout (process_timeout)

   1424 |          1 |hildon-status-m | schedule_hrtimeout_range (hrtimer_wakeup)

    738 |          1 |        syslogd | hrtimer_start (it_real_fn)

   1816 |          1 |         modest | journal_get_write_access (commit_timeout)

   8506 |          1 |        pdflush | journal_get_write_access (commit_timeout)

    500 |          1 |          kmmcd | schedule_timeout (process_timeout)

  18824 |          1 |       powertop | do_nanosleep (hrtimer_wakeup)



Power domain activity breakdown

Domain  | % of time spent in states

--------+---------+---------+---------+---------+----------

usbhost |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    sgx |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    per |OFF:  32%|RET:  42%|INA:   0%| ON:  24%| now:(ON)

    dss |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    cam |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

   core |OFF:   0%|RET:  32%|INA:  31%| ON:  36%| now:(ON)

   neon |OFF:   0%|RET:  33%|INA:  41%| ON:  24%| now:(ON)

    mpu |OFF:   0%|RET:  33%|INA:  41%| ON:  24%| now:(ON)

   iva2 |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)



Clock activity breakdown at end of period

Domain  | Active clocks

--------+---------------+---------------+------------------

   core |          SDRC | HSOTGUSB_IDLE |      OMAPCTRL 

        |     MAILBOXES |

   wkup |          GPT1 |       32KSYNC |         GPIO1 

        |          WDT1 |           SR1 |           SR2 

        |

  ckgen |          CORE |          PERI |           96M 

        |           48M |           12M |           54M 

        |      EMU_CORE |

    per |         GPIO2 |         GPIO3 |         GPIO4 

        |         GPIO5 |         GPIO6 |



Total wakeups  15340, 511.3/s | IRQ 12675, 422.5/s | Timers 2665,  88.8/s

HW wakeups       44,   1.5/s |     Real gp_timers expired  102,   3.4/s

Now, it might be that nTox is badly written, but on my desktop PC uTox shows similar CPU usage

Code:

top - 10:51:47 up 5 days,  3:37,  7 users,  load average: 0,15, 0,13, 0,21

Tasks: 239 total,   3 running, 236 sleeping,   0 stopped,   0 zombie

%Cpu(s):  2,3 us,  1,3 sy,  0,0 ni, 96,1 id,  0,2 wa,  0,0 hi,  0,1 si,  0,0 st

KiB Mem:  16388860 total,  5986692 used, 10402168 free,   852760 buffers

KiB Swap: 16467964 total,        0 used, 16467964 free.  3073580 cached Mem



  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     

 3012 ivo        9 -11  523296  15972  13004 S   6,6  0,1 302:11.32 pulseaudio  

22516 ivo       20   0  775072  14896   8980 S   4,6  0,1   1:01.81 utox        

 8743 ivo       20   0  513416  53060  25736 S   1,3  0,3   0:50.90 plugin-con+ 

24380 ivo       20   0 1436516 437112  56372 S   1,3  2,7   6:42.79 firefox

It seems nTox simply does while(1) loop with tox_do calls every n msecs(simplified), so a better structured code that uses what is explained on https://libtoxcore.so/getting_starte...to-come-to-you might be more efficient. I might look into hacking nTox to work like that.

Find here binaries compiled for N900 if you want to play with it.

Re: Tox for N900

cute, seems https://libtoxcore.so/getting_starte...to-come-to-you functions are no longer supported https://github.com/irungentoo/toxcor...8e53666aa91739

I asked on #tox-dev if there is a replacement API, lets see if there will be an answer

Re: Tox for N900

I wouldn't waste any more time on that, unless someone fix the logic behind. Excerpt from a chat I had on #tox-dev(irungentoo is the main tox dev IIUC):

Quote:

freemangordon: hi guys, I compiled tox for Maemo5 (Nokia N900) then performed some tests with nTox. While playing with it, I saw there is high CPU usage when idle. after googling a bit, I found this https://libtoxcore.so/getting_starte...to-come-to-you . Unfortunately those functions have been removed https://github.com/irungentoo/toxcor...8e53666aa91739 . Is there any replacement API I can use, as in its current shape (calling tox_do every n msecs), tox is unusable on battery operated devices?
freemangordon: irungentoo: ^^^
irungentoo: freemangordon, uint32_t tox_do_interval(Tox *tox);
irungentoo: freemangordon, the other functions were removed because nobody used them
freemangordon: irungentoo: if I read the code correctly, the minimum value is 50 ms
irungentoo: text chats should work with 500ms
irungentoo: but if you do file transfers or A/V, you need to call it more
freemangordon: whatever the interval is, it is still polling for events, thus waking CPU no matter if there is data to be processed or not
irungentoo: there will always be data
freemangordon: irungentoo: ok, I'll rephrase my question - is there any chance to bring back tox_wait_xxx API?
irungentoo: freemangordon, it didn't work and increased the number of times tox_do() was run
freemangordon: I see

Re: Tox for N900

...."irungentoo: there will always be data"...

.... WTF?!? It should be nice on a 3G connected device..

Re: Tox for N900

Quote:

Originally Posted by freemangordon (Post 1438186)

Doesn't look good :(

Find here binaries compiled for N900 if you want to play with it.

Can you add .deb file that can be installed on n900?

Re: Tox for N900

Quote:

Originally Posted by usr (Post 1438229)

Can you add .deb file that can be installed on n900?

no, I won't waste time on debian packaging, sorry.

simply download tar.gz from the link I posted earlier, extract it somewhere in /opt, cd to that dir and run nTox with LD_LIBRARY_PATH=./ nTox ...

Re: Tox for N900

@freemangordon, thanks for your tests and congratulations for your findings!

"there will always be data" : is this by design, because every device is part of the network (and is used to process messages of other users)?

Re: Tox for N900

it used to process finding nodes for faster connection, it using dht. all messages going p2p only, not through other devices :D

Re: Tox for N900

Thank you for the investigation.

How bad is "there will always be data" and dropped tox_wait_xxx API in usability terms when compared to Skype on N900?

Besides the Tox CPU consumption could we rejoice to have a multi-platform secure, open source text, voice and videochat solution that does not require to re-exchange security keys each time the user switches OS or should we look elsewhere?

Re: Tox for N900

Quote:

Originally Posted by freemangordon (Post 1438240)

no, I won't waste time on debian packaging, sorry.

simply download tar.gz from the link I posted earlier, extract it somewhere in /opt, cd to that dir and run nTox with LD_LIBRARY_PATH=./ nTox ...

So what should I do?
extract Tox folder to /home/opt/
then in terminal

Code:

# cd /home/opt/tox

Whats next?
Tell me in detail please

Aslo it's bad that Tox for Android and iOS has user-friedly GUI and n900 has deprecated and will likely no longer work nTox.
Anyway thanks a lot for compiling!

Re: Tox for N900

Quote:

Originally Posted by usr (Post 1438395)

So what should I do?
extract Tox folder to /home/opt/
then in terminal

Code:

# cd /home/opt/tox

Whats next?
Tell me in detail please

Aslo it's bad that Tox for Android and iOS has user-friedly GUI and n900 has deprecated and will likely no longer work nTox.
Anyway thanks a lot for compiling!

For you next will be typing LD_LIBRARY_PATH=/home/opt/tox ./nTox

and then read

https://wiki.tox.im/NTox

and this

https://wiki.tox.im/Servers

Re: Tox for N900

Hi there

Tox can work on our N900 ?