Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 12 Nov 2019, 21:00
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Raspberry Pi Buster Raspup RC
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 5 of 6 [80 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Author Message
Brown Mouse

Joined: 09 Jun 2009
Posts: 536

PostPosted: Sun 13 Oct 2019, 03:47    Post subject:  

01micko wrote:




@Brown Mouse

I am working on getting some rudimentary bluetooth stuff working. That will be in the next release.

With PPM, the find_cat binary is broken. I built a new one and it works and should fix your broken PPM. Pet attached.

Thanks for reports.


Mick

Cheers for the pet which has now fixed the broken PPM.

Been running this on a daily basis on a RPI 3B for 10 hours a day and always with Pmusic radio streamer running and Vivaldi with normally 3 tabs open,which leaves me seeing around 200mb's of 1gb ram spare,according to Htop.

At boot,I'm seeing an under voltage icon and message which isn't causing a problem when running but I think that is attributed to my slightly underpowered although good quality 2.1 amp Samsung power supply and usb cable.

Great work
Back to top
View user's profile Send private message 
Dud

Joined: 04 Jun 2011
Posts: 44

PostPosted: Sun 13 Oct 2019, 14:34    Post subject:  

Thanks 01micko, devx does enable the AppImage to run. I'll let the builder know and suggest he adds a note to help other Raspup users.

Odd thing though: Under Raspbian the AppImage runs much faster, I would have expected it to be about the same speed:
Complex part script on Raspbian renders in 12 minutes, on Raspup the same file takes 30 minutes.

Hold off from the samba problem for a while - I have a Wifi irregularity which might be at the root, I must heave some kit around and do some wired comparisons; I might be pointing you in the wrong direction.

Cheerio,
Back to top
View user's profile Send private message 
Dud

Joined: 04 Jun 2011
Posts: 44

PostPosted: Mon 14 Oct 2019, 13:58    Post subject:
Subject description: Samba and WiFi
 

Hello 01micko, I've narrowed the issue a little - and found another.

All this is on a RPi4B with 4GB ram.

I connected with ethernet to avoid the WiFi problem (below) and tried again to log into samba.

Pnethood can't find any servers on a scan or refresh - when I disabled cifs (a known Pnethood problem) it reported 'smbmount not found'.

Samba shares from Raspup are rock steady - I am able to transfer GB+ sized files when logging in from another machine.

BUT

All this is on a wired connection. WiFi is decidedly flaky..

Raspup using wlan pings the router at anything from 4ms to 30000 ms with 60% - 80% packet loss.
I just ran a new test with the Pi within 2 metres direct line of sight of the router:
The first 24 pings lost 6 packets, the rest all returned together with #1 at 23000ms then each quicker until #24 at 17ms but the next to return, #27, took 5500ms.

Raspbian on the same RPi in the same place loses no packets and pings rarely go over 6ms.

If it might help I could substitute a Pi3 and re-run the tests?

Cheerio,
Back to top
View user's profile Send private message 
Dud

Joined: 04 Jun 2011
Posts: 44

PostPosted: Tue 15 Oct 2019, 09:25    Post subject:
Subject description: More WiFi tests - and boot times.
 

I replaced the Pi4 4GB with a Pi4 1GB and got essentially the same results
then with a Pi3B and although the WiFi was better it was still poor.

All 3 Pi's on Raspup lost over 50% packets,see typical runs below.

This explains the success only with FTP which is designed to be very fault tolerant.

All 3 Pi's on Raspbian Buster pinged 4-5ms with near 100% returns.
The Pi3B (others not tested) on Raspbian Stretch returned 100% with average times at 1.8ms

The difference between Stretch and Buster is a surprise.

Unrelated but I've seen comments above:
Bootup time for 4GB version 1.48, for 1GB 1.03
I assume something is accessing memory at about 15s/GB.
To check; anyone with a 2GB Pi getting 1.18 bootup times?

Hth, Cheerio,
scapp3.png
 Description   Pi3B pings - very poor but just enough to get some response from remote hosts. After this it settled down to about 62% losses.
 Filesize   27.25 KB
 Viewed   651 Time(s)

scapp3.png

scapp4.png
 Description   Pi4 1GB pings - wlan keeps dropping out so this was the best of about 20 tries.
 Filesize   24.3 KB
 Viewed   647 Time(s)

scapp4.png

Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8727
Location: qld

PostPosted: Sat 19 Oct 2019, 18:29    Post subject:  

Hello Dud

Yes there is definitely some networking/wireless problem, although with my 3B+ and my Zero you barely notice it; with browsing, using PPM, ftp, smb and pinging the router the 3 and zero seem 99% rock solid. I can't say the same for the pi 4, however I am posting from it now after connecting from the cli with wpa_cli and do have a very noticeable improvement.

Some stats - warts and all -
Code:
# ifup -a
# wpa_cli -i wlan0 reconfigure
OK
# ifconfig
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:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:624 (624.0 B)  TX bytes:624 (624.0 B)

wlan0     Link encap:Ethernet  HWaddr DC:A6:32:07:07:D4 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:53 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2204 (2.1 KiB)  TX bytes:592 (592.0 B)

# dhcpcd
script_runreason: /lib/dhcpcd/dhcpcd-run-hooks: WEXITSTATUS 1 ##### this one bothers me
script_runreason: /lib/dhcpcd/dhcpcd-run-hooks: WEXITSTATUS 1
DUID 00:01:00:01:25:2b:c1:cb:dc:a6:32:07:07:d4
wlan0: IAID 32:07:07:d4
wlan0: adding address fe80::4430:dc09:ea08:1fed
ipv6_addaddr1: Operation not supported
eth0: waiting for carrier
wlan0: soliciting a DHCP lease
wlan0: soliciting an IPv6 router
ipv6nd_startrs1: Address family not supported by protocol
wlan0: offered 10.1.1.185 from 10.1.1.1
wlan0: probing address 10.1.1.185/24
wlan0: leased 10.1.1.185 for 86400 seconds
wlan0: adding route to 10.1.1.0/24
wlan0: adding default route via 10.1.1.1
script_runreason: /lib/dhcpcd/dhcpcd-run-hooks: WEXITSTATUS 1
forked to background, child pid 8125
# ifconfig
eth0      Link encap:Ethernet  HWaddr DC:A6:32:07:07:D3 
          UP BROADCAST MULTICAST  MTU:1500  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 B)  TX bytes:0 (0.0 B)

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:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:624 (624.0 B)  TX bytes:624 (624.0 B)

wlan0     Link encap:Ethernet  HWaddr DC:A6:32:07:07:D4 
          inet addr:10.1.1.185  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:81 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3760 (3.6 KiB)  TX bytes:1835 (1.7 KiB)

# ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1): 56 data bytes
64 bytes from 10.1.1.1: seq=2 ttl=64 time=2.643 ms
64 bytes from 10.1.1.1: seq=3 ttl=64 time=3.214 ms
64 bytes from 10.1.1.1: seq=6 ttl=64 time=8.421 ms
64 bytes from 10.1.1.1: seq=8 ttl=64 time=4.395 ms
64 bytes from 10.1.1.1: seq=9 ttl=64 time=4.565 ms
64 bytes from 10.1.1.1: seq=10 ttl=64 time=3.426 ms
64 bytes from 10.1.1.1: seq=11 ttl=64 time=3.345 ms
64 bytes from 10.1.1.1: seq=12 ttl=64 time=2.696 ms
64 bytes from 10.1.1.1: seq=13 ttl=64 time=2.882 ms
64 bytes from 10.1.1.1: seq=14 ttl=64 time=3.562 ms
64 bytes from 10.1.1.1: seq=15 ttl=64 time=3.491 ms
^C
--- 10.1.1.1 ping statistics ---
16 packets transmitted, 11 packets received, 31% packet loss
round-trip min/avg/max = 2.643/3.876/8.421 ms
# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr DC:A6:32:07:07:D4 
          inet addr:10.1.1.185  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8195 (8.0 KiB)  TX bytes:4127 (4.0 KiB)

# ping -c10 10.1.1.1
PING 10.1.1.1 (10.1.1.1): 56 data bytes
64 bytes from 10.1.1.1: seq=0 ttl=64 time=5.335 ms
64 bytes from 10.1.1.1: seq=1 ttl=64 time=57.148 ms
64 bytes from 10.1.1.1: seq=2 ttl=64 time=5.940 ms
64 bytes from 10.1.1.1: seq=3 ttl=64 time=7.157 ms
64 bytes from 10.1.1.1: seq=4 ttl=64 time=3.503 ms
64 bytes from 10.1.1.1: seq=5 ttl=64 time=2.103 ms
64 bytes from 10.1.1.1: seq=6 ttl=64 time=2.158 ms
64 bytes from 10.1.1.1: seq=7 ttl=64 time=2.063 ms
64 bytes from 10.1.1.1: seq=8 ttl=64 time=2.339 ms
64 bytes from 10.1.1.1: seq=9 ttl=64 time=2.665 ms

--- 10.1.1.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 2.063/9.041/57.148 ms
# ping -c10 10.1.1.254
PING 10.1.1.254 (10.1.1.254): 56 data bytes
64 bytes from 10.1.1.254: seq=0 ttl=64 time=43.126 ms
64 bytes from 10.1.1.254: seq=1 ttl=64 time=9.193 ms
64 bytes from 10.1.1.254: seq=2 ttl=64 time=6.174 ms
64 bytes from 10.1.1.254: seq=3 ttl=64 time=13.204 ms
64 bytes from 10.1.1.254: seq=4 ttl=64 time=12.096 ms
64 bytes from 10.1.1.254: seq=5 ttl=64 time=7.382 ms
64 bytes from 10.1.1.254: seq=6 ttl=64 time=7.307 ms
64 bytes from 10.1.1.254: seq=7 ttl=64 time=6.506 ms
64 bytes from 10.1.1.254: seq=8 ttl=64 time=7.541 ms
64 bytes from 10.1.1.254: seq=9 ttl=64 time=5.739 ms

--- 10.1.1.254 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 5.739/11.826/43.126 ms


Puppy uses busybox ping and as you see it is much more reliable limiting the pings to 10 ( -c10 option) - 100% packets get returned.

I think the big network managers, frisbee and SNS are too complex for the pi so I may write a very simple ncurses version (so it will work in console mode too). Of course it won't have all the features but should reconnect automatically if dhcpcd is running as a service.

Part of the problem too I think is that many of the hook scripts in /lib/dhcpcd/ are systemd agnostic which of course puppy doesn't use. I'll try to find replacements (slackware will be a good place to look).

Cheers!

_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
Dud

Joined: 04 Jun 2011
Posts: 44

PostPosted: Sat 19 Oct 2019, 19:50    Post subject:
Subject description: WiFi
 

Hello Micko,

As is Raspup WiFi is sufficiently responsive for *just* long enough that a cursory test looks OK but longer transfers fail.

Your short-burst test and the intermittent, grouped, response to my longer ones makes me wonder:

Is there something else taking up resources and only releasing every few seconds so the Pi's attention is diverted much of the time?
OR
Is one, occasionally used call failing with a timeout that causes the batching?

'though the difference between Raspbian Stretch and Buster suggests there may be something else involved too.

Quote:
Part of the problem too I think is that many of the hook scripts in /lib/dhcpcd/ are systemd agnostic which of course puppy doesn't use. I'll try to find replacements (slackware will be a good place to look).


That it works at all suggests very few of those calls are going astray - a couple of small patches might be enough.

Thanks for all the good work - the Pi4 is so close to being a viable desktop replacement and a good Puppy might just tip the balance.

Cheerio,
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8727
Location: qld

PostPosted: Sun 20 Oct 2019, 01:20    Post subject:
Subject description: WiFi
 

Dud wrote:
Hello Micko,

As is Raspup WiFi is sufficiently responsive for *just* long enough that a cursory test looks OK but longer transfers fail.

Your short-burst test and the intermittent, grouped, response to my longer ones makes me wonder:

Is there something else taking up resources and only releasing every few seconds so the Pi's attention is diverted much of the time?
OR
Is one, occasionally used call failing with a timeout that causes the batching?

'though the difference between Raspbian Stretch and Buster suggests there may be something else involved too.

Quote:
Part of the problem too I think is that many of the hook scripts in /lib/dhcpcd/ are systemd agnostic which of course puppy doesn't use. I'll try to find replacements (slackware will be a good place to look).


That it works at all suggests very few of those calls are going astray - a couple of small patches might be enough.

Thanks for all the good work - the Pi4 is so close to being a viable desktop replacement and a good Puppy might just tip the balance.

Cheerio,


We'll see...

My wireless is still up, from the original test.

I've logged into the samba share on my laptop downstairs; it's right near the router but the pi 4 signal has to get around a couple of walls and the floor. I'm currently copying a slackware-live-plasma5 iso image, 4.4 GB, over smb (cli - rox tends to bog down, not just a pi issue there). I prefixed the command with time so I should get a rough idea of the time it takes - bearing in mind that smb is quite a bit slower than ftp.

After that I might download a hefty iso from the internet with wget to see how that fares, but it certainly seems that my connection is more stable using the commandline.

Cheers

------------------

Later ... Shocked

Code:
# mount.cifs //10.1.1.222/puppyshare ./sam -o user=root,pass=woofwoof -v
mount.cifs kernel mount options: ip=10.1.1.222,unc=\\10.1.1.222\puppyshare,user=root,pass=********
# pwd
/mnt/mmcblk0p2
# cd sam
# ls ..
lost+found  raspupsave-piZero  sam
# time cp slackware64-live-plasma5-current.iso ../

real   186m52.222s
user   0m0.121s
sys   0m46.115s


Yup, 3 hours for ~4.4GB over smb. For comparison ftp took ~14 mins for a 300MB iso. However, to be fair, my desktop was about the same with the same iso and the same server under the same conditions on my network - wifey watching netflix and grandson playing youtube. Rolling Eyes

Still no dropouts though (and still running from RAM - about to make a save and use my cli method at boot).

_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
Dud

Joined: 04 Jun 2011
Posts: 44

PostPosted: Sun 20 Oct 2019, 09:52    Post subject:
Subject description: WiFi - interaction with screen resolution..?
 

Please can someone with different screens available and a Pi4 confirm this:

All my tests upthread were done at 1920x1080 screen resolution.

Today I tried 1366x768 resolution, and while at that setting retried pinging the router.

...and got an improvement.

It's still very ropy but wlan was easier to get going and didn't drop out. Pings were still slow and intermittent but packet loss was only 35% on 1026 tries.

And I traced a pattern in the pings:

Returns paused for 25 - 30 seconds then most of the delayed pings returned in a burst before pausing again. The fastest pings in each group were under 100ms but the slowest were always around 26000ms

When I went back to the higher resolution performance was as before.

* * *

Hello Micko,

Have you seen:

https://blog.jlu5.com/blog/2018/07/debian-buster-on-a-raspberry-pi-3-model-b-plus/

- some of the comments might be useful too.

Hth Cheerio,
Back to top
View user's profile Send private message 
Brown Mouse

Joined: 09 Jun 2009
Posts: 536

PostPosted: Fri 25 Oct 2019, 16:15    Post subject:  

Five days + uptime on a Raspberry PI 3b and no problems for this little gem Very Happy
AFA4E6FA-5911-4D35-AB81-682453C98255.jpeg
Description 
jpeg

 Download 
Filename  AFA4E6FA-5911-4D35-AB81-682453C98255.jpeg 
Filesize  161.37 KB 
Downloaded  41 Time(s) 
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8727
Location: qld

PostPosted: Sat 26 Oct 2019, 22:53    Post subject:  

Brown Mouse wrote:
Five days + uptime on a Raspberry PI 3b and no problems for this little gem Very Happy


Code:
# uptime
 12:46:52 up 25 days, 19:31,  0 users,  load average: 0.98, 0.98, 0.62


Shocked

Well it's been asleep most of the time but I'm posting from it now from a firefox sfs (coming soon in the next raspup iteration)

I've mostly been working on a simple cli based wireless network manager which will also be in the next version.

I haven't yet had time for bluetooth, and don't have any hardware but that may change soon.
uptime.jpg
 Description   Yep, 25 days on 3b+
 Filesize   61.31 KB
 Viewed   295 Time(s)

uptime.jpg


_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
01micko


Joined: 11 Oct 2008
Posts: 8727
Location: qld

PostPosted: Sun 27 Oct 2019, 01:08    Post subject:
Subject description: WiFi - interaction with screen resolution..?
 

Dud wrote:
Please can someone with different screens available and a Pi4 confirm this:

All my tests upthread were done at 1920x1080 screen resolution.

Today I tried 1366x768 resolution, and while at that setting retried pinging the router.

...and got an improvement.

It's still very ropy but wlan was easier to get going and didn't drop out. Pings were still slow and intermittent but packet loss was only 35% on 1026 tries.

And I traced a pattern in the pings:

Returns paused for 25 - 30 seconds then most of the delayed pings returned in a burst before pausing again. The fastest pings in each group were under 100ms but the slowest were always around 26000ms

When I went back to the higher resolution performance was as before.

* * *

Hello Micko,

Have you seen:

https://blog.jlu5.com/blog/2018/07/debian-buster-on-a-raspberry-pi-3-model-b-plus/

- some of the comments might be useful too.

Hth Cheerio,


Hi Dud,

While I didn't test with a high res on with my pi4 I did test pinging with my new CLI network manager (TBA). I'll attach a screeny and a log of pinging the router, bearing in mind the signal from my pi needs to travel between/around a wall and a floor over ~10 metres ATCF (as the crow flies).

The results are somewhat baffling as to why they are so good when I did experience problems before - only 10 packets dropped out of 1024.

Cheers!
ping-test.png
 Description   end result with screen res and pi version
 Filesize   55.46 KB
 Viewed   280 Time(s)

ping-test.png

ping.log.gz
Description  gunzip ping.log.gz # command to open
gz

 Download 
Filename  ping.log.gz 
Filesize  5.72 KB 
Downloaded  14 Time(s) 

_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
spotted

Joined: 25 Jan 2018
Posts: 38

PostPosted: Sun 27 Oct 2019, 12:38    Post subject:  

Wish list for what ever Raspuppy is next.
Minor gripes only, it is almost usable as Fatdog
opps, not allowed to mention fatdog
Cut and paste in and out of the terminal
Highlight and paste from a web page. I have to highlight the text in a web page then go to glipper and highlight again before I can paste into URL bar, but this dont work double clicking into the terminal.
CPU meter that bobs up and down in real time like in
errr, dont go there
Actually after 13 years of using puppy I am not so sure that cpu meter next to the time is a cpu meter, some times when it gets them lines across it might be a ram meter. Anyhow it shows what was happening yesterday, and needs to be errr self censored
If anyone knows how to take 'system monitor' from Mate desktop and put it into the tray can you do a howto. It can monitor the cpu and the internet speed, separate graph for each in real time.

Anyone found a video downloader for valaldi?
Or a gui for youtube-dl
You2pup dont work for me.
Forget firefox, your never going to fix it, people on the odroid forum that have sent a bug to mozilla say they aint interested in 'arm'

To play videos in full screen
If you have quirky xerus 814 handy
Nick 'Simplevp' and two depends, wmctrl, popup.
Works using ffmpeg, could not toggle it to work using omxplayer or vlc. its simple but it works
'ldd' for vlc says all depends are there but cant get it to run as stand alone either.
Back to top
View user's profile Send private message 
spotted

Joined: 25 Jan 2018
Posts: 38

PostPosted: Sat 02 Nov 2019, 07:34    Post subject:  

Just mucking around with Simplevc from Quirky, good luck trying to toggle vlc and omxplayer to work.

# vlc
VLC media player 2.2.4 Weatherwax (revision 2.2.3-37-g888b7e89)
vlc: unknown option or missing mandatory argument `--dbus'

# omxplayer
/usr/bin/omxplayer.bin: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libavcodec-ffmpeg.so.56: undefined symbol: x264_bit_depth
#

So also tried vlc-gtk as a GUI
# vlc-gtk
BusyBox v1.31.0 (2019-08-05 23:31:11 +0Cool multi-call binary.

Usage: which [COMMAND]...

Locate a COMMAND
# command: search
command: search
sort: cannot read: /tmp/vlc-gtk-playlist_root1: No such file or director

Anyone been able to trim a SSD connected to a pi 4, boot from micro sd card and throw to the SSD. When doing a 'save' it takes forever, I have 400 MB.sec SSD. A lot of pausing of the HD light while writing. But fstrim just goes nowhere.

hdparm -I /dev/sda2 | grep "TRIM supported"
* Data Set Management TRIM supported (limit 8 blocks)
# fstrim -V /dev/sda2
fstrim from util-linux 2.33.1

# fstrim -V /
fstrim from util-linux 2.33.1

Read up on hdparm, wiper. still have slow SSD HD

This operation could silently destroy your data. Are you sure (y/N)? y
Allocating temporary file (16498541 KB).. WIPER_TMPFILE.7747: Invalid argument
/dev/sda2: this kernel may not support 'fallocate' on a ext4 filesystem, aborting.
Back to top
View user's profile Send private message 
spotted

Joined: 25 Jan 2018
Posts: 38

PostPosted: Sun 03 Nov 2019, 11:15    Post subject:  

See Olle, I said Micko is working on it, errr well, working on working on it.
Not long to wait. Take a break Micko, do it after the holidays, and make it easier on your self, do a minimal.
Rox
firewall
vivaldi
unfortunately full networking plus usb tether so everybody can go online
alsa and mixer
package manager

question apps like cups, console, geany, pmount, vlc, htop, gparted. hardinfo, pfind, could they be obtained from rasbian or have to be compiled specially for raspuppy because Puppy dont have those sudo and systemd jerks.
Back to top
View user's profile Send private message 
spotted

Joined: 25 Jan 2018
Posts: 38

PostPosted: Sun 03 Nov 2019, 11:17    Post subject:  

Heres how a pi 4 stacks up against a odroid n2.
A n2 has 4 A73 cores plus 2 A53 cores. With the A73 cores everything is bigger and better than the A72. Cant get the A73 cores past 1900.
My pi4 is at 2000 and set to performance.
cpu drawing higher is better n2=4458 pi4=4265
fpu raytrace lower n2=3.52 pi4=2.14 winner
fpu fft lower n2=2.47 pi4=5.28
zlib higher n2=.40 pi4=.32
n-queens lower n2=8.94 pi4=8.82 winner
fibronacci lower n2=1.57 pi4=1.73
cryptohash higher n2=317 pi4=473 winner
blowfish lower n2=3.92 pi4=5.14
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 5 of 6 [80 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0885s ][ Queries: 13 (0.0189s) ][ GZIP on ]