• Content Count

  • Joined

  • Last visited

About willmore

  • Rank
    Advanced Member

Recent Profile Visitors

651 profile views
  1. willmore

    Armbian for Amlogic S912

    Data for the Odroid-C2 for 2 threads to fill out the table @tkaiser. 100: execution time (avg/stddev): 196.7230/0.01 250: execution time (avg/stddev): 76.9758/0.01 500: execution time (avg/stddev): 37.5997/0.00 1000: execution time (avg/stddev): 18.3120/0.00 1296: execution time (avg/stddev): 14.3056/0.00 1536: execution time (avg/stddev): 12.0588/0.00 1656: execution time (avg/stddev): 11.1768/0.00 1680: execution time (avg/stddev): 11.0148/0.00 1752: execution time (avg/stddev): 10.5501/0.00
  2. willmore

    Orange Pi Zero Plus / H5 Chip

    As a user and not a dev, I'd like to add that I'd much prefer that a distro be stable than faster-and-unstable. For an experienced user, I know I can fiddle with these values and characterize the abilities of *my* particular boards if I want to take the time. For an unexperienced user, an increased chance--howerver small--of the software making my hardware unstable is unacceptable as I'm likely already chasing a bunch of problems of my own creation--the aforementioned SD and power problems being primary amongst them. That's my long way of saying, please choose 624.
  3. willmore

    Orange Pi Zero Plus / H5 Chip

    PC2: http://sprunge.us/jVAH
  4. This should help SSD performance, no? Oww, I want to try this!
  5. willmore

    Some basic benchmarks for Le Potato?

    Back when the clock speed cheating was first detected, I had been doing just the kind of bencharking that detected it. I approached a vendor in the area with my results--looking to find out why there was a performance plateau at 1.5GHz. That was one of the things that triggered the investigation into the issue which lead to revelation that the firmware was lying. There's some data there that might be of interest historically. Nothing that matters to this thread, really. The method that you've shown in this thread is similar to what I was doing back then and I'm confident that you can detect cheating with this.
  6. willmore

    Some basic benchmarks for Le Potato?

    Ahh, yes, for a clock speed surrogate, you'd want exactly a task like that--something that doesn't stress the CPU too much that power and thermal issues com into play. You'd also want to avoid anything with alot of memory usage as that will be inelastic with CPU speed. Yeah, the clock speed issue for the S905. I remember that well. Maybe some day I can release the info I have on how that was detected.....
  7. willmore

    Some basic benchmarks for Le Potato?

    Someone said my name? Sorry it took me a while to run this, but they offer a 100MHz clock speed and that takes a very long time to run--especially with one thread. I have a high degree of confidence that there is no throttling as IIRC, I tested this setup with cpuburn and got no throttling. I can't imagine this being more demanding than that! Here's the data: num-threads=4 100: execution time (avg/stddev): 99.4764/0.02 250: execution time (avg/stddev): 37.7647/0.01 500: execution time (avg/stddev): 18.6581/0.00 1000: execution time (avg/stddev): 9.2395/0.00 1296: execution time (avg/stddev): 7.1300/0.00 1536: execution time (avg/stddev): 6.0117/0.00 1656: execution time (avg/stddev): 5.5794/0.01 1680: execution time (avg/stddev): 5.4853/0.00 1752: execution time (avg/stddev): 5.2694/0.01 num-threads=1 100: execution time (avg/stddev): 369.1851/0.00 250: execution time (avg/stddev): 146.8992/0.00 500: execution time (avg/stddev): 73.3360/0.00 1000: execution time (avg/stddev): 36.6221/0.00 1296: execution time (avg/stddev): 28.2551/0.00 1536: execution time (avg/stddev): 24.4123/0.00 1656: execution time (avg/stddev): 22.0989/0.00 1680: execution time (avg/stddev): 21.7828/0.00 1752: execution time (avg/stddev): 21.3559/0.00
  8. willmore

    Details with OPIZ2+ H5

    I think the question becomes "where does the OpiZ get power? If it's over the micro-USB, then it's looking dangerous.
  9. The decision to remove BogoMIPS measurements in ARM was made a decade or so ago. It was made in the open on the linux arm mailing list. You're welcome to search the archives and reread the discussion. If you take issue with any of it, you are free to try to reopen the issue. I would suggest that such a pursuit will not be productive. In the context of Armbian, read the forum here, read the appropriate linxu-* mailing list, and join the IRC channel. All of these decisions are discussed there. Are they distilled into some convenient Wifi? No, but anyone is free to read all of these sources and edit the relevant wiki.
  10. From a 3.14.29 kernel: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000) ARM doesn't use a busy wait loop, so the BogoMIPS calculation was abandoned a very long time ago. The value you see now is only a placeholder for old scripts and programs that expect to find it for whatever their reasons.
  11. That's always been the case, hasn't it?
  12. There is the Odroid XU4. There are probably others.
  13. Thanks for pulling in the fix. I'm glad I could help even if it's just me stumbling in the dark and running into things.
  14. Okay, I put the changes back in and rebooted. It works just fine. I haven't verified functionality of SPI, though. Kernel log says: [ 9.546118] spidev spi0.0: probing from DT So, it looks like it's working. Need to me do anything else?