(04-30-2016, 04:31 AM)romangaag Wrote: Test finished without errors.
You can now delete the test files *.h2w or verify them again.
Writing speed: 16.2 MByte/s
Reading speed: 63.4 MByte/s
H2testw v1.4
That looks good but unfortunately these are only (mostly irrelevant) sequential transfer speeds. Way more important is random I/O. While you're at it you could give CrystalDiskMark also a try (just to be sure -- since slow random write performance is equivalent with 'Android/RemixOS experience will pretty much suck'): http://forum.pine64.org/showthread.php?tid=191&page=5
05-02-2016, 12:37 AM
(This post was last modified: 05-02-2016, 12:38 AM by romangaag.)
Hello everyone! I've managed to install "Ubuntu Linux Image base on Longsleep 20160421 image, Pine64".
It looks like system works ok, but... I see Ethernet wired options, BT options and no Wifi options. How to turn wifi module on?
How to check if the system see it?
thnx
(05-02-2016, 12:37 AM)romangaag Wrote: I've managed to install "Ubuntu Linux Image base on Longsleep 20160421 image, Pine64"
Unfortunately this image simply sucks, reasons here: http://forum.pine64.org/showthread.php?t...97#pid7797
And it might help if you don't add such questions to an unrelated thread 
(05-02-2016, 12:53 AM)tkaiser Wrote: And it might help if you don't add such questions to an unrelated thread
Sorry if I use wrong forum thread ) And sorry again if next question also misthread)
Q: what is appropriate read/write speed of SD card for using it with Pine (to use Pine without lags I mean)?
05-02-2016, 01:58 AM
(This post was last modified: 05-02-2016, 02:13 AM by tkaiser.)
(05-02-2016, 01:31 AM)romangaag Wrote: Q: what is appropriate read/write speed of SD card for using it with Pine (to use Pine without lags I mean)?
Sorry? A few posts above I already pointed to the thread in question: http://forum.pine64.org/showthread.php?t...75#pid7675
Look in the other thread, start to understand that sequential transfer speeds are close to irrelevant (this is the so called 'speed class') and that random I/O with small record/block sizes matters. Then look at the results for typical bad brands in the other thread and start to realize that good brands (the more expensive cards from SanDisk, Toshiba and Transcend or the simple dirt cheap Samsung EVO/EVO+) are magnitudes faster.
The average Kingston card tested over there is 6 times slower than a cheap 32GB EVO and the PNY tested there was over 100 times slower than a cheap 32GB EVO. Even if their speed class ratings were better. Again: Speed class is just plain bullshit when we're talking about computers and not cameras/recorders.
And NEVER forget that all test results you find somewhere on the net are irrelevant for the products you buy. Since results might be outdated/wrong and since you might bought counterfeit cards. Always test yourself directly after purchase. All the tools are free and it just takes you some time to check the whole capacity of the card (H2testw/f3) and also random I/O (CrystalDiskMark)
05-04-2016, 07:50 AM
(This post was last modified: 05-04-2016, 08:05 AM by Brian Beuken.)
Sorry if this has been mentioned already, its a long thread so I may have missed this, I note there are issues with 2Gb and Ethernet so this may well be what I encountered. Though it seems backwards to the advice given!
I had issues booting Debian on a 2Gb machine, it appeared to hang after 17secs of boot..this was strange, I tried burning a copy of remix, it fired up, so felt my board was ok. I then tried again with Debian on a different 16Gb card and it worked......hmmmm odd, since my cards are all valid and work fine.
The only thing different was that I plugged in my Ethernet cable when remix was up....so I tried to boot Debian again on the 8Gb, without the network
Sure enough it seemed to hang at 17secs.........but when I plugged the cable in, it actually responded with a notice the cable had been connected, so clearly it wasn't hanging, 20 secs or so later, it booted to the Debian 8 log in screen
So...I reset again this time with cable in, and it fired up in about 30secs....
Without the cable, it will fire up, but takes 2-3 mins before it boots up, giving the impression of a failure to boot.
Oh, this also seems to be the case with longsleeps basic Ubuntu image, it does go to a login,with a cable attached, I gave up after about 5 mins without
I don't know if this is a common issue, or just my particular board, but I hope this is helpful.
Brian Beuken,
Very old game programmer, teaching very young game programmers, a LOT of bad habits.
Lecturer in Games Programming @ BUas in The Netherlands. Author of The Fundamentals of C/C++ Game Programming. Check out my website www.scratchpadgames.net and feel free to join the forum even if you don't own the book.
(05-04-2016, 07:50 AM)Brian Beuken Wrote: Sorry if this has been mentioned already, its a long thread so I may have missed this, I note there are issues with 2Gb and Ethernet so this may well be what I encountered. Though it seems backwards to the advice given!
I had issues booting Debian on a 2Gb machine, it appeared to hang after 17secs of boot..this was strange, I tried burning a copy of remix, it fired up, so felt my board was ok. I then tried again with Debian on a different 16Gb card and it worked......hmmmm odd, since my cards are all valid and work fine.
The only thing different was that I plugged in my Ethernet cable when remix was up....so I tried to boot Debian again on the 8Gb, without the network
Sure enough it seemed to hang at 17secs.........but when I plugged the cable in, it actually responded with a notice the cable had been connected, so clearly it wasn't hanging, 20 secs or so later, it booted to the Debian 8 log in screen
So...I reset again this time with cable in, and it fired up in about 30secs....
Without the cable, it will fire up, but takes 2-3 mins before it boots up, giving the impression of a failure to boot.
I hope this is helpful. This is not the experience I have had with any of the current linux images, so it is a bit premature to call this a new Ethernet bug. They all boot fine with Ethernet connected with no lags. Is it possible your DHCP server is slow to respond? Especially since each fresh OS install on the Pine generates a new MAC? Maybe you ran out of reservations?
Just a thought.
(05-04-2016, 08:06 AM)rahlquist Wrote: This is not the experience I have had with any of the current linux images, so it is a bit premature to call this a new Ethernet bug.
He prefered to use any of the manipulated/crappy OS images from Pine64 wiki instead of the real one. This has network-manager enabled and also interfaces enabled in /etc/network/interfaces which is simply wrong. As usual: Everything as expected since people are still encouraged to do it wrong.
Apart from that if 'auto' instead of 'allow-hotplug' is used in /etc/network/interfaces then Jessie will need a few minutes until it runs in a timeout when no link can be established. So this boot delay is absolutely normal and people now run into this sort of trouble with Linux since they read about problems with connected Ethernet that apply to 1st boot with Android/RemixOS only.
It's still such an unbelievable mess due to lack of a real quickstart guide, a FAQ that can be called so and proper documentation.
05-04-2016, 08:30 AM
(This post was last modified: 05-04-2016, 02:43 PM by Brian Beuken.)
TK, I also used the longsleep version of ubuntu, you linked to in another post. it also takes many minutes to boot when there is no cable attached.
it takes 30-40 seconds if there is a cable attached.
Both Debian and Ubuntu, are sticking at 17secs waiting for some kind of ethernet contact, which does not come, so it stays waiting until a very long timeout occurs.
I make no claims for it to be a new or old bug, simply a report of my own experience, the speed of my DHCP server is irrelevant, as I point out, it is considerably slower to boot, without a connection!
Btw, there is a valid reason why I deliberately use maker supplied distros, its to do with the project I am working on that tries to emulate as far as possible the experience of a novice getting an SBC up and running as a target machine for code. I'm not a linux coder, and am avoiding learning any, so that I can maintain that novice status and continue with my project.
The old coding fart in me agrees with much of your points TK, but your manner of stating them really is unsettling. Be nice to the noobs!
Brian Beuken,
Very old game programmer, teaching very young game programmers, a LOT of bad habits.
Lecturer in Games Programming @ BUas in The Netherlands. Author of The Fundamentals of C/C++ Game Programming. Check out my website www.scratchpadgames.net and feel free to join the forum even if you don't own the book.
(03-31-2016, 11:15 AM)Andrew2 Wrote: I explained the reason several times in the forums why Android images 'need' Phoenix card (the data partition somewhere inside will be resized to the medium's maximum capacity) and also how the Pine64 folks could deal with: prepare a bunch of dd-able Android images with fixed sizes: 7.5, 15.5, 31.5 and 63.5 GB. Or by expanding the partition on first boot -- that's easy with Linux but maybe not with Android. No idea since I'm not interested in Android at all
It sounds like depending on a Windows host could be easily eliminated. It shouldn't be hard enough to make a shell script that could do the writing of the small image then increase the FS to the needed capacity (or simply make the FS big from the start and loopback mount the partition from the image and rsync the contents from the image to the big FS).
I see you said you're not interested in this, but hasn't anybody tried this yet?
On a related topic, is the format of the Pine64 compatible images documented somewhere? I am thinking of trying other OSes than Linux or Android, so this information would be crucial to be able to do this.
|
