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.

The current mainline kernel has the same problem with orange pi pc plus. Legacy image works but mainline don't. On mainline the wireless don't work even on client the initialization just fails. Tried my own build and the image provided, on a working installation the command what it is trying is to set the ap mode...

Generally speaking linux boot will not slow down from any number of application installations. The core operation system is already running and the apps are started only after the os is already running. What does slow down is network errors, forced filesystem checks or maltunction on device layer. Just check the boot cycle from console to spot errors. Kernel modules do eat memory space but we are not talking here about 3party application gadgets. Example network manager will try to use dhcp even when the lan cable is not even connected... Run a apt-get clean to remove the package cache or if it does not help remove them manually. If you do not like to see the packages cut the available repositories from use but however upgrading becomes harder

don't understand your usecase are you trying to do some kind of repeater ? change the client connection to lan and recheck the speeds if the transfer speed is slow it usually always means that the client connection is too weak. any 20-30EUR wlan router will always outperform just by using pure antenna power

unless you have serial console cable (usb) there is really nothing to do. or you could try older version

It depends how the software is being installed. If example you use distributions own apt repositories it does not really matter. Ubuntu packages are updated a bit slower and sometimes have strange configuration but overal there is little difference. Personally I use ubuntu as I have more experience on it and use it on work. There has been big changes like systemctl management, network manager and unattended upgrades so things have evolved. I would use the ubuntu unless there is some reason example out dated version of packages or something similar. Using virtualmachines is so easy today so its easy to develop the non hardware depended parts before hand with fast deployment and debugging procedures.

Ubuntu xenial is a lot more stable use it instead. I have had several devices where after the upgrade the device fails to boot no more. Downloaded a new image an worked again (I think it was orange pi pc plus debian last time...).

I did some tests yesterday the mainline kernel hostap with ESP8266 client. Sadly it seems that the wireless is totally unreliable at least on the AP mode. Sometimes the client can't even connect to the AP network as the kernel spams the error messages. I don't know why generic laptops or mobile devices work better perhaps they have better network stack coding or have more powerfull antennas as they do not seems to have trouble getting the actual connection but fail on traffic use sometimes Only thing that seems to help is to restart the hostAP processes but as there is not really an option I am dropping Orange Pi Zero from my potential test devices. Perhaps it can be used as client machine with lan-connection but its not my initial goal...

frontpanel connectors are usually behind long cables and connected to the motherboards "external usb" connector headers. backpanel connectors are soldered to the motherboard and overall very reliable. example when doing new os installations to baremetal sometimes the frontpanel connectors just don't seems to be detected fast enough for the boot process to work if you use mouse or keyboard on the frontpanel those are detected very late on the boot cycle so there a bit lag does not matter the usb key's are not that reliable either they need to formatted from time to time other way they just slow down to non existing speeds

There is no really "wrong" with usb power. Even Arduinos can run on USB power. Problem is that USB spec itself don't enforce the amp output for higher numbers (which these boards would require). Meaning that cheap USB cables/connectors don't need to support example more than 1.0a witch is not really enough for power hungry devices. Example USB-C is more than enough if it ever gets to the soc - scene. I once connected by mistake a 0.5a usb cable to 2.4A power source and yes wires started to heat up and the power source itself started to give error blinking

Yes wifi direct is not an ap point. cameras, printers and most screen casting devices use wifi direct. i do not have any experience how it can be used from linux or computers overall.