willmore

Members
  • Content Count

    94
  • Joined

  • Last visited

About willmore

  • Rank
    Advanced Member

Recent Profile Visitors

820 profile views
  1. Here you go, sir. armbianmonitor -u output
  2. I have an Orange Pi One Plus with the H6 chip in it and I'm quite happy with how well it's supported by Armbian. I haven't really had any problems with it. I do have one question, though. I'm using armbianmonitor to "-m" monitor the machine and I notice that the temps are always pretty hot. Even at idle (480MHz) it still shows 72C. That seems higher than I would have expected. Is this normal, expected behavior? I understand that the SoC thermal monitoring code in the kernel is pretty new and therefore might not be perfect, yet. So, I thought I'd ask. Because it may just be my board that's off. Does anyone know if this is normal? Info: The board is in a lightly vented case and there is no HS on the SoC. There is light cross airflow in the area. Armbian version is "Welcome to Debian Buster with Armbian Linux 5.3.0-sunxi64" with current software updates. If there is more information I can provide, I would be glad to report it. Thank you for your time.
  3. 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
  4. 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.
  5. This should help SSD performance, no? Oww, I want to try this!
  6. 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.
  7. 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.....
  8. 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
  9. I think the question becomes "where does the OpiZ get power? If it's over the micro-USB, then it's looking dangerous.
  10. 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.
  11. 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.