home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   RBERRYPI      Support for the Raspberry Pi device      21,939 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 20,951 of 21,939   
   Pancho to Theo   
   Re: Pi5 M.2 HAT   
   31 Oct 24 10:02:34   
   
   INTL 3:770/1 3:770/3   
   REPLYADDR Pancho.Jones@proton.me   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  f040b2e3   
   REPLY:  af1f8460   
   PID: SoupGate-Win32 v1.05   
   On 10/30/24 23:14, Theo wrote:   
   > Pancho  wrote:   
   >> On 10/30/24 08:50, Andy Burns wrote:   
   >>> Pancho wrote:   
   >>>   
   >>>> The official NVMe Pi Hat has been out for months,   
   >>>   
   >>> Oh, I don't have a Pi5, and though I kept hearing about 3rd party NVMe   
   >>> HATs and lack of official one   
   >>>   
   >>   
   >> OK, I see there is a story about rPi launching actual NVMe M.2 SSDs. As   
   >> opposed to a hat. I've no idea why they would do that. The obvious   
   >> suspicion is cashing in on a brand name.   
   >>   
   >>    
   >   
   > It may be they are doing it because supply of small-capacity 2230 NVMe is a   
   > bit of a minefield.  eg I checked scan.co.uk and the smallest 2230 they have   
   > is 512GB.  There are some 256GB sold by Amazon.co.uk which are more   
   > expensive (and a few more dispatched by other sellers, of variable   
   > trustworthiness).  At least with the RPi brand you know they're compatible,   
   > and they seem to be decent value.   
   >   
      
   I have three 2242 NVMe, they work fine, apart from some versions of   
   U-Boot boot loader (They actually worked in older versions, then stopped   
   working). A couple of those are 256GB from a couple of years ago, due to   
   the price low differential I would buy 512GB now.   
      
   I'm thinking of getting a M.2 NVMe adapter for my rPI5, I'll probably   
   get a Pimoroni one, because it take standard 2280 drives. Best to go   
   with the flow.   
      
      
   >> It's hard to know what is going on with the Raspberry Pi guys, the   
   >> RK3588 devices are clearly faster, lower energy, albeit with shit   
   >> software support. Who knows what will happen with the next generation   
   >> Arm SoCs. I guess maybe Raspberry Pi have a clue, and hence decided to   
   >> monetise the brand now, before a new product wipes the floor with them.   
   >   
   > It'll depend on what fab slots they can get.  Not everyone can fab on the   
   > latest process, especially with a budget.  Also how much cache they can   
   > afford to put on the die.   
   >   
   > RK3588: (64+64+512)*4+(32+32+128)*4+3072 = 6400KiB   
   > RPi5  : 512*4+2048 = 4096KiB   
   >   
   > RK3588 also has 4 extra A55 cores which RPi doesn't have, but is more   
   > expensive ($100+ for the Banana Pi).   
   >   
      
   It's only costs a little more, but the RK3588 is now two years old. For   
   me it it was the first PC quality Pi type device. I think the next   
   generation of Pi type devices may be genuine mass consumer products. The   
   rPi niche is disappearing,  rPi will either become much bigger or much   
   smaller. Saying others have a manufacturing advantage is supporting the   
   idea rPi might have problems in future.   
      
   FWIW I'm not a traditional Linux/Unix person. When MS Win NT provided a   
   proper OS, I dropped Unix and was a MS Fanboi for 25 years. I looked at   
   Linux occasionally, but not seriously. Now I think Arm/Linux is about to   
   become a serious mass market desktop PC.   
      
   MS seem to be a little nervous too.   
      
      
   >>>> I guess I should get one, or maybe an alternative. I just bought a   
   >>>> NVMe USB enclosure which has appalling performance   
   >>>   
   >>> Anyway, is it likely the write speeds are faster than theĀ  read speeds?   
   >>> I know some enterprise SSDs come in "read mostly" or "write mostly"   
   >>> flavours, but for a Pi?   
   >   
   >> Dunno, IOPS doesn't mean a lot to me. As TNP says, maybe a write   
   >> operation is to cache, and a read is from main memory.   
   >>   
   >> On many solid state persistence devices you see a very fast initial   
   >> write (presumably to cache) before quickly settling down to a much lower   
   >> rate for big files.   
   >   
   > Any decent benchmarking tool should get past the cache to exercise the real   
   > storage.   
   >   
      
   These are marketing benchmarks, about as reliable as VW diesel vehicle   
   emission tests. i.e. They could do it properly, but they don't want to.   
      
      
   > I think they've got them around the wrong way.  Their ODM Biwin's 2230 has   
   > more read than write IOPS:   
   > https://droix.co.uk/product/biwin-2230/   
   >   
      
   Yeahbut...   
      
      
      
   650K  IOPS Max. Random Read 4K   
   800K  IOPS Max. Random Write 4K   
      
      
   But as I said, I don't really understand what IOPS means. The same   
   device quotes a faster Max Read than Max Write (presumably sustained   
   read/write).   
      
   I'm not saying the Raspberry Pi NVMe spec is right, just that it is good   
   manners to have a bit more evidence before accusing it of being wrong.   
      
      
   > Theo   
      
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 10/0 1 90/1 103/705 105/81 106/201 124/5016 128/187 129/305   
   SEEN-BY: 153/757 7715 218/0 1 601 700 840 870 930 220/70 221/1 6 360   
   SEEN-BY: 226/17 30 100 227/114 229/110 111 114 200 206 300 317 400   
   SEEN-BY: 229/426 428 470 550 616 664 700 240/1120 266/512 267/800   
   SEEN-BY: 282/1038 291/111 292/854 301/1 113 812 310/31 320/219 322/757   
   SEEN-BY: 335/364 341/66 342/200 396/45 460/58 633/280 712/848 770/1   
   SEEN-BY: 770/3 100 330 340 772/210 220 230 5020/400 1042 5075/35   
   PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca