Jump to content

Rui Ribeiro

Members
  • Posts

    104
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Rui Ribeiro got a reaction from rubymp18 in Lamobo-R1 wifi unstable in AP ("host") mode [better buy a good wifi dongle with proper linux support]   
    I have been playing with the lamobo for quite a while. I actually do not like bananian. Tried openwrt also did not like it. The wifi seems to only operate for a bit while.
    Just tried the last version of armbian, kernel 4.2.3, the wifi drops after a few minutes, and I can only use it again if I close and open the wifi icon in my macbook. Interestingly enough, if I keep a ping in a shell it seems to last longer. Will do some more testing, though I am inclined to say the onboard wifi is so bad it is not usable.
  2. Like
    Rui Ribeiro got a reaction from rubymp18 in Lamobo-R1 wifi unstable in AP ("host") mode [better buy a good wifi dongle with proper linux support]   
    Been investigating a little. Unfortunately did not progress more, because the MicroSD card finally died. It seems the wifi driver has a long standing bug in Debian and derivates. I think I also saw a passing message about this either here or in SinoVoip board. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1365844I also found a very interesting explanation for a problem of not being able to not select 40Mhz channel bandwidth - http://www.brunsware.de/blog/gentoo/hostapd-40mhz-disable-neighbor-check.html
  3. Like
    Rui Ribeiro got a reaction from Jens Bauer in Lamobo-R1 wifi unstable in AP ("host") mode [better buy a good wifi dongle with proper linux support]   
    chester and Igor, as suggested by Igor here I have the changes in a rough form to make wifi in Lamobo R1 Stable.
     
    $su
     
    Install aptitude just because I prefer using it
     
    #apt-get install aptitude   Install tools for later on   #aptitude install dkms git   Correct missing sys/cdefs.h in the armbian 4.5 image or otherwise we wont be able to compile the hostapd version from realtek   #aptitude reinstall libc6-dev   Download the source of the new driver   #git clone https://github.com/dz0ny/rt8192cu.git   Steps to compile it   #cd rt8192cu   Edit include/autoconf.h and comment //#define CONFIG_DEBUG_RTL819X  (line 299) //#define CONFIG_PROC_DEBUG 1 (line 301)   If you do not disable the debug mode your logs will grow too fast.   Now let´s continue. This will compile, rmmod the old driver and install the new   #make dkms #cd ..   You do not need to reboot here. The make rules took care of removing the old driver, inserting the new, inserting a dkms rule for recompiling again the driver for kernel upgrades, and blacklisting the old module.   Go to this page  to download the realtek file   http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=48&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#RTL8192CU  and download the linux kernel driver (under RTL8192CU)   I got a file called 0001-RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911.zip. This file is around 1GB, if with limited space and/or MicroSD card on the destination unzip it on your machine, and just copy the tar.gz mentioned bellow.   $unzip 0001-RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911.zip $cd RTL8188C_8192C_USB_linux_v4.0.2_9000.20130911 $cd wpa_supplicant_hostapd   Copy wpa_supplicant_hostapd-0.8_rtw_r7475.20130812.tar.gz to your R1/pi/whatever.   #tar -zxvf wpa_supplicant_hostapd-0.8_rtw_r7475.20130812.tar.gz #cd wpa_supplicant_hostapd-0.8_rtw_r7475.20130812 #cd hostapd   Based on this page, I also commented out the check of neighbours to enable always 40MHz channels.  http://www.brunsware.de/blog/gentoo/hostapd-40mhz-disable-neighbor-check.html  It seems I am not needing it here, conditions might change in a near future.   In file src/ap/hw_features.c   line 453 - function ieee80211n_check_scan   /*              iface->conf->secondary_channel = 0; */   Now compile hostap   #make   stop hostap service. If it is not running, it will throw an error, ignore it   #service hostapd stop   not sure if the service was uninstalled by me before or by any previous script, installing the package just in case   #aptitude install hostapd   freeze hostapd package, for it in the future not to be upgraded   #echo hostapd hold | dpkg —set-selections      Overwrite hostap with the realtek ones that we compiled   #cp hostapd hostapd_cli /usr/sbin   Now create /etc/hostapd.conf file with: ssid=YOURSSID interface=wlan0 ctrl_interface=/var/run/hostapd channel=5 wpa=2 wpa_passphrase=YOUR_SSID_PASSWORD bridge=br0 wmm_enabled=0 driver=rtl871xdrv beacon_int=100 hw_mode=g ieee80211n=1 wme_enabled=1 ht_capab=[sHORT-GI-40][HT40+][HT40-][DSSS_CCK-40] wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP max_num_sta=8 wpa_group_rekey=86400   Start again the service.   #service hostapd start   DONE.   So after setting this up, to check up everything:   #iwconfig wlan0     IEEE 802.11bgn  ESSID:"YOURSSID"  Nickname:"<WIFI@REALTEK>"           Mode:Master  Frequency:2.432 GHz  Access Point: AC:A2:13:5C:96:31              Sensitivity:0/0             Retry:off   RTS thr:off   Fragment thr:off           Encryption key:off           Power Management:off           Link Quality=100/100  Signal level=88/100  Noise level=0/100           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0           Tx excessive retries:0  Invalid misc:0   Missed beacon:0     $lsmod | grep rtl8192cu rtl8192cu   My dmesg is after a reboot.   $dmesg  usb 2-1: new high-speed USB device number 2 using ehci-platform [    2.599494] usb 2-1: New USB device found, idVendor=0bda, idProduct=8178 [    2.599527] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [    2.599544] usb 2-1: Product: 802.11n WLAN Adapter [    2.599560] usb 2-1: Manufacturer: Realtek [    2.599575] usb 2-1: SerialNumber: 00e04c000001 [    3.909414] usbcore: registered new interface driver rtl8192cu [    4.944917] cfg80211: World regulatory domain updated: [    4.944946] cfg80211:  DFS Master region: unset [    4.944953] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [    4.944965] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [    4.944974] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [    4.944982] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [    4.944993] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [    4.945003] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [    4.945012] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [    4.945021] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [    4.945029] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [    9.504116] +871x_drv - drv_open, bup=0 [    9.508641]  ===> FirmwareDownload91C() fw:Rtl819XFwImageArray_TSMC [    9.508664] FirmwareDownload92C accquire FW from embedded image [    9.508674] fw_ver=v88, fw_subver=2, sig=0x88c0 [    9.534123] fw download ok! [    9.534140] Set RF Chip ID to RF_6052 and RF type to 2. [    9.930023] IQK:Start!!! [    9.941896] Path A IQK Success!! [    9.946770] Path B IQK Success!! [    9.955388] Path A IQK Success!! [    9.960148] Path B IQK Success!! [    9.965028] IQK: final_candidate is 0 [    9.965066] IQK: RegE94=ff RegE9C=3fe RegEA4=f7 RegEAC=3 RegEB4=101 RegEBC=a RegEC4=fb RegECC=9  Path A IQ Calibration Success ! [    9.967525] Path B IQ Calibration Success ! [   10.081283] pdmpriv->TxPowerTrackControl = 1 [   10.086157] rtl8192cu_hal_init in 580ms [   10.102538] MAC Address = ac:a2:13:5c:96:31 [   10.103040] -871x_drv - drv_open, bup=1     # iwlist wlan0 channel wlan0     14 channels in total; available frequencies :           Channel 01 : 2.412 GHz           Channel 02 : 2.417 GHz           Channel 03 : 2.422 GHz           Channel 04 : 2.427 GHz           Channel 05 : 2.432 GHz           Channel 06 : 2.437 GHz           Channel 07 : 2.442 GHz           Channel 08 : 2.447 GHz           Channel 09 : 2.452 GHz           Channel 10 : 2.457 GHz           Channel 11 : 2.462 GHz           Channel 12 : 2.467 GHz           Channel 13 : 2.472 GHz           Channel 14 : 2.484 GHz           Current Frequency:2.432 GHz (Channel 5)     Listing neighbours frequencies    # iwlist wlan0 scan | grep Channel                     Frequency:2.412 GHz (Channel 1)                     Frequency:2.412 GHz (Channel 1)                     Frequency:2.422 GHz (Channel 3)                     Frequency:2.412 GHz (Channel 1)                     Frequency:2.422 GHz (Channel 3)                     Frequency:2.422 GHz (Channel 3)                     Frequency:2.422 GHz (Channel 3)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.442 GHz (Channel 7)                     Frequency:2.442 GHz (Channel 7)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.437 GHz (Channel 6)                     Frequency:2.442 GHz (Channel 7)                     Frequency:2.452 GHz (Channel 9)                     Frequency:2.452 GHz (Channel 9)                     Frequency:2.452 GHz (Channel 9)                     Frequency:2.462 GHz (Channel 11)                     Frequency:2.462 GHz (Channel 11)                     Frequency:2.462 GHz (Channel 11)                     Frequency:2.467 GHz (Channel 12)                     Frequency:2.467 GHz (Channel 12)                     Frequency:2.472 GHz (Channel 13)   Working like a charm, no drops, 40MHz bandwidth in channel 5.   --   Rui Ribeiro
  4. Like
    Rui Ribeiro reacted to zador.blood.stained in [Lamobo-R1] [5.20] swconfig & problem with last 5.20 Armbian update   
    Please test this swconfig package (don't forget to use absolute path or remove other binary):
    https://dl.dropboxusercontent.com/u/5385968/swconfig_15.04-2%7Earmbian5.20%2B1_armhf.deb
  5. Like
    Rui Ribeiro got a reaction from zador.blood.stained in [Lamobo-R1] [5.20] swconfig & problem with last 5.20 Armbian update   
    Zador, the new binary seems to be working.
  6. Like
    Rui Ribeiro got a reaction from wildcat_paris in [Lamobo-R1] [5.20] swconfig & problem with last 5.20 Armbian update   
    Old swconfig
     
    # ldd swconfig
    linux-vdso.so.1 (0xbee4d000)
    libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6f6b000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e7a000)
    /lib/ld-linux-armhf.so.3 (0x7f601000)
     
    new swconfig
     
    # ldd swconfig
    linux-vdso.so.1 (0xbef88000)
    libnl-3.so.200 => /lib/arm-linux-gnueabihf/libnl-3.so.200 (0xb6f11000)
    libnl-genl-3.so.200 => /lib/arm-linux-gnueabihf/libnl-genl-3.so.200 (0xb6f04000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e14000)
    libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6df1000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6d7d000)
    /lib/ld-linux-armhf.so.3 (0x7f628000)
     
    The pthread library seems out of place here.
     
    @goldfish the difference in size is because the new is stripped
     
    Even then, after stripping
     
    root@ruir:/sbin# ls -la swconfig
    -rwxr-xr-x 1 root root 23276 Sep 17 04:30 swconfig
    root@ruir:/sbin# ls -la swconfig.new
    -rwxr-xr-x 1 root root 11444 Sep 16 20:10 swconfig.new
  7. Like
    Rui Ribeiro reacted to wildcat_paris in [Lamobo-R1] [5.20] swconfig & problem with last 5.20 Armbian update   
    @Rui
    Cool, so we have a workaround solution for others Lamobo-R1 Armbian users
  8. Like
    Rui Ribeiro got a reaction from wildcat_paris in [Lamobo-R1] [5.20] swconfig & problem with last 5.20 Armbian update   
    @goldfish, your binary restored my switch
  9. Like
    Rui Ribeiro reacted to wildcat_paris in [Lamobo-R1] [5.20] swconfig & problem with last 5.20 Armbian update   
    @Rui
     
    check if you still have the old binary in /usr/local/bin/
    whereis swconfig
     
    test it then overwrite the /sbin/swconfig
    so Zador has spare time to fix this problem
  10. Like
    Rui Ribeiro got a reaction from wildcat_paris in [Lamobo-R1] [5.20] swconfig & problem with last 5.20 Armbian update   
    Hi,
     
    Did today a kernel update...upon reboot, has no connectivity. I have lost swconfig; copied the one that comes with the sdcard/img download, it booting the switch by default, but does not allow to do much more...the reset and set operations are giving an error.
     
    What could I do?
  11. Like
    Rui Ribeiro got a reaction from wildcat_paris in [Lamobo-R1] [5.20] swconfig & problem with last 5.20 Armbian update   
    Here it is Zador. I only have one swconfig, unlike goldfish
     
    #swconfig dev eth0 help
    switch0: eth0(BCM53125), ports: 9 (cpu @ 8), vlans: 4096
         --switch
            Attribute 1 (int): enable_vlan ((null))
            Attribute 2 (string): ports ((null))
            Attribute 3 (int): reset_mib ((null))
            Attribute 4 (int): enable_jumbo ((null))
            Attribute 5 (int): allow_vid_4095 ((null))
            Attribute 6 (unknown): apply ((null))
            Attribute 7 (unknown): reset ((null))
         --vlan
            Attribute 1 (ports): ports ((null))
         --port
            Attribute 1 (string): mib ((null))
            Attribute 2 (int): pvid ((null))
            Attribute 3 (string): link ((null))
  12. Like
    Rui Ribeiro got a reaction from wildcat_paris in Hardware Mod BPi-R1   
    Was trying to desolder +3V pin, too much trouble. Ended up taking the wifi wafer out with a small blade, the R1 is so much better now. The wifi AP is next to it, wifi seems to be working better. I am using speedtest, and this is confirmed. Was there interference  noise from the realtek? Pity I did not take better measures.
  13. Like
    Rui Ribeiro reacted to tkaiser in RPi-MonitorWatcher - Android App   
    An alternative would be to think about the whole approach first and then drop the whole idea.
     
    RPi-Monitor if adjusted to the data sources of the boards we play here with is a great tool to explore system behaviour (as part of a development/optimization process) since it's leightweight enough to not tamper the system's behaviour it should monitor.
     
    When you have a look what RPi-MonitorWatcher is doing then it's just plain 'fooling yourself' as usual: https://github.com/tobiasfiechter/RPi-MonitorWatcher/blob/master/app/src/main/java/io/hotkey/rpi_monitorwatcher/model/Raspberry.java#L16-L22
     
    Numbers without meaning displayed in nice colors. And the usual misunderstanding of 'average load' which is most of the times NOT CPU related on Linux SBCs (the author calls average load 'statusCPULoad' which is plain wrong). To understand what's wrong with such approaches please see http://forum.armbian.com/index.php/topic/1160-login-script-enhancement-for-load-average-color/?view=getlastpost
     
    But I doubt that this information will help since most people love numbers without meaning especially when nice colored graphs have been made of them.
  14. Like
    Rui Ribeiro reacted to tkaiser in Tkaiser made the news   
    I've neither found this nor fixed the code -- I just sat in a beergarden watching others do the work, wrote a summary later and also informed affected vendors where possible (LinkSprite and CubieTech still ignoring the issue and SinoVoip as usual providing a fix in the most complicated way so 99,9% of their users are still affected by exploits targeting this vulnerability, same applies most probably to 100% of Xunlong/loboris OS image users).
     
    So kudos to the people who discovered this and fixed it!
     
    We should take this as a reminder why 'legacy' kernels should be avoided where possible. You never know how many of these issues are present there since vendor provided kernels are made without code/peer review by contractors/employees paid by SoC vendors that do not care about security at all. Expect the worst. Always!
     
    And that's why the ability to use mainline kernel is that important. And why it's important to use a distro like Armbian that is actively developed. I would suspect that most if not all OS images for Orange Pis that are still available on orangepi.org download section will never be upgraded and that the users there not even know what's going on.
  15. Like
    Rui Ribeiro reacted to tkaiser in help me to chose good board for home NAS these days - 2016   
    You should take an hour and read carefully through this article here: http://linux-sunxi.org/Sunxi_devices_as_NAS
     
    What differentiates Banana Pro from the original Banana Pi (or M1) is just onboard WiFi, same applies to M1+ that has been designed to be a Banana Pro clone (after the LeMaker and SinoVoip divorce -- of course SinoVoip failed with a few details so OS images for Pro are NOT 100 per cent compatible with M1+). 
     
    In my personal opinion all these cheap onboard WiFi solutions aren't worth a look so I would neither choose Pro nor M1+ but the original Banana Pi instead (also cheaper). In case you want to use WiFi do some research before regarding your specific use case. And please remember that M1+ is made by a company 'famous' for not being able to provide correct hardware descriptions (be it .fex files or .dts files -- they still simply don't give a sh*t about correct information -- until this is resolved I would not buy anything from them).
     
    Regarding M1+ (and WiFi) also worth a read:
    http://forum.armbian.com/index.php/topic/340-banana-pi-pro-m1plus-no-wifi-armbian-45/ http://forum.armbian.com/index.php/topic/1149-patches-for-m1-dts-file-for-wifi/ http://forum.armbian.com/index.php/topic/1079-the-armbian-status-for-banana-pi-m1-plus/ BTW: We can expect an A20 successor called A20E rather soon (internally called sun8iw11p1, still dual core, still SATA capable but clocked somewhat higher). But since this chip seems to be based on different IP blocks compared to 4 years old A20 while it might be 100% pin compatible to A20 we currently know nothing what to expect regarding drivers and general compatibility).
  16. Like
    Rui Ribeiro reacted to tkaiser in Login Snipplet Updates available at Login   
    You might be talking about /etc/update-motd.d/40-updates? Please keep in mind that the information there might be outdated by 2 days since the count of available updates will be somehow cached since it migth delay any login attempt otherwise.
     
    https://github.com/igorpecovnik/lib/blob/master/scripts/update-motd.d/40-updates#L139
     
    So in case you really believe this is valuable 'information' then think about adjusting the script so that it updates /var/cache/apt/archives/updates.number anyway and call it from cron hourly or in case you love ultra slow logins modify the twodays_ago formula to your needs.
  17. Like
    Rui Ribeiro reacted to zador.blood.stained in Testers wanted: Improving THS settings   
    I don't expect any H3 board to survive at full load in a small box made of anything that doesn't conduct heat well or without enough holes at the top and bottom.
     
    In same hellish conditions?
     
    BTW, please look at your logs and cooler table. You want cores to be killed at 240MHz, but frequency doesn't go lower than 480 probably due to limits defined in /etc/default/cpufrequtils and/or FEX file DVFS table. 
     
    Edit; First 5 lines with 240MHz @ 51-52°C are probably due to data collection starting before cpufrequtils applied its settings.
  18. Like
    Rui Ribeiro reacted to tkaiser in Security Alert for Allwinner sun8i (H3/A83T/H8)   
    This security flaw has been proudly produced by Allwinner itself: https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/arch/arm/mach-sunxi/sunxi-debug.c
     
    As Zador explained there might be good reasons to enable/use something like this while developing, the real problem ist that none of these devs does really care about Linux and 'productive use' (and security at all). That's one of the reasons no one wants to use these BSP kernels since you never know how many surprises like this are hidden in there.
     
    Fortunately mainlining efforts for H3 are still progressing nicely so we can throw this Allwinner 3.4 crap in the bin rather sooner than later
  19. Like
    Rui Ribeiro reacted to zador.blood.stained in Security Alert for Allwinner sun8i (H3/A83T/H8)   
    Original BSP kernel is designed for Android, where getting root privileges in "one click" would be very useful for testing and debugging purposes...
    ... if only there was a simple way (even kernel config symbol!) to disable this for production / public images.
  20. Like
    Rui Ribeiro reacted to sooperior in Learning Linux, begginer advice please.   
    Hi,
    I'm afraid this might not be the best place. Armbian, or rather the devices it runs on, requires some technical knowledge/linux background.
    If I were you I recommend using something like Debian, Ubuntu or Linux Mint (Mint is easy and similar to windows 7/Vista) in a standard PC. You can find plenty of tutorials on how to install / use them and most of the time you'll be working with a graphical interface.
     
    You are more than welcome to use armbian (after you have learned a bit of linux) but as a starting point... Honestly, I don't recommend it. Armbian is based on debian (also Ubuntu and Mint), so you can start by learning Debian or its derivatives and then give armbian a try.
     
    PS: You know that armbian can only run on soc devices, not in a standard PC, don't you?
  21. Like
    Rui Ribeiro reacted to tkaiser in Banana Pi M3   
    Again: What are you talking about? Armbian does not support Banana Pi M3. If you use the insanely broken Armbian rip-off 'Team BPi' provides then please ask them what they fucked up (but since they fucked up so many things in all of their crappy OS images they obviously have no clue which skills they lack   )
  22. Like
    Rui Ribeiro reacted to tkaiser in Banana Pi M3   
    Another update on the great 'development efforts' 'Team BPi' shows. A few hours ago they finally managed to add 1-wire support to their kernel tree for the Banana Pi M3.
     
    Missing 1-Wire support was brought to their attention several times through their forums in the last months, a user provided the necessary driver as pull request for the M2 back on 3rd Dec., it took them only 24 days to merge this pull request (hard work you know?), and then just additional 19 days to get the idea to activate 1-wire for Banana Pi M3 also.
     
    What does this mean for unfortunate M3 customers already using their OS images? Simply nothing since 'Team BPi' still provides no kernel/u-boot update routines. Most probably they will release a couple of new fishy OS images the next days/weeks that suck not that much any more. But it's still close to unbelievable they don't provide an online update routine so users can benefit immediately from fixes to their BSP they commited on Github.
     
    We've told them so many times how easy it is to achieve this but they still don't care about anything else than selling their hardware and tricking users into believing some sort of development/support progress would be made.
     
    Same with the issue kometchtech brought to our and their attention (adding "init=/bin/systemd" to the bootargs which is necessary for every OS image that makes use of systemd -- and these are a lot). This is something they should've to adjust in sunxi-pack/chips/sun8iw6p1/configs/*/env.cfg but they refuse to and provide countless crappy OS images that all do not fully work instead.
  23. Like
    Rui Ribeiro reacted to zador.blood.stained in banana R1 / hardware watchdog   
    A20 hardware watchdog is supported by both kernel families and should work if configured correctly.
    "dmesg | grep watchdog" on mainline:
    [ 3.448805] sunxi-wdt 1c20c90.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) How to configure it depends on your OS release.
  24. Like
    Rui Ribeiro reacted to Rui Ribeiro in banana R1 / hardware watchdog   
    Hi,
     
    Was anyone able to use the watchdog in the Lamobo/banana pi r1? If not is anyone using some hardware that resets it/an hardware watchdog?
  25. Like
    Rui Ribeiro reacted to tkaiser in For our get all the data fre..ks :)   
    You find most if not all used methodologies/tools listed here: http://de.slideshare.net/brendangregg/broken-linux-performance-tools-2016
     
    On a SBC I would always take care to use a minimalistic monitoring approach since when the monitoring task starts to influence the behaviour of the system (always running at highest clockspeeds for example when interactive performance governor is used) then this is simply 'Monitoring gone wrong'.
     
    Another huge difference when we're talking about more recent SBCs is the thermal/throttling and dvfs/cpufreq behaviour. Not taking that into account and looking at something more or less useless like 'load average' is just fooling yourself (without taking notice). So if you've fun watching at meaningless graphs this might be great. Otherwise better stay away from it unless it serves ok for specific use cases you're an expert in (networking stuff for example)
     
    Please just think a few seconds about a monitoring approach that does not monitor CPU clockspeeds and throttling strategies either. Is having an average CPU utilisation of 50% 'bad'? When the system is downclocking to 240 MHz at the same time to save energy and lower temperatures? Is it better when the system only shows 10% CPU utilisation since cpufreq settings let it run at 1200 MHz instead (and the SBC consumes twice as much energy due to dvfs settings)?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines