jkajolin

All socks have terrible slow filesystems even 10 years old market pc runs faster. Example linux swap is terrible slow from sd-card. javas biggest problem is and has always been garbage collector it makes the software really cpu depended and on weak systems the performance is poor. For a pure performance I would go for the small size embedded pc's. Java is reasonable if you have alot of memory, strong CPU and the application loads as match as possible at startup.

Running Linux under Linux is quite power full. I example have a 8-core, 32GB RAM machine which I use to run libvirt/QEMU on local SDD hard drives. At work I use Oracle VirtualBox under MacOS and libvirt/QEMU under Linux Desktop, its so easy to mess up your desktop just be installing some garbage and there is not real uninstall on Linux environments. Just create a clean installation and snapshot it then revert as needed for clean installations. Performance is not the best on desktop installation as the desktop itself takes quite a lot of resources and the virtual filesystem is really slow.

got today mine. raspberry pi zero W v.1.1 at first glance don't see where the wireless chip is but have to see if have time to get it running seems similar to what Raspberry Pi 3 install process does - serial console is blocked by the bluetooth chip (which you can override from /boot/config.txt; dtoverlay=pi3-disable-bt) - remote ssh is blocked (haven't checked what the raspiconfig does to allow it) - uses wpa_suplicant for wireless lsmod Module Size Used by sg 20831 0 brcmfmac 201842 0 brcmutil 9031 1 brcmfmac snd_bcm2835 23131 0 snd_pcm 95473 1 snd_bcm2835 snd_timer 22556 1 snd_pcm snd 68400 3 snd_bcm2835,snd_timer,snd_pcm cfg80211 500739 1 brcmfmac rfkill 21397 2 cfg80211 bcm2835_gpiomem 3759 0 bcm2835_wdt 4133 0 uio_pdrv_genirq 3718 0 uio 10230 1 uio_pdrv_genirq ipv6 367697 20 # lscpu Architecture: armv6l Byte Order: Little Endian CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 Model name: ARMv6-compatible processor rev 7 (v6l) CPU max MHz: 1000.0000 CPU min MHz: 700.0000 root@zerow1:~# ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr --- inet addr:192.168.88.194 Bcast:192.168.88.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8213 errors:0 dropped:21 overruns:0 frame:0 TX packets:2790 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:10297797 (9.8 MiB) TX bytes:351783 (343.5 KiB)

If you have network manager running it will mess up and you should not use wpa_supplicant direcrly but use nmcli commands / profiles I just use thins simple line on /etc/network/interfaces wpa-conf /etc/wpa_supplicant/example.conf

Same with Orange Pi PC lite. Have not tried to fix it.

do id ls -l

You can not do anything for the digital pin rules, the difference between low and high is hardcoded. From what I understand there is no single value for the threshold but it works on higher than some targed value... Some logic coverter might work but I think you need analog device which basic socs do not support

Using wlan scanner from mobile phone I did notice that the channel 1 was not the best one. I have 3 wlan routers in differend rooms and hard wired lan cables between them so there might be some overlapping. i did the test on cheap market lenovo laptop it showed about 4mbit speed. From a normal wlan router the speed was something like 15mbit. With hostap I removed the network manager alltogether. I have the same configuration on pc plus and pc 2e which seem to work fine atleast with one esp8266 client posting iot data on 1 min intervals. Have't done any stresstests yet with multiple clients. I have around 20 units ready to be used some day hopefully soon

It seems to have the same problem than with hostap. It works fine for a while but then the client connection starts to fail and the kernel starts to spam these messages There is nothing to do other than disconnect the client and try again as it seems to work again Feb 18 16:48:13 iothub1 kernel: [ 3081.881165] xradio_wlan mmc1:0001:1: received frame has no key status

Had some free time to toy around with Orange Pi Zero Used a image "Armbian_5.26_Orangepizero_Ubuntu_xenial_dev_4.10.0.img" build with 'compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=no PROGRESS_DISPLAY=plain RELEASE=xenial BUILD_DESKTOP=no' - which should not do anything special ? 1) First steps - run upgrades and normal tweaking (changed hostname, disabled ipv6, changed ntp, changed time-zone, generated correct locale) 2) Ensure that WLAN0 is working as client - using 'nmtui' created a new connection to my desktop WLAN router - disabled auto connect from eth0 - reboot with serial connection - run example speedtest-cli to see that the driver do work 3) Removed the client profile and redo the eth0 for auto connection 4) I used these lines to create the sample profile but them afterwards tweaked it around with nmtui 'edit profile' nmcli c add type wifi ifname wlan0 con-name ap-wlan0 autoconnect no ssid zmserver nmcli connection modify ap-wlan0 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method shared nmcli connection modify ap-wlan0 wifi-sec.key-mgmt wpa-psk nmcli connection modify ap-wlan0 wifi-sec.psk "password" nmcli connection up ap-wlan0 Key points here are 802-11-wireless.mode ap and shared - shared means that network manager creates "internet-connection sharing" like MacOS and Windows wizards - you cannot give dns-server or any other setting while using the shared - selection Ensure that the "automatically connect" is selected to make sure that the connection is started when booted 5) I do have the basic nat lines enabled with 'iptables-persistent' sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT 6) Actual profile root@iothub1:/etc/NetworkManager/system-connections# more AP [connection] id=AP uuid=8e0bb6d9-52f9-4000-bbfa-d49db6790598 type=wifi interface-name=wlan0 permissions= secondaries= timestamp=1487425840 [wifi] band=bg channel=1 mac-address-blacklist= mac-address-randomization=0 mode=ap seen-bssids=12:42:13:81:F5:29; ssid=IotHub1 [wifi-security] group= key-mgmt=wpa-psk pairwise= proto= psk=iothub123 [ipv4] dns-search= method=shared [ipv6] addr-gen-mode=stable-privacy dns-search= method=ignore Some output # nmcli d DEVICE TYPE STATE CONNECTION eth0 ethernet connected Wired connection 1 wlan0 wifi connected AP lo loopback unmanaged -- # nmcli c NAME UUID TYPE DEVICE AP 8e0bb6d9-52f9-4000-bbfa-d49db6790598 802-11-wireless wlan0 Wired connection 1 b9e400ce-f567-3f12-b459-366adc05a7f2 802-3-ethernet eth0 # ifconfig eth0 Link encap:Ethernet HWaddr 02:42:13:81:f5:29 inet addr:192.168.88.206 Bcast:192.168.88.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:45505 errors:0 dropped:0 overruns:0 frame:0 TX packets:28178 errors:0 dropped:0 overruns:0 carrier:0 collisions:20 txqueuelen:1000 RX bytes:66887562 (66.8 MB) TX bytes:2051800 (2.0 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 TX bytes:0 (0.0 wlan0 Link encap:Ethernet HWaddr 12:42:13:81:f5:29 inet addr:10.42.0.1 Bcast:10.42.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:27567 errors:0 dropped:0 overruns:0 frame:0 TX packets:44475 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1901813 (1.9 MB) TX bytes:67699829 (67.6 MB) # iwconfig wlan0 wlan0 IEEE 802.11 Mode:Master Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:off 7) Does it work ==> YES Is it fast ==> NO Is it realiable ==> DO NOT KNOW Feb 18 16:25:35 iothub1 wpa_supplicant[706]: wlan0: AP-STA-DISCONNECTED 78:45:61:ee:43:47 Feb 18 16:25:35 iothub1 kernel: [ 1723.628815] ieee80211 phy0: vif 0: set_key cmd 1 Feb 18 16:25:35 iothub1 wpa_supplicant[706]: Device is trying to offload WPS Probe Response while not supporting this Feb 18 16:25:38 iothub1 wpa_supplicant[706]: Device is trying to offload WPS Probe Response while not supporting this Feb 18 16:25:38 iothub1 wpa_supplicant[706]: wlan0: AP-STA-CONNECTED 78:45:61:ee:43:47 Feb 18 16:25:38 iothub1 kernel: [ 1726.789198] ieee80211 phy0: vif 0: set_key cmd 0 Feb 18 16:25:38 iothub1 kernel: [ 1726.789213] ieee80211 phy0: CCMP_PAIRWISE keylen=16! Feb 18 16:25:38 iothub1 dnsmasq-dhcp[902]: DHCPREQUEST(wlan0) 10.42.0.153 78:45:61:ee:43:47 Feb 18 16:25:38 iothub1 dnsmasq-dhcp[902]: DHCPACK(wlan0) 10.42.0.153 78:45:61:ee:43:47 ideapad Feb 18 16:26:07 iothub1 kernel: [ 1755.102706] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD DCE !! Feb 18 16:26:07 iothub1 kernel: [ 1755.109460] sunxi-mmc 1c10000.mmc: data error, sending stop command

Most likely the device does not get enough power check used cable and charger.

from my understanding you can't. unlike in arduino which can run 1wire on any free pin the linux soc's use kernel driver which is tied to a single master. the raspberry version is hack to the kernel driver creating a new 'duplicated' master port.. (haven't personally used it but read the guides)

don't know if you are using the post marked by igor it show nothing on actual routing. perhaps the network manager does it internally adding iptable rows or something similar. hostap itself don't actually do anything for the networking layer other than just give the client ip-address all the interface tied routing is done by normal procedures. at least I don't know any other way to route traffic from one interface to another than iptables rules one thing to test whenever have some extra time...

I am using various DHT sensors. The one in picture indeed does have internal resistor. You can see it when loot at actual circuit board part. I have one running on Raspberry Pi Zero for now about a half of a year using Java JNI to C bridge. The DHT-11 fails quite often on read even with the 5 rereads cycle, the Linux is just too unreliable for the correct input counting. On Arduino like ESP8266 there is no multithreading and the timing is therefore more accurate than on Linux installations. It would be better using 1Wire sensor like DSDB1820 although at least on Raspberry Pi the whole 1Wire buss takes a lot of the CPU power as it always scans for new instances of the sensors.

Just a note, on modern installations you don't ever manually configure the /etc/resolv.conf it is automatically maintained by other services. Plain openvpn installation don't do dns push lines unless you tweak them from the server side, the network manager plugin which is part of the gnome packages does this automatically while restarting whole networking. We have some amazon to datacenter bridges and even my soc installations are connected to datacenter network services by openvpn client. Most of the problems started when ubuntu started using network manager on desktop images but dns push routes took a lot off man hours to get them right. Currenlty I add manually the hostnames and don't rely on dns lookups.