maemo.org - Talk
Page 3 of 4 12 3 4
Show 40 post(s) from this thread on one page

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)

freemangordon 2014-09-04 08:09
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.

freemangordon 2014-09-04 09:03
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

freemangordon 2014-09-04 15:51
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

xes 2014-09-04 16:27
Re: Tox for N900
 
...."irungentoo: there will always be data"...

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

usr 2014-09-04 17:11
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?

freemangordon 2014-09-04 17:57
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 ...

Jordi 2014-09-04 21:50
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)?

coderus 2014-09-04 22:10
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

ste-phan 2014-09-05 09:50
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?

usr 2014-09-06 07:18
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!


All times are GMT. The time now is 10:11.
Page 3 of 4 12 3 4
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8