Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

2410 profile views
  1. I was holding it wrong, that was an H5 board. FFS..... raw=1, etc. slow board.
  2. My OPiOnePlus is raw=0, bin=0 (unknown). Am I holding it wrong?
  3. My temp responds very well to added cooling. I placed the boxed SBC next to a small fan and the temperature dropped by 20C. So it may just be a board specific cooling issue. I'll look into adding a heatsink and find a better source of improved airflow. Thanks, megi, and Igor!
  4. 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.
  5. 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
  6. 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.
  7. This should help SSD performance, no? Oww, I want to try this!
  8. 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.
  9. 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.....
  10. 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
  11. I think the question becomes "where does the OpiZ get power? If it's over the micro-USB, then it's looking dangerous.
  12. 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.
  • Create New...