Software to test flash storage

An 2.5 USB HD will use around 2-3 W if powered only by 1 USB port (5V, 500 mA max).

Bye Jack

Reply to
jack4747
Loading thread data ...

Yes. One might consider an SSD in a USB enclosure to have that information. I recently built one for myself, just as a fast portable media. Enclosure from ebay and drive (M.2 2240 size) from a local store.

Price was about the same as a fast USB stick (128 GB) but you get support for TRIM at least. I haven't checked SMART, support really depends on whether the USB controller passes through those commands through to the driver or not.

Physical size is somewhat wider and longer than your typical USB stick. The width causes trouble with tightly grouped USB ports. There might be better enclosures than what I got.

Reply to
Anssi Saari

On a sunny day (04 Oct 2018 20:48:26 GMT) it happened A. Dumas wrote in :

Excuse my ignorance, but what is the difference between that thing and a large USB stick, apart from the marketing hype 'SSD'? You can just mount it in the same way I suppose?

Different controller for random access? But then the filesystem rules? I have been using reiserfs since it existed.

Reply to
Jan Panteltje

Mmhh, I'm not sure that having a SSD is better than a normal mechanical HD, since the bottleneck is the (slow) USB2 connection. Raw throughput (with big files) will be the same, and IOPS...mah...I expect some buffering in the USB driver linux, and in the USB controller on the disk side, so probably the faster access time of the SSD is masked by the USB. I don't know. Someone has done some benchmarks? I dont' have a SSD round to try.

Bye Jack

Reply to
jack4747

On a sunny day (Fri, 5 Oct 2018 05:23:13 +0000 (UTC)) it happened bob prohaska wrote in :

My old 1TB Seagate USB has its own wall-wart marked as 12V 2A, makes 24 W. My new small 'Platinum' 1TB USB disk needs 2 USB ports for power, USB is rated at < 600 mA, so estimate 1A at 5 V is 5 W. The Seagate spins down after a while not use. Not sure about the other one, use it on the TV for movies mainly. The Seagate has all the raspi backups, maybe using USB drives with external supply is safer with raspi.

Reply to
Jan Panteltje

I just picked up a Kingston 120GB SSD to use as a boot drive in my new NAS for a bit under ?30 (it was priced in pounds) from a reliable UK supplier. USB 3 enclosures can be had for well under ?10. A bit cheaper and a lot faster at random I/O than spinning rust. But if you want tiny you pay the price in money or performance.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
The computer obeys and wins.                |    licences available see 
You lose and Bill collects.                 |    http://www.sohara.org/
Reply to
Ahem A Rivet's Shot

I got the Seagate Expansion Portable because it was the cheapest. Last year, so a modern version (maybe older ones draw more power, idk). It only has one usb port, so no (extra) power, and works reliably on a Pi3 (plus or not) with the official 5V 2.5A adapter, even without the "max_usb_current=1" parameter in /boot/config.txt. So the normal max usb2 power of 5 V * 0.5 A = 2.5 W seems to be an upper limit for its peak power draw. It could even be a bit lower, I haven't checked, and I also haven't looked at idle/average use.

Reply to
A. Dumas

That's why I wrote "supposedly" and "ssd-technique." I don't know either, and the Sandisk page has no details :( Quoted speeds indicate that it's probably not "normal" flash, though; or, like you say, it might have a different controller.

Reply to
A. Dumas

On a sunny day (Fri, 5 Oct 2018 11:07:13 +0200) it happened "A. Dumas" wrote in :

Ah, thank you, of course, now it dawns on me: They must have, like modern harddisks, a RAM cache! That would explain the incredible speed, reading from cache. So a ram-chip and memory chip in one housing.

Reply to
Jan Panteltje

Random IO is *way* faster because of zero seek time. It's not the bulk rate that matters for most purposes so much as the random IO.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
The computer obeys and wins.                |    licences available see 
You lose and Bill collects.                 |    http://www.sohara.org/
Reply to
Ahem A Rivet's Shot

Well I dint think so.

Program loading is my bugaboo. Thats pretty sequential

And linux caches reads pretty well

--
"Anyone who believes that the laws of physics are mere social  
conventions is invited to try transgressing those conventions from the  
windows of my apartment. (I live on the twenty-first floor.) " 

Alan Sokal
Reply to
The Natural Philosopher

now

ion

I meant SD sized capacity, rather than physical size!

---druck

Reply to
druck

It does depend on what you do.

Sequential is going to be maxed out by USB2 - random is where an SSD can still max out USB2 but spinning rust can't. SSD always wins noticably on performance.

That being said you may well be surprised - there can be a lot of pulling in of shared library pages when a program loads. I swapped out a hard disc for an SSD recently

Do enough work and you're down to physical read speeds.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
The computer obeys and wins.                |    licences available see 
You lose and Bill collects.                 |    http://www.sohara.org/
Reply to
Ahem A Rivet's Shot

There's a fair amount of random access involved in converting a file name to the disk address of the first data block: ~/project/bin/myprog involves three directory lookups (find 'project' in ~. find 'bin' in myproject, find 'myprog' in bin - and all involve an access to the directory's inode plus reading at least one block in the directory. Followed by finding 'myprog's inode and then reading the first block of the program - thats roughly two random reads per directory and another two to get the first block holding your program. Even then there's no guarantee that a non-trivial program in sequential blocks: that depends on how fragmented the filing system is.

Now, if the program uses dynamically linked libraries (very likely for Java, and big C programs) you go through the same process again for each library that contains support code that the program needs.

Exactly so: on this 'ere 8GB laptop, an i5-cased Lenovo T440, the sort of stuff I do normally has around a 1 Gb of running code (the OS, its services, plus what what I'm doing) and between 1 and 7 GB of file cache. I've just been writing/compiling/testing Java and it is showing 1.2 GB of running code and 1.15 GB of disk cache. The bigger C compiles I do can easily run the cache size up the 7GB, probably due to all the files the linker needs to search.

Just how much speed-up Linux file caching provides is easily found: reboot the system and then do a large compilation twice. Run "make clean; make" twice (or "ant clean;ant" for Java ). The second compile will be faster by a factor of between 2 and 5 because all the files being accessed are already in cache for the second compile, so the disk is only accessed to write the executable back to it.

Of course, you won't see anything like this speed-up on an RPi because it hasn't got the spare RAM for a decent sized cache: my old 512MB Pi1B+ shows about a 2/3 improvement the second time it compiles a modular C application. This involves building a function library and three programs, one of which uses code from the library. The speed-up is noticeable, though you have to be paying attention to see it.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

Almost always cached except for the executable read itself (assuming it?s not an executable that?s been invokved recently).

Also you forgot the runtime linker (also usually cached).

Also almost always cached.

No need to reboot, use /proc/sys/vm/drop_caches.

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

Oh, I didn't mention this as any kind of performance upgrade for a Raspberry Pi. Just an answer to the OP's question about checking the status of his storage via SMART.

Reply to
Anssi Saari

It's understood that "normal" USB hard drives can't be powered directly from the Pi and require a separate power supply. I just started wondering if anybody is making ultra low power mechanical drives that _could_ be powered directly from the Pi's USB port.

A 2.5" drive that drew little enough power to be driven from the Pi might be a viable alternative to flash storage. Is there such a beast? 64G or 128GB would be large enough, 32 GB is slightly too small.

Thanks for reading!

bob prohaska

Reply to
bob prohaska

If "normal" means 3.5", then yeah.

Every modern 2.5" drive, I'm sure. Like I wrote earlier: I use one just so and it works.

Reply to
A. Dumas

I have a 1 TB Toshiba 2.5" portable USB drive connected to a Pi

3B, running all the time (datalogging and bittorrent).

At first I tried to power it with a Y cable from a separate power supply. That failed, somehow the two power supplies fight and fail to regulate properly (back feeding?).

Now it is powered by a Pi 3B's USB port and draws 500 mA. At power up That works fine, but to prevent the low power warnings (yellow lighting bolt) it is essential that the cable between power adaptor and Pi has a very low resistance.

The power cables of most adaptors are too long and too thin to work properly. The buffer capacitors in the Pi are tiny, and can't can't handle short peaks in demand very well.

So I bought short cables with just power leads (no data) and AWG

18 gauge for all my Pi's. These aren't the cheapest, but they work fine.

Search on eBay for:

15cm 0.5FT Micro B USB Fast Quick Charge Cable 2.1A Android SmartPhone 18AWG 30cm 1FT Micro B USB Fast Quick Charge Cable 2.1A Android SmartPhone 18AWG NEW

HTH

--
Regards, 
Kees Nuyt
Reply to
Kees Nuyt

On Mon, 8 Oct 2018 02:49:19 +0000 (UTC), bob prohaska declaimed the following:

I ran a benchmark about two+ years ago which required significant swap space to complete; otherwise the Out-of-Memory monitor would kill it (somewhat strange, since the program was designed to take a failure from malloc() as signal to shut down and report results -- and that part worked on a No-OS embedded system). After killing an SD card, I bought a small 1TB drive.

That drive worked on both the R-Pi3 and a Beaglebone Black.

It has no provision for separate power. USB only.

Seagate Backup Plus Portable (model SRD00F1) 1TB.

I was powering each processor card with a wall-wart supply, not from a computer connection (Beaglebone Black is designed to use either a separate

5V supply, or USB client port -- the USB client port also mounts as a network connection but I preferred to use the standalone Ethernet port)
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.