• Content Count

  • Joined

  • Last visited

Everything posted by pfeerick

  1. I think from an update that TL gave a few days ago about progress on identifying the issue that this fixes some of the cases, may not fix all. There may be an issue of either poor soldering or faulty PHY chips in the mix as well - but it seems like they are starting to identify all the different factors that trigger those similar symptoms. I know that for at least one person fiddling with the TX and RX registers in the PHY had no effect for them... so this fix won't help them. I may be wrong, but I think that the Android 5.1.1 just got a similar fix, and at least one report indicated that
  2. Don't you mean the news that had been previously broken by you a month or five earlier, and had been promptly ignored and ridiculed? :-O What can I say... things take a while in pine64 land? :-D You'll be unsurprised to hear that the Ethernet problem with that other user was indeed masked by the PoE adapter... so he seems to have that curse-ed GbE gremlin.
  3. Does this help? (Questo aiuto?)
  4. lol... sound about right... another file management tool I use does exactly the same thing... uses multiple I/O threads, and also uses larger buffers for certain transfers (i.e. drive to drive, or via network IIRC). I'll throw that in just for fun... and also the reverse direction file copy... the 1gb of zeros TO the pine64 this time... looks like the brtfs is pretty happy to compress that puppy down as it goes... so happy in fact that I don't see the USB lighting up much during the transfer :-) So it will be interesting to see what happens once the dual USB opens up. I will say that after tra
  5. Indeed... if we were always transferring zero byte files... I'd be very worried that we have nothing better to do with our time This what you wanted?
  6. So, I know it isn't comparing apples with apples, but I just have to post this as it shows the GbE on the pine64 can indeed move when it wants too... I finally reformatted my USB flash drive as btrfs, and made a zeroed 1G file as you suggested earlier (with compression on). I'd started armbian up again a youtube upload for tonight, so thought I'd make that file first,and then see what the transfer speed was like. I'm copying to the same desktop computer as before, but it's booted in to windows (I know, you won't like it) this time (dual-boot), and it was... fast... damn near missed gettin
  7. lol... I don't disagree with your emphasis... but notice I didn't mention the crappy connector at all (for that exact reason)... as it doesn't matter if you have a 2A 5v PSU or a 200A 5v PSU... you can't avoid the voltage sag on the cable or connector, but then you get hit with connector loss/resistance. And since the 5v 5A PSUs I had in mind are deliberately tweaked by the supplier (Adafruit) to start at 5.25v, and sag down to 4.9-5.0 at 5A, they don't follow the usual rules... but then again... even the cheapie I bought the other day for another project sat at 5.03v when I load tested it at
  8. Just on the PSU more than 2A - the only caveat I would add to that point is that with a power supply capable of say 5A as opposed to 2A, the PSU itself probably won't start to drop it's voltage below 5v on Pine64-ish loads, so may be one less source of voltage drop. Having said that, from the various USB leads I've tried over the years, that is still the sole biggest contributor, followed closely by the connector used. And the lack of test points would also explain why this may turn out to be the product of a hardware / construction issue, as they don't have the test points to be able to
  9. Many thanks for that info tkasier... I'll certainly put that to the test after I've done the others, as it will be interesting to seek how much more I can elk out of the board. As things stand, I can at least evidence for newbies that you can't complain about performance if you switch over to a sanely configured distro... (shameless Armbian plug)... it will improve significantly. And this is the out of the box experience, so it ain't rocket science! So, next thing too do is to push it to the max... and see if we can get this puppy purring like a kitten... or some spontaneous combustion pe
  10. I'm sorry... I have stop you there... I'm having trouble not bursting out laughing... nope... I did... you've just summed up what I've been shaking my head over for past few months... lol... settings matter, ignorance hurts... so true... so true... ok, that makes sense... I'd gathered from what you'd said before that cqufreq played a big part here (which is understandable in the world of ARM, since its all on the one chip, rather than across different chips like on a x86 platform...). It would be interesting to see what they stuffed up in the debian distro though that still bottlene
  11. Thanks for that tkaiser, I'm glad you're on the same page there That is exactly what I will be doing... I have already uploaded several other videos showing the Pine64 debian distro, both without tuning (~9MB/s both ways) and tuned (~28MB/s up, ~9MB/s down IIRC), but I haven't made them public as I will be re-doing them on the weekend with a webcam on the pine64 board so they can't complain that it's not the Pine64 being tested, and can see how it is set up. Indeed... I don't know enough about the tests that I can do, so if you tell me, I'll run them Am I correct in thinking that iowait
  12. It'll be a day or two before I can do any more tests, but the results of the iozone test across the 64GB flash drive are as follow (after a reformat to exfat as it didn't like the idea of writing 6GB files to fat32... so I'll have to see if that has any impact on anything also now ). This is without any active (fan) cooling... just the heatsinks, and an ambient temperature of 24C. btw, I'm happy to do speed tests pushing the board to the limits, but the goal of videos atm is simply to discredit any claims that the best the board can do is 100Mbit, as made by some people, and also show tha
  13. Hm... thought I posted this before, but must have closed the tab without actually sending.... Anyway, I don't know enough about the Armbian image build process to work out where to shove a PR/issue... so will document the issue here, and pin my ears back Edit: nevermind, found the source of the gremlin, and raised an issue ... feel free to delete this post as it's now sort of redundant. When running legacy Armbian, I ran armbianmonitor in monitor mode (-m), and noticed the temperature was staying abnormally low at 25C. Went digging in the source, and realised that /etc/armbianmonitor/
  14. Perfect timing! I was about to post that I have finally done a test with Armbian, and with a fresh legacy install (after realising some fool had gone and installed vanilla before) + installing samba, my 'scientific' test of copying a 1GB file from a linux desktop with GbE to a USB 3 (I know only USB2 for the pine, but higher speed memory has to help... right?) flash drive in the LOWER usb port... and out of the box... I got 29MB/s up (to pine64) and 24-25MB/s down (from pine64)... so pretty happy with those results... notwithstanding the fact that it should be possible to elk a smidgen more mo
  15. I concur... let the Pain64 bashing... er... smashing... um... using? begin!! In the GbE note, what are some more realistic performance numbers you would expect to see from it. On the debian, with updated longlseep kernel, after running longsleeps optimisation script, I have been able to get 29-30MB/s samba upload to the Pine64, but only 10MB/s down... and someone commented that they had the exact opposite results, when using a USB GbE adapter... so do you think I'll be able to lift the down throughput to nearer the up, or is that getting to about the best we're likely to see fro
  16. And it looks like it got edited twice... as I first saw it just say it was edited, and now it says "edit: moderator: inflammatory commentary was removed from the post, the technical content was left unaltered"... technical content like where to actually find support was left unaltered?