wtarreau

Members
  • Content Count

    33
  • Joined

  • Last visited

About wtarreau

  • Rank
    Advanced Member

Recent Profile Visitors

280 profile views
  1. wtarreau

    Quick review of NanoPi Fire3

    Hi, So I finally found some time to pick the file form the board, sorry for the delay, was busy on other stuff. I verified the temperature thresholds. First alert is at 113, second at 115 and critical is at 120. The file includes one extra DVFS entry for 1600 MHz at 1.25V. I didn't find any other difference compared to the factory dtb. For those landing here from a search engine without preliminary context, this works for my board and is very likely to fry yours, so don't randomly try this file at all, or don't complain! s5p6818-nanopi3-rev05.1g6-1v25-113deg.dtb
  2. wtarreau

    Quick Review of Rock960 Enterprise Edition AKA Ficus

    Hehe, that doesn't change my opinion of this standard which is only useful to build development boards and nothing looking even remotely like a usable prototype. The small form factor only exposes useless stuff and the large one requires access to both sides, thus imposing an enclosure size. But for development I'm totally fine with the EE form factor as it provides a rich set of connectors and standards in a reasonable size.
  3. wtarreau

    Quick review of NanoPi Fire3

    Confirmed, from memory I just added a line with "1600000 1250000". Mine is ultra-stable even with 8 cores at full speed. It happens to throttle a little bit from time to time because the heat cannot escape easily from the cardboard enclosure, but that's all. From what I remember from the datasheet, the chip is designed to run at 1.6 GHz, that's why I picked this frequency. I also modified the thermal triple points because I don't want the machine to throttle quickly, I seeked the limits on mine and set the points slightly below. I can upload the file later if some want it. It's just that it's possible that my temp limits might cause issues to others so we need to be cautious and I don't want people to randomly download the file without reading the context, then complain about this board's stability when using armbian...
  4. wtarreau

    NanoPi NEO4

    I thought they were two different names for the same upcoming board, with various intermediary designs. But you're right, the NEO4 is even smaller than the M4! So yes that makes sense, it's a single channel RAM. Then I think I'm more interested in the M4. However if they made a complete aluminum enclosure like they recently did with the NEO/NEO2 with the buttons and OLED, it could be very tempting to get one as well for about everything you can do with a machine lying in your computer bag!
  5. wtarreau

    NanoPi NEO4

    I just checked the Wiki and it's clearly written dual-channel for the RAM regardless of the size, so we have 64 bits.
  6. wtarreau

    NanoPi NEO4

    @tkaiser I totally agree with you. I'm checking every morning on their site while drinking my first coffee if it's available or not! While I'm not *that* much impressed by RK3399, it's still a pretty good SoC, and this combined with FE's documentation and thermal design should bring something really nice. I'm just wary of the 32-bit memory, we'll have to see once it's available. I can understand their choice given the small size of the board though.
  7. wtarreau

    Benchmarking CPUs

    What you can do is increase the 2nd argument, it's the number of loops you want to run. At 1000 you can miss some precision. I tend to use 100000 on medium-power boards like nanopis. On the clearfog at 2 GHz, "mhz 3 100000" takes 150ms. This can be much for your use case. It reports 1999 MHz. With 1000 it has a slightly larger variation (1996 to 2000). Well, it's probably OK at 10000. I took bad habits on x86 with intel_pstate taking a while to start. Maybe you should always take a small and a large count in your tests. This would more easily show if there's some automatic frequency adjustment : the larger count would report a significantly higher frequency in this case because part of the loop would run at a higher frequency. Just an idea. Or probably that you should have two distinct tools : "sbc-bench" and "sbc-diag". The former would report measured values over short periods, an the latter would be used with deeper tests to try to figure whats wrong when the first values look suspicious.
  8. Please note that the operating points is usually fed via the DT while the operating frequency is defined by the jumpers on the board. It's very possible that the DT doesn't reference the correct frequencies here. From what I've apparently seen till now, the Armada 38x has limited ability to do frequency scaling, something like full speed or half speed possibly. When I was running mine at 1.6 GHz, I remember seeing only 1600 or 800 being effectively used. I didn't check since I upgraded to 2 GHz (well 1.992 to be precise) but I suspect I'm now doing either 2000 or 1000 and nothing else. Thus if you have a smaller number of operating points it would be possible that they are incorrectly mapped. Just my two cents :-)
  9. wtarreau

    NanoPI M4

    Oh I definitely agree and that's what I was thinking as well in the case an RPi enclosure was used : cover all the bottom with a 1mm thick aluminum plate that will radiate the heat through the plastic over all this surface. After all my cardboard-made npi-fire3 enclosure is not far from this :-) BTW I wasn't aware of the FLIRC case at all.
  10. wtarreau

    Amlogic still cheating with clockspeeds

    Absolutely, and this factor is impacted by current (derived from voltage) and temperature. That's why what matters for stability is to find the proper operation conditions. Overclocking in a place where the ambien temperature can vary by 10 degrees can cause big problems. Same for those who undervolt to reduce heat because signals raise softly and degrade as well, or who use too small a heatsink. That said with nowadays software quality you often face a software bug many more times than hardware bit flips :-)
  11. wtarreau

    NanoPI M4

    It definitely is one, the size and shape leave no doubt about it. I'm also seeing some symmetric lines routed to the GPIO2 connector, maybe it's USB2 that's brought there. Maybe even PCIe (though I doubt PCIe works fine on such large connectors since it requires very low capacitance). I do also appreciate a lot the CPU on the correct side. Those who complain about the inability to use a heatsink in an RPi enclosure are also the ones not planning on using one anyway if it were on the other side Also, very likely the other side will feature the DDR4 chips, and it will still be possible to use a heatsink there to spread most of the heat into the enclosure. But having an aluminum enclosure for such a design would be really great.
  12. wtarreau

    Amlogic still cheating with clockspeeds

    This is exactly why there are people like us who dissect products and push them to their limits so that end users don't have to rely on marketing nor salesmen but on real numbers reliably measured by third party who don't have any interest in cheating. Regarding your point about Tj and lifetime, you're totally right, and in general it's not a problem for people who overclock because if they want to get a bit more speed they won't keep the device for too long once it's obsolete. Look at my build farm made out of MiQi boards (RK3288). The Rockchip kernel by default limits the frequency to 1.6 GHz (thus the Tinker board is likely limited to this as well). But the CPU is designed for 1.8. In the end, with a large enough heat sink and with throttling limits pushed further, it runs perfectly well at 2.0 GHz. For a build farm, this 25% frequency increase directly results in 25% lower build time. Do I care about the shortened lifetime ? Not at all. Even if a board dies, the remaining ones are faster together than all of them at stock frequency. And these boards will be rendered obsolete long before they die. I remember a friend, when I was a kid, telling me about an Intel article explaining that their CPU's lifetime are halved for every 10 degrees Celsius above 80 or so, and based on this I shouldn't overclock my Cyrix 133 MHz CPU to 150. I replied "because you imagine that I expect to keep using that power-hungry Cyrix for 50 years? For me it's more important that my audio processing experimentation can run in real time than protecting my CPU and having to perform them offline". However it's important that we are very clear about the fact that this has to be a choice. You definitely don't want companies to build products that will end up in sensitive domains and expected to run for over a decade using these unsafe limits. On the other hand, the experiments run by a few of us help figuring available margins and optimal heat dissipation, both of which play an important role in long term stability designs.
  13. wtarreau

    Quick review of NanoPi Fire3

    By the way if we start to be numerous to buy the board, it may finally become incentive for someone to design a 3D printed enclosure. I'd prefer a metal one with a thermal pad serving as a heat sink at the same time, but I'd be happy with anything better than cardboard+duct tape...
  14. wtarreau

    Quick review of NanoPi Fire3

    Any "correct" USB power supply delivering more than 1.5A under 5V will work, though you'll have to make you own cable or to solder the wires. But with good quality USB cables, it will also work via the micro-USB port, because the current drawn by this board is not *that* high. I even power mine from a USB3 connector of my laptop which delivers about 1.6A (it's over spec and that's great for this use case). You really need to test. Some reported 1.2A under 5V. It's only 33% higher than the regular USB3 limit (900mA) and may actually work fine with most PCs or chargers due to large enough margins in the design.
  15. wtarreau

    Quick review of NanoPi Fire3

    I'm pretty sure it depends on a number of parameters. Mine starts to throttle at 113 degrees C because I found that it works fine till 120 and I don't want it to throttle for no reason. In your case for a cluster it will be difficult to test all boards and check that they're running fine over time. But it can also be valuable. I seem to remember reading 90 degrees max in the datasheet so that could be a good start but it's very close to the existing limits. I don't know if the stability of your workloads is critical or if you can take the risk to see one board hang once in a while to find the limits. One other important factor to keep in mind is whether you're using the GPU or not. I am not, which is why I can trust the ability to throttle to cool it down. If you are not using it either, you could possibly decide to start with a limit at 105. I'm only concerned by temperatures getting close to the ones causing instability. For most of my hardware, when I focus on performance I don't care if it shortens its life since it will be obsolete before it dies. That's why I searched the limits for my board. You need to keep a bit of margin because it takes some time for the temperature to be reported, then when the board starts to throttle it continues to heat a bit. However at very high temperatures it cools down very quickly. Mine throttles at 113 and it rarely reaches 115. I'm using the stock heat sink, and worse, the whole thing is packed into a cardboard "enclosure" so that it can safely lay in my computer bag. Basically there is no air flow around it, it only adds latency to the temperature raise, and spreads it all around in the cardboard. It's totally horrible, and when I leave it for too long on my desk, the desk gets hot under it :-) For my use cases (mostly network endpoint for development) it doesn't throttle at all. I've run some build tests, and I have enough time to compile for a few minutes before it starts to throttle, but even when it does, it doesn't for too long (it oscillates between 113 and 115 degrees). Oh I know what you're talking about, I also happen to hate fans for the same reason. I've installed a 12cm fan behind my MiQi build farm at work, which is powered by the central board's GPIO when the temperature gets too high. It's a 12V fan running on 5V so it probably rotates at less than 1000 RPM and I almost can't hear it. The one at home has much larger heat sinks and no fan. Small fans are noisy and inefficient, you should really pick a large and slow one for your whole cluster. That's what I'd do if I built one (I'd love to just for fun, it's just that I figured that I have no use case for a NanoPi cluster at the moment!).