causes for this?

[Gene Heskett]

I have a usb-3 to sata adapter with a 60GB ssd attached plugged into one
of the usb-2 ports of a raspi 3b. I just moved a 150 megabyte zip file
containing the 750 megabyte sources for an rt kernel to it, got decent
speed doing the copy.

ssh'd into the pi, I asked mc to uppack it, took several minutes. When mc
finally displayed the root dir of the data in the zip, I set it to the
task of copying it to the ssd. The speed slowly decayed and after
around 700k has been copied, the speed is now just over 112 bytes a
second, with an ETA of nearly 2000 hours. Well into August to complete
at this rate.

Does anyone have a clue where the blockage for data might be? This is
from that drive, to that drive. htop is showing perhaps 1 megabyte of
swap being used. ????????

Thanks everybody.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[David Pottage]

Is it a new SSD that has not been used before? Did you start copying
data shortly after powering it on for the first time?

I saw similar behavior with an SD card a few years ago, and came up with
a theory that when new the SSD controller needs to test all the flash to
build up a bad blocks map, but most this is not done in the factory,
only when the device is powered for the first time.

So when you first plug in a flash device, only a few megabytes are
actually available for writing, and the controller is busy running self
test routines on the rest. Any writes to the untested parts of the flash
get queued behind the testing so will be quite slow. Most users would
not notice an effect, especially with SD cards in digital cameras
because they are powered all the time and only filled gradually.

Of course this is all just a theory with no real evidence to back it up
other than a cynical view of flash drive manufacturers cost cutting, but
as a work around I now make a point of plugging in a new drive and
leaving it to sit powered but not otherwise in use for a few hours
before I start copying large amounts of data.
--
David Pottage

Post by Gene Heskett
I have a usb-3 to sata adapter with a 60GB ssd attached plugged into one
of the usb-2 ports of a raspi 3b. I just moved a 150 megabyte zip file
containing the 750 megabyte sources for an rt kernel to it, got decent
speed doing the copy.
ssh'd into the pi, I asked mc to uppack it, took several minutes. When mc
finally displayed the root dir of the data in the zip, I set it to the
task of copying it to the ssd. The speed slowly decayed and after
around 700k has been copied, the speed is now just over 112 bytes a
second, with an ETA of nearly 2000 hours. Well into August to complete
at this rate.
Does anyone have a clue where the blockage for data might be? This is
from that drive, to that drive. htop is showing perhaps 1 megabyte of
swap being used. ????????
Thanks everybody.
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Alan Corey]

That's a pretty big zip file for mc to deal with, it's considerably slower
than using bare unzip. Other than that IDK.

Sent from my Motorola XT1527

Post by David Pottage
Is it a new SSD that has not been used before? Did you start copying
data shortly after powering it on for the first time?
I saw similar behavior with an SD card a few years ago, and came up with
a theory that when new the SSD controller needs to test all the flash to
build up a bad blocks map, but most this is not done in the factory,
only when the device is powered for the first time.
So when you first plug in a flash device, only a few megabytes are
actually available for writing, and the controller is busy running self
test routines on the rest. Any writes to the untested parts of the flash
get queued behind the testing so will be quite slow. Most users would
not notice an effect, especially with SD cards in digital cameras
because they are powered all the time and only filled gradually.
Of course this is all just a theory with no real evidence to back it up
other than a cynical view of flash drive manufacturers cost cutting, but
as a work around I now make a point of plugging in a new drive and
leaving it to sit powered but not otherwise in use for a few hours
before I start copying large amounts of data.
--
David Pottage

Post by Gene Heskett
I have a usb-3 to sata adapter with a 60GB ssd attached plugged into one
of the usb-2 ports of a raspi 3b. I just moved a 150 megabyte zip file
containing the 750 megabyte sources for an rt kernel to it, got decent
speed doing the copy.
ssh'd into the pi, I asked mc to uppack it, took several minutes. When mc
finally displayed the root dir of the data in the zip, I set it to the
task of copying it to the ssd. The speed slowly decayed and after
around 700k has been copied, the speed is now just over 112 bytes a
second, with an ETA of nearly 2000 hours. Well into August to complete
at this rate.
Does anyone have a clue where the blockage for data might be? This is
from that drive, to that drive. htop is showing perhaps 1 megabyte of
swap being used. ????????
Thanks everybody.
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Gene Heskett]

Post by David Pottage
Is it a new SSD that has not been used before? Did you start copying
data shortly after powering it on for the first time?

No, its been prepared by gparted, and has 300 or so powerup hours
already, although only the ext4 file system was written to it.

Post by David Pottage
I saw similar behavior with an SD card a few years ago, and came up
with a theory that when new the SSD controller needs to test all the
flash to build up a bad blocks map, but most this is not done in the
factory, only when the device is powered for the first time.
So when you first plug in a flash device, only a few megabytes are
actually available for writing, and the controller is busy running
self test routines on the rest. Any writes to the untested parts of
the flash get queued behind the testing so will be quite slow. Most
users would not notice an effect, especially with SD cards in digital
cameras because they are powered all the time and only filled
gradually.

Sounds plausible, but you'd think they'd want to test it just to stop the
shipment of bad product. But then I've had an automatic contract out for
bean counters since one of them cost me 6 months fighting with an
intermittent in a radio transmitter. But when I finally caught it in the
act, I was so upset I called the maker, got the head design guy on the
phone and told him he wasn't complete, the best part had run down his
mothers leg. He had speced a ultra cheap motorized powerstat, with an
alu contact ring, and did not have one with a brass contact ring to
offer as a replacement. So I bought the $90 piece of junk and made a
brass piece to match it. End of problem.

Post by David Pottage
Of course this is all just a theory with no real evidence to back it
up other than a cynical view of flash drive manufacturers cost
cutting, but as a work around I now make a point of plugging in a new
drive and leaving it to sit powered but not otherwise in use for a few
hours before I start copying large amounts of data.

The Cynical view has been well earned by the flash suppliers.

Anyway, I had a 7 minute power failure that killed it long before my
auto-starting 20 kw brought the lights back up, so I blew away what it
did get done, and sent unzip after it, which did the unpack in just a
couple minutes. So that parts done.

Now I need to locate a source for xelatex so I can print the docs and get
started. apt can't find it it the repo's. Sigh... Hints welcomed of
course.

[Diego Roversi]

On Sat, 23 Jun 2018 11:15:47 -0400

Post by Gene Heskett
Now I need to locate a source for xelatex so I can print the docs and get
started. apt can't find it it the repo's. Sigh... Hints welcomed of
course.

I think you should install texlive-xetex package. Or just install texlive, if you have planty of disk space.

[Gene Heskett]

Post by Diego Roversi
On Sat, 23 Jun 2018 11:15:47 -0400

Post by Gene Heskett
Now I need to locate a source for xelatex so I can print the docs
and get started. apt can't find it it the repo's. Sigh... Hints
welcomed of course.

I think you should install texlive-xetex package. Or just install
texlive, if you have planty of disk space.

texlive @ 500 megs of stuff was not enough, and the texlive-xetex is
another 500 mags. Installing now. But the pi-3b is painfully slow at
installing all that. The spi bus that runs my machinery seems 100x
faster. 41 megabaud writes, 25 megabaud reads.

All this stuff is going into a 32 or 64 GB u-sd card. But I intend to
move the lcnc's nc_files to this SSD if it works to build a kernel as
that will take 90% of the write exercise off the u-sd.

Color depth of the video framebuffer needs help but I doubt if that will
ever happen given its current update speed. I'm getting used to the slow
screen updates. Under 10 frames a second, so what I see in the backplot
is always 1/4" behind the machine if its moving at any great speed. The
rock64 is easily 50x faster than a pi, but support for non-media
applications is non-existent. The mali gfx in the rock64 looks great in
the propaganda, but is only now getting some experimental support.
Despite all that, its still blindingly faster than the pi. But I can't
use it until the spi driver we have for the pi, has been ported to
the "pi like" gpio facilities the rock64 has. While I've written all
this, the pi has only 33% completed the texlive-xerex kit.
copy/paste from its ssh session:

Need to get 344 MB of archives.
After this operation, 507 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main
preview-latex-style all 11.87-3+deb8u1 [318 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian/ jessie/main
texlive-latex-extra all 2014.20141024-1 [7,604 kB]
Get:3 http://mirrordirector.raspbian.org/raspbian/ jessie/main
texlive-latex-extra-doc all 2014.20141024-1 [327 MB]
Get:4 http://mirrordirector.raspbian.org/raspbian/ jessie/main
texlive-xetex all 2014.20141024-2+deb8u1 [9,259 kB]
Fetched 344 MB in 5min 15s (1,091 kB/s)
Selecting previously unselected package preview-latex-style.
(Reading database ... 204633 files and directories currently installed.)
Preparing to unpack .../preview-latex-style_11.87-3+deb8u1_all.deb ...
Unpacking preview-latex-style (11.87-3+deb8u1) ...
Selecting previously unselected package texlive-latex-extra.
Preparing to unpack .../texlive-latex-extra_2014.20141024-1_all.deb ...
Unpacking texlive-latex-extra (2014.20141024-1) ...
Selecting previously unselected package texlive-latex-extra-doc.
Preparing to
unpack .../texlive-latex-extra-doc_2014.20141024-1_all.deb ...
Unpacking texlive-latex-extra-doc (2014.20141024-1) ...

Progress: [ 33%]
[#########################################................................................................................]

Please $DIETY, deliver me from this bottleneck of getting data into an
u-sd card. Do it by making the rock64 usable. If nothing else, a pi with
an internal usb-3 port replaceing its internal usb-2 and 2-4GB of ram,
would be a huge leap in the right direction. Booting from e-MMC right on
the cpu bus would also be helpfull, but that internal usb2 port used for
everything but spi & wifi, has GOT to be replaced with something faster
as it barely makes usb-1.1 speeds.

pi is done, finally.

Next roadblock, make pdfdocs can't find sphinx, 1.3 or better. And apt
can't find it either... Sigh.

I guess I go out and see if synaptic can show me anything on its own
screen. This is a jessie based install. But with a pinned realtime
kernel a few versions lower than what I'm attempting to build. 4.4.4
something.

[Alan Corey]

Yeah, texlive is like 1 GB. I used it once about 10 years ago but I have
it on every Debian or Raspbian machine. I wish there was more flexibility
in dependencies somehow.

Sent from my Motorola XT1527

Post by Gene Heskett

Post by Diego Roversi
On Sat, 23 Jun 2018 11:15:47 -0400

Post by Gene Heskett
Now I need to locate a source for xelatex so I can print the docs
and get started. apt can't find it it the repo's. Sigh... Hints
welcomed of course.

I think you should install texlive-xetex package. Or just install
texlive, if you have planty of disk space.

another 500 mags. Installing now. But the pi-3b is painfully slow at
installing all that. The spi bus that runs my machinery seems 100x
faster. 41 megabaud writes, 25 megabaud reads.
All this stuff is going into a 32 or 64 GB u-sd card. But I intend to
move the lcnc's nc_files to this SSD if it works to build a kernel as
that will take 90% of the write exercise off the u-sd.
Color depth of the video framebuffer needs help but I doubt if that will
ever happen given its current update speed. I'm getting used to the slow
screen updates. Under 10 frames a second, so what I see in the backplot
is always 1/4" behind the machine if its moving at any great speed. The
rock64 is easily 50x faster than a pi, but support for non-media
applications is non-existent. The mali gfx in the rock64 looks great in
the propaganda, but is only now getting some experimental support.
Despite all that, its still blindingly faster than the pi. But I can't
use it until the spi driver we have for the pi, has been ported to
the "pi like" gpio facilities the rock64 has. While I've written all
this, the pi has only 33% completed the texlive-xerex kit.
Need to get 344 MB of archives.
After this operation, 507 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main
preview-latex-style all 11.87-3+deb8u1 [318 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian/ jessie/main
texlive-latex-extra all 2014.20141024-1 [7,604 kB]
Get:3 http://mirrordirector.raspbian.org/raspbian/ jessie/main
texlive-latex-extra-doc all 2014.20141024-1 [327 MB]
Get:4 http://mirrordirector.raspbian.org/raspbian/ jessie/main
texlive-xetex all 2014.20141024-2+deb8u1 [9,259 kB]
Fetched 344 MB in 5min 15s (1,091 kB/s)
Selecting previously unselected package preview-latex-style.
(Reading database ... 204633 files and directories currently installed.)
Preparing to unpack .../preview-latex-style_11.87-3+deb8u1_all.deb ...
Unpacking preview-latex-style (11.87-3+deb8u1) ...
Selecting previously unselected package texlive-latex-extra.
Preparing to unpack .../texlive-latex-extra_2014.20141024-1_all.deb ...
Unpacking texlive-latex-extra (2014.20141024-1) ...
Selecting previously unselected package texlive-latex-extra-doc.
Preparing to
unpack .../texlive-latex-extra-doc_2014.20141024-1_all.deb ...
Unpacking texlive-latex-extra-doc (2014.20141024-1) ...
Progress: [ 33%]
[#########################################................................................................................]
Please $DIETY, deliver me from this bottleneck of getting data into an
u-sd card. Do it by making the rock64 usable. If nothing else, a pi with
an internal usb-3 port replaceing its internal usb-2 and 2-4GB of ram,
would be a huge leap in the right direction. Booting from e-MMC right on
the cpu bus would also be helpfull, but that internal usb2 port used for
everything but spi & wifi, has GOT to be replaced with something faster
as it barely makes usb-1.1 speeds.
pi is done, finally.
Next roadblock, make pdfdocs can't find sphinx, 1.3 or better. And apt
can't find it either... Sigh.
I guess I go out and see if synaptic can show me anything on its own
screen. This is a jessie based install. But with a pinned realtime
kernel a few versions lower than what I'm attempting to build. 4.4.4
something.
--
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[peter green]

Yeah, texlive is like 1 GB. I used it once about 10 years ago but I have it on every Debian or Raspbian machine. I wish there was more flexibility in dependencies somehow.

The large size is caused by a couple of factors.

1. Debian bundles together tex packages into a small number of Debian packages, I understand why they do this (tex packages are mostly quite small and there is an overhead for each package in the Debian archive) but it basically means that you normally end up installing all the packages because you end up wanting something from each.
2. Up to and including stretch texlive-latex-base, texlive-latex-recommended and texlive-latex extra declared "recommends on" their corresponding doc packages. These doc packages (especially texlive-latex-extra-doc) are unfortunately very large adding up to about 450 megabytes of download and about 550 megabytes of installed size).

You can avoid the second issue by telling apt not to install recommends, unfortunately I don't think there is much you can do about the first.

[Christian Knoke]

Post by peter green

Yeah, texlive is like 1 GB. I used it once about 10 years ago but I have it on every Debian or Raspbian machine. I wish there was more flexibility in dependencies somehow.

The large size is caused by a couple of factors.

Motivated by your Q&A, I examined the tex* packages installed on my stable
system with aptitude. I didn't find any hard dependency to other packages,
but a lot of cyclic ones. Short minded as ever, I d'd them, ending up with
869 MB less disk space use. Reads:

Die folgenden Pakete werden ENTFERNT:
dot2tex prerex preview-latex-style prosper texlive-latex-base
texlive-latex-base-doc texlive-latex-extra texlive-latex-extra-doc
texlive-latex-recommended texlive-latex-recommended-doc texlive-pictures
texlive-pictures-doc texlive-pstricks texlive-xetex texworks
texworks-scripting-lua{a} texworks-scripting-python{a} tipa vprerex

Christian

[Gene Heskett]

Post by Gene Heskett

Post by Diego Roversi
On Sat, 23 Jun 2018 11:15:47 -0400

Post by Gene Heskett
Now I need to locate a source for xelatex so I can print the docs
and get started. apt can't find it it the repo's. Sigh... Hints
welcomed of course.

I think you should install texlive-xetex package. Or just install
texlive, if you have planty of disk space.

[...]

Post by Gene Heskett
Next roadblock, make pdfdocs can't find sphinx, 1.3 or better. And apt
can't find it either... Sigh.
I guess I go out and see if synaptic can show me anything on its own
screen. This is a jessie based install. But with a pinned realtime
kernel a few versions lower than what I'm attempting to build. 4.4.4
something.

Synaptic did find it, but its version 1.2.3, too early for this >1.3
demanding makefile.

I looked at the repo's but did not find a backports entry, nor did I find
anything from debian-arm not pre-filtered by passing thru the raspian
repo first, no direct debian-arm entries.

Jessie is running well, and except for the keyboard/mouse miss-fires,
dead stable. I've tried a stretch install several times on the rock64,
and setting up an amanda-client to back it up is a sure way to lock it
up, needs a full 10 second powerdown to reboot and recover. Zip in the
logs for clues. So I won't touch a stretch install on a working machine
until amanda can back it up. And its backing up this jessie install
every night w/o any hiccups.

Open to suggestions as to what I do about the out of date sphinx-common
install. Seems like I ought to be able to find it in backports, but
whose?

/etc/apt/sources.list.d/ entry preferred.

Thanks everybody.

[Elena ``of Valhalla'']

Post by Gene Heskett

Post by Gene Heskett
Next roadblock, make pdfdocs can't find sphinx, 1.3 or better. And apt
can't find it either... Sigh.
I guess I go out and see if synaptic can show me anything on its own
screen. This is a jessie based install. But with a pinned realtime
kernel a few versions lower than what I'm attempting to build. 4.4.4
something.

Synaptic did find it, but its version 1.2.3, too early for this >1.3
demanding makefile.

I see that in debian (not raspbian) there is a backport for sphinx into
jessie-backports:

https://packages.debian.org/jessie-backports/python3-sphinx
https://packages.debian.org/jessie-backports/sphinx-common

it's arch=all, so it should work without issues on the raspberry, but
I didn't check the dependencies.

[Gene Heskett]

Post by Elena ``of Valhalla''

Post by Gene Heskett

Post by Gene Heskett
Next roadblock, make pdfdocs can't find sphinx, 1.3 or better. And
apt can't find it either... Sigh.
I guess I go out and see if synaptic can show me anything on its
own screen. This is a jessie based install. But with a pinned
realtime kernel a few versions lower than what I'm attempting to
build. 4.4.4 something.

Synaptic did find it, but its version 1.2.3, too early for this >1.3
demanding makefile.

I see that in debian (not raspbian) there is a backport for sphinx
https://packages.debian.org/jessie-backports/python3-sphinx
https://packages.debian.org/jessie-backports/sphinx-common
it's arch=all, so it should work without issues on the raspberry, but
I didn't check the dependencies.

I'm willing to give it a shot. sources.list formatted example? Theres no
debian in the current sources.list stuff at all on that pi.

Thanks.

[Luke Kenneth Casson Leighton]

Post by Gene Heskett

Post by David Pottage
So when you first plug in a flash device, only a few megabytes are
actually available for writing, and the controller is busy running
self test routines on the rest. Any writes to the untested parts of
the flash get queued behind the testing so will be quite slow. Most
users would not notice an effect, especially with SD cards in digital
cameras because they are powered all the time and only filled
gradually.

Sounds plausible, but you'd think they'd want to test it just to stop the
shipment of bad product.

pffh, naah. you can't do tests on flash without actually risking
damaging it. damage means reduced life. reduced life means less
confidence from the customer as its capacity is less than what it's
supposed to be. much better to ship out untested product and let
amazon and other sales front(s) deal with complaints and returns.

firmware on low-cost (and newly-designed unusual) SSDs is extremely
dodgy. one of the drives that i tested literally crawled to an
absolute stand-still after a certain sustained amount of parallel
writing (from different processes). the article went out on slashdot
and i was given some advice about it: stop the parallel write
queueing. there's a linux kernel parameter somewhere for it... i
didn't get to try it out unfortunately.

this was after OCZ had been caught switching on a firmware #define
which they had been TOLD under no circumstances to enable as it causes
data corruption (they wanted to be "faster" than the competition).
the data corruption was so bad it actually in some cases overwrote the
actual firmware *on the drive*, meaning that the SSD was no longer...
an SSD.

the only reasonably-priced SSDs i trust now are the intel s35xx
series. other drives such as the toshibas which are also supposed to
have supercapacitors for "enhanced power loss protection", the
supercapacitors simply aren't large enough, so a sustained series of
writes above a certain threshold speed, pull the power and there's not
enough in the supercapacitors to cover the time it takes to save the
cached data.

only the intel s35xx series has had the work put into it,
technically, to do the job *at a reasonable price*. i ran a 4-day
test writing several terabytes of data, the power was randomly pulled
at between 7 and 25 second intervals, for a total of six and a half
THOUSAND times, and *not a single byte* was lost. which is deeply
impressive.

the s37xx series is by a different team and they use the fuckwit
marvel "consumer" chipset that's so troublesome in kingston, crucial
and other SSDs.

really not being funny or anything: if you care about your data
(*and* your wallet) just don't buy anything other than intel s35xx
series SSDs. of course if you have over $10k to spend there are
plenty of data-centre quality SSDs.

l.

[Gene Heskett]

Post by Luke Kenneth Casson Leighton

Post by Gene Heskett

Post by David Pottage
So when you first plug in a flash device, only a few megabytes are
actually available for writing, and the controller is busy running
self test routines on the rest. Any writes to the untested parts of
the flash get queued behind the testing so will be quite slow. Most
users would not notice an effect, especially with SD cards in
digital cameras because they are powered all the time and only
filled gradually.

Sounds plausible, but you'd think they'd want to test it just to
stop the shipment of bad product.

pffh, naah. you can't do tests on flash without actually risking
damaging it. damage means reduced life. reduced life means less
confidence from the customer as its capacity is less than what it's
supposed to be. much better to ship out untested product and let
amazon and other sales front(s) deal with complaints and returns.
firmware on low-cost (and newly-designed unusual) SSDs is extremely
dodgy. one of the drives that i tested literally crawled to an
absolute stand-still after a certain sustained amount of parallel
writing (from different processes). the article went out on slashdot
and i was given some advice about it: stop the parallel write
queueing. there's a linux kernel parameter somewhere for it... i
didn't get to try it out unfortunately.
this was after OCZ had been caught switching on a firmware #define
which they had been TOLD under no circumstances to enable as it causes
data corruption (they wanted to be "faster" than the competition).
the data corruption was so bad it actually in some cases overwrote the
actual firmware *on the drive*, meaning that the SSD was no longer...
an SSD.
the only reasonably-priced SSDs i trust now are the intel s35xx
series. other drives such as the toshibas which are also supposed to
have supercapacitors for "enhanced power loss protection", the
supercapacitors simply aren't large enough, so a sustained series of
writes above a certain threshold speed, pull the power and there's not
enough in the supercapacitors to cover the time it takes to save the
cached data.
only the intel s35xx series has had the work put into it,
technically, to do the job *at a reasonable price*. i ran a 4-day
test writing several terabytes of data, the power was randomly pulled
at between 7 and 25 second intervals, for a total of six and a half
THOUSAND times, and *not a single byte* was lost. which is deeply
impressive.
the s37xx series is by a different team and they use the fuckwit
marvel "consumer" chipset that's so troublesome in kingston, crucial
and other SSDs.
really not being funny or anything: if you care about your data
(*and* your wallet) just don't buy anything other than intel s35xx
series SSDs. of course if you have over $10k to spend there are
plenty of data-centre quality SSDs.
l.

I will try to remember that s35xx intel.

Unforch, that search at newegg comes back empty today.

So far, and I've had a couple of 60GB adata or SP ssd's in use here for
several months with no problems, on sale for about a 44 dollar bill each
from newegg, figured I'd get my feet wet since with amanda I can do a
bare metal revert back to spinning rust should it blow up. So far, so
good.

The 3rd one I just put on the pi, an SP 60GB thats now 24 bucks, with a
$10 usb-3<->sata adapter plugged into a usb-2 port on the pi, seems to
be ok so far. Yeah, that faint knocking sound is real but my knuckles
are getting tender. :)

If it dies while building a kernel on it, thats the price we pay for
experience as I totalled a tiny spinning rust seagate 1T with a usb-3
cable sticking out of it. Spinning hours maybe 1500 when it signed off,
$50 bucks from Wallies. Running off the rock64 usb-3 port. Worked very
well, with speeds in the 350 meg a second region, when it worked.

It does seem to be the direction to get used to.

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Gene Heskett
I will try to remember that s35xx intel.
Unforch, that search at newegg comes back empty today.

currently up to version "S3520"
https://www.amazon.co.uk/Intel-S3520-240GB-Solid-State-Drive/dp/B01K4I77JE/

Post by Gene Heskett
The 3rd one I just put on the pi, an SP 60GB thats now 24 bucks, with a
$10 usb-3<->sata adapter plugged into a usb-2 port on the pi, seems to
be ok so far. Yeah, that faint knocking sound is real but my knuckles
are getting tender. :)

:)

if you're setting up a cluster of ultra-low-cost machines with
distributed redundancy then pffh who cares if even 10% of the machines
die.

l.

[Gene Heskett]

Post by Luke Kenneth Casson Leighton
---
https://www.crowdsupply.com/eoma68

Post by Gene Heskett
I will try to remember that s35xx intel.
Unforch, that search at newegg comes back empty today.

currently up to version "S3520"
https://www.amazon.co.uk/Intel-S3520-240GB-Solid-State-Drive/dp/B01K4I
77JE/

Post by Gene Heskett
The 3rd one I just put on the pi, an SP 60GB thats now 24 bucks,
with a $10 usb-3<->sata adapter plugged into a usb-2 port on the pi,
seems to be ok so far. Yeah, that faint knocking sound is real but
my knuckles are getting tender. :)

:)
if you're setting up a cluster of ultra-low-cost machines with
distributed redundancy then pffh who cares if even 10% of the machines
die.
l.

But that doesn't describe what I want to do. The pi3b runs from a u-sd,
which is slow as hell. I put the 60GB Silicon Power on it to get what I
hope is going to be a faster storage for building a new rt-kernel in a
reasonable time, like under 24 hours. In any event, the usb-2 interface
is going to represent the biggest speed limit. But all it has to do is
work error free at the available speed.

The pi 3b has plenty of power to run this lathe as its spi driver can
send a 32 bit packet of data over the spi bus to the interface card at
41 megabaud, and read the cards response at 25 megabaud. This data, like
the wifi data, does NOT have to pass thru the internal usb-2 pinhole
that all the rest of the i/o has to get thru too. If it survives that,
then the one fairly volatile data directory for LCNC might get moved to
it, further enhancing the life of the u-sd card.

I've already had one of these SP 60GB drives in a Dell running a 4 axis
milling machine for about a year. The diff in speed makes a whole new
machine out of an old Dell with a P4 processor in it. So far, zero
problems. One 300 LOC file I'm still fine tuning, has probably been
rewritten 6000 times with the only errors being my own typu's. Some of
that is a fix if I can find a focus follows mouse and turn it on.
But thats a question for the TDE list.