Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.ports.arm > #10861 > unrolled thread

causes for this?

Back to article view | Back to linux.debian.ports.arm

Contents

  causes  for this? Gene Heskett <gheskett@shentel.net> - 2018-06-23 15:00 +0200
    Re: causes for this? David Pottage <david@electric-spoon.com> - 2018-06-23 15:30 +0200
      Re: causes for this? Alan Corey <alan01346@gmail.com> - 2018-06-23 15:40 +0200
      Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-23 17:20 +0200
        Re: causes for this? Diego Roversi <diegor@tiscali.it> - 2018-06-24 10:40 +0200
          Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-24 15:40 +0200
            Re: causes for this? Alan Corey <alan01346@gmail.com> - 2018-06-24 15:50 +0200
              Re: causes for this? peter green <plugwash@p10link.net> - 2018-06-25 02:10 +0200
                Re: causes for this? Christian Knoke <chrisk@cknoke.de> - 2018-06-25 11:20 +0200
            Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-24 16:20 +0200
              Re: causes for this? Elena ``of Valhalla'' <valhalla-l@trueelena.org> - 2018-06-25 12:30 +0200
                Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-25 13:00 +0200
        Re: causes for this? Luke Kenneth Casson Leighton <lkcl@lkcl.net> - 2018-06-24 13:00 +0200
          Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-24 17:00 +0200
            Re: causes for this? Luke Kenneth Casson Leighton <lkcl@lkcl.net> - 2018-06-25 11:30 +0200
              Re: causes for this? Gene Heskett <gheskett@shentel.net> - 2018-06-25 12:40 +0200

#10861 — causes for this?

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>

[toc] | [next] | [standalone]

#10862 — Re: causes for this?

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

On 23/06/18 13:39, Gene Heskett wrote:
> 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>
>

[toc] | [prev] | [next] | [standalone]

#10863 — Re: causes for this?

[Multipart message — attachments visible in raw view] — view raw

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

On Sat, Jun 23, 2018, 9:28 AM David Pottage <david@electric-spoon.com>
wrote:

> 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
>
> On 23/06/18 13:39, Gene Heskett wrote:
> > 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>
> >
>
>

[toc] | [prev] | [next] | [standalone]

#10864 — Re: causes for this?

On Saturday 23 June 2018 09:18:29 David Pottage wrote:

> 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.

> 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. 

> 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.

-- 
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>

[toc] | [prev] | [next] | [standalone]

#10865 — Re: causes for this?

On Sat, 23 Jun 2018 11:15:47 -0400
Gene Heskett <gheskett@shentel.net> wrote:

> On Saturday 23 June 2018 09:18:29 David Pottage wrote:
> 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.



-- 
Diego Roversi <diegor@tiscali.it>

[toc] | [prev] | [next] | [standalone]

#10867 — Re: causes for this?

On Sunday 24 June 2018 04:07:28 Diego Roversi wrote:

> On Sat, 23 Jun 2018 11:15:47 -0400
>
> Gene Heskett <gheskett@shentel.net> wrote:
> > On Saturday 23 June 2018 09:18:29 David Pottage wrote:
> > 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.

-- 
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>

[toc] | [prev] | [next] | [standalone]

#10868 — Re: causes for this?

[Multipart message — attachments visible in raw view] — view raw

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

On Sun, Jun 24, 2018, 9:32 AM Gene Heskett <gheskett@shentel.net> wrote:

> On Sunday 24 June 2018 04:07:28 Diego Roversi wrote:
>
> > On Sat, 23 Jun 2018 11:15:47 -0400
> >
> > Gene Heskett <gheskett@shentel.net> wrote:
> > > On Saturday 23 June 2018 09:18:29 David Pottage wrote:
> > > 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.
>
> --
> 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>
>
>

[toc] | [prev] | [next] | [standalone]

#10871 — Re: causes for this?

On 24/06/18 14:44, Alan Corey wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#10872 — Re: causes for this?

Peter Green schriebst am 25. Jun um 00:56 Uhr:
> On 24/06/18 14:44, Alan Corey wrote:
> > 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

-- 
***   Christian Knoke  *  25541 Brunsbüttel  *  http://cknoke.de   ***
...                                                                ...
   The prejudices people feel about each other disappear when they 
get to know each other.   -- Kirk, "Elaan of Troyius", stardate 4372.5

[toc] | [prev] | [next] | [standalone]

#10869 — Re: causes for this?

On Sunday 24 June 2018 09:31:27 Gene Heskett wrote:

> On Sunday 24 June 2018 04:07:28 Diego Roversi wrote:
> > On Sat, 23 Jun 2018 11:15:47 -0400
> >
> > Gene Heskett <gheskett@shentel.net> wrote:
> > > On Saturday 23 June 2018 09:18:29 David Pottage wrote:
> > > 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.
>
[...]
> 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.

-- 
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>

[toc] | [prev] | [next] | [standalone]

#10874 — Re: causes for this?

On 2018-06-24 at 10:13:06 -0400, Gene Heskett wrote:
> > 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.

-- 
Elena ``of Valhalla''

[toc] | [prev] | [next] | [standalone]

#10876 — Re: causes for this?

On Monday 25 June 2018 05:43:19 Elena ``of Valhalla'' wrote:

> On 2018-06-24 at 10:13:06 -0400, Gene Heskett wrote:
> > > 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.

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.



-- 
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>

[toc] | [prev] | [next] | [standalone]

#10866 — Re: causes for this?

On Sat, Jun 23, 2018 at 4:15 PM, Gene Heskett <gheskett@shentel.net> wrote:

>> 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.

[toc] | [prev] | [next] | [standalone]

#10870 — Re: causes for this?

On Sunday 24 June 2018 06:15:24 Luke Kenneth Casson Leighton wrote:

> On Sat, Jun 23, 2018 at 4:15 PM, Gene Heskett <gheskett@shentel.net> 
wrote:
> >> 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.

-- 
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>

[toc] | [prev] | [next] | [standalone]

#10873 — Re: causes for this?

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


On Sun, Jun 24, 2018 at 3:57 PM, Gene Heskett <gheskett@shentel.net> wrote:

> 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/

> 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.

[toc] | [prev] | [next] | [standalone]

#10875 — Re: causes for this?

On Monday 25 June 2018 05:26:41 Luke Kenneth Casson Leighton wrote:

> ---
> crowd-funded eco-conscious hardware:
> https://www.crowdsupply.com/eoma68
>
> On Sun, Jun 24, 2018 at 3:57 PM, Gene Heskett <gheskett@shentel.net> 
wrote:
> > 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/
>
> > 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.

-- 
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>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.ports.arm

csiph-web