Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #267123 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2024-02-07 21:40 +0100 |
| Last post | 2024-02-09 14:20 +0100 |
| Articles | 20 on this page of 98 — 20 participants |
Back to article view | Back to linux.debian.user
Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-07 21:40 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-08 05:30 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 11:00 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 11:40 +0100
shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-10 13:50 +0100
Re: shred bug? [was: Unidentified subject!] tomas@tuxteam.de - 2024-02-10 14:00 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 15:00 +0100
Re: shred bug? <tomas@tuxteam.de> - 2024-02-10 15:40 +0100
Re: shred bug? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-10 14:40 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 14:40 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 01:10 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 01:20 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 01:30 +0100
Re: shred bug? [was: Unidentified subject!] debian-user@howorth.org.uk - 2024-02-11 14:00 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 14:30 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 08:10 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 15:40 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 15:50 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 16:00 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 16:00 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-12 18:00 +0100
Re: shred bug? [was: Unidentified subject!] Curt <curty@free.fr> - 2024-02-12 18:00 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 22:00 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-12 22:10 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-13 06:50 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-11 16:30 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 13:20 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 13:40 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-13 13:50 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 14:00 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-13 16:40 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 17:30 +0100
Re: shred bug? [was: Unidentified subject!] debian-user@howorth.org.uk - 2024-02-13 18:50 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-13 22:10 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-14 06:50 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 19:00 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 20:00 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 20:40 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 20:40 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 20:50 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 21:30 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-13 22:10 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 22:50 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-15 06:40 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 23:50 +0100
Re: shred bug? [was: Unidentified subject!] Max Nikulin <manikulin@gmail.com> - 2024-02-13 03:40 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 16:30 +0100
Re: shred bug? [was: Unidentified subject!] Michael Stone <mstone@debian.org> - 2024-02-16 16:00 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 18:50 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 19:40 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 20:30 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 00:50 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 09:10 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 21:50 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 00:40 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 09:20 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 11:10 +0100
Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-11 11:30 +0100
Re: Fast Random Data Generation "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 12:30 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-11 13:20 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 07:20 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-12 17:40 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 22:30 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-13 18:40 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Jeffrey Walton <noloader@gmail.com> - 2024-02-12 22:30 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 12:20 +0100
Re: Unidentified subject! Jeffrey Walton <noloader@gmail.com> - 2024-02-11 16:20 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 23:00 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-10 15:40 +0100
Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 16:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 17:20 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 17:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-09 09:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Ralph Aichinger <ra@h5.or.at> - 2024-02-08 18:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Jeffrey Walton <noloader@gmail.com> - 2024-02-08 20:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:20 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 23:10 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-09 14:00 +0100
Re: Things I don't touch with a 3.048m barge pole "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-09 14:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-10 07:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage(WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-10 18:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Arno Lehmann <al@its-lehmann.de> - 2024-02-09 09:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Max Nikulin <manikulin@gmail.com> - 2024-02-08 18:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:10 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:20 +0100
Re: Unidentified subject! Richmond <dnomhcir@gmx.com> - 2024-02-08 23:50 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-09 00:10 +0100
Re: Unidentified subject! Charles Curley <charlescurley@charlescurley.com> - 2024-02-09 00:50 +0100
Re: Unidentified subject! Richmond <dnomhcir@gmx.com> - 2024-02-09 05:50 +0100
Re: Unidentified flying subject! Charles Curley <charlescurley@charlescurley.com> - 2024-02-09 07:50 +0100
Re: Unidentified flying subject! Richmond <dnomhcir@gmx.com> - 2024-02-09 14:20 +0100
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-12 07:20 +0100 |
| Subject | Re: Fast Random Data Generation (Was: Re: Unidentified subject!) |
| Message-ID | <I6xPA-9AWS-3@gated-at.bofh.it> |
| In reply to | #267279 |
On 2/11/24 02:26, Linux-Fan wrote: > I wrote a program to automatically generate random bytes in multiple > threads: > https://masysma.net/32/big4.xhtml > > Before knowing about `fio` this way my way to benchmark SSDs :) > > Example: > > | $ big4 -b /dev/null 100 GiB > | Ma_Sys.ma Big 4.0.2, Copyright (c) 2014, 2019, 2020 Ma_Sys.ma. > | For further info send an e-mail to Ma_Sys.ma@web.de. > || 0.00% +0 MiB 0 MiB/s 0/102400 MiB > | 3.48% +3562 MiB 3255 MiB/s 3562/102400 MiB > | 11.06% +7764 MiB 5407 MiB/s 11329/102400 MiB > | 19.31% +8436 MiB 6387 MiB/s 19768/102400 MiB > | 27.71% +8605 MiB 6928 MiB/s 28378/102400 MiB > | 35.16% +7616 MiB 7062 MiB/s 35999/102400 MiB > | 42.58% +7595 MiB 7150 MiB/s 43598/102400 MiB > | 50.12% +7720 MiB 7230 MiB/s 51321/102400 MiB > | 58.57% +8648 MiB 7405 MiB/s 59975/102400 MiB > | 66.96% +8588 MiB 7535 MiB/s 68569/102400 MiB > | 75.11% +8343 MiB 7615 MiB/s 76916/102400 MiB > | 83.38% +8463 MiB 7691 MiB/s 85383/102400 MiB > | 91.74% +8551 MiB 7762 MiB/s 93937/102400 MiB > | 99.97% +8426 MiB 7813 MiB/s 102368/102400 MiB > || Wrote 102400 MiB in 13 s @ 7812.023 MiB/s What algorithm did you implement? > Secure Random can be obtained from OpenSSL: > > | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * > 1024 * 1024)); done > | > | real 0m49.288s > | user 0m44.710s > | sys 0m4.579s > > Effectively 2078 MiB/s (quite OK for single-threaded operation). It is > not designed to generate large amounts of random data as the size is > limited by integer range... Thank you for posting the openssl(1) incantation. Benchmarking my daily driver laptop without Intel Secure Key: 2024-02-11 21:54:04 dpchrist@laalaa ~ $ lscpu | grep 'Model name' Model name: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz 2024-02-11 21:54:09 dpchrist@laalaa ~ $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done real 1m40.149s user 1m25.174s sys 0m14.952s So, ~1.072E+9 bytes per second. Benchmarking a workstation with Intel Secure Key: 2024-02-11 21:54:40 dpchrist@taz ~ $ lscpu | grep 'Model name' Model name: Intel(R) Xeon(R) E-2174G CPU @ 3.80GHz 2024-02-11 21:54:46 dpchrist@taz ~ $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done real 1m14.696s user 1m0.338s sys 0m14.353s So, ~1.437E+09 bytes per second. David
[toc] | [prev] | [next] | [standalone]
| From | Linux-Fan <Ma_Sys.ma@web.de> |
|---|---|
| Date | 2024-02-12 17:40 +0100 |
| Subject | Re: Fast Random Data Generation (Was: Re: Unidentified subject!) |
| Message-ID | <I6Hvz-9GDo-3@gated-at.bofh.it> |
| In reply to | #267319 |
[Multipart message — attachments visible in raw view] — view raw
David Christensen writes: > On 2/11/24 02:26, Linux-Fan wrote: >> I wrote a program to automatically generate random bytes in multiple threads: >> https://masysma.net/32/big4.xhtml >> >> Before knowing about `fio` this way my way to benchmark SSDs :) >> >> Example: >> >> | $ big4 -b /dev/null 100 GiB >> | Ma_Sys.ma Big 4.0.2, Copyright (c) 2014, 2019, 2020 Ma_Sys.ma. >> | For further info send an e-mail to Ma_Sys.ma@web.de. [...] >> | 99.97% +8426 MiB 7813 MiB/s 102368/102400 MiB >> | Wrote 102400 MiB in 13 s @ 7812.023 MiB/s > > > What algorithm did you implement? I copied the algorithm from here: https://www.javamex.com/tutorials/random_numbers/numerical_recipes.shtml I found it during the development of another application where I needed a lot of random data for simulation purposes :) My implementation code is here: https://github.com/m7a/bo-big/blob/master/latest/Big4.java If I were to do it again today, I'd probably switch to any of these PRNGS: * https://burtleburtle.net/bob/rand/smallprng.html * https://www.pcg-random.org/ >> Secure Random can be obtained from OpenSSL: >> >> | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 >> * 1024)); done >> | >> | real 0m49.288s >> | user 0m44.710s >> | sys 0m4.579s >> >> Effectively 2078 MiB/s (quite OK for single-threaded operation). It is not >> designed to generate large amounts of random data as the size is limited by >> integer range... > > > Thank you for posting the openssl(1) incantation. You're welcome. [...] HTH Linux-Fan öö
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-12 22:30 +0100 |
| Subject | Re: Fast Random Data Generation (Was: Re: Unidentified subject!) |
| Message-ID | <I6M2d-9Jqf-1@gated-at.bofh.it> |
| In reply to | #267327 |
On 2/12/24 08:30, Linux-Fan wrote: > David Christensen writes: > >> On 2/11/24 02:26, Linux-Fan wrote: >>> I wrote a program to automatically generate random bytes in multiple >>> threads: >>> https://masysma.net/32/big4.xhtml >> >> What algorithm did you implement? > > I copied the algorithm from here: > https://www.javamex.com/tutorials/random_numbers/numerical_recipes.shtml That Java code uses locks, which implies it uses global state and cannot be run multi-threaded (?). (E.g. one process with one JVM.) Is it possible to obtain parallel operation on an SMP machine with multiple virtual processors? (Other than multiple OS processes with one PRNG on one JVM each?) > I found it during the development of another application where I needed > a lot of random data for simulation purposes :) > > My implementation code is here: > https://github.com/m7a/bo-big/blob/master/latest/Big4.java > > If I were to do it again today, I'd probably switch to any of these PRNGS: > > * https://burtleburtle.net/bob/rand/smallprng.html > * https://www.pcg-random.org/ Hard core. I'll let the experts figure it out; and then I will use their libraries and programs. David
[toc] | [prev] | [next] | [standalone]
| From | Linux-Fan <Ma_Sys.ma@web.de> |
|---|---|
| Date | 2024-02-13 18:40 +0100 |
| Subject | Re: Fast Random Data Generation (Was: Re: Unidentified subject!) |
| Message-ID | <I74Vc-9V9L-13@gated-at.bofh.it> |
| In reply to | #267339 |
[Multipart message — attachments visible in raw view] — view raw
David Christensen writes:
> On 2/12/24 08:30, Linux-Fan wrote:
>> David Christensen writes:
>>
>>> On 2/11/24 02:26, Linux-Fan wrote:
>>>> I wrote a program to automatically generate random bytes in multiple threads:
>>>> https://masysma.net/32/big4.xhtml
>>>
>>> What algorithm did you implement?
>>
>> I copied the algorithm from here:
>> https://www.javamex.com/tutorials/random_numbers/numerical_recipes.shtml
>
> That Java code uses locks, which implies it uses global state and cannot be
> run multi-threaded (?). (E.g. one process with one JVM.)
Indeed, the example code uses locks which is bad from a performance point of
view. That is why _my_ implementation works without this fine-grained
locking and instead ensures that each thread uses its own instance as to
avoid the lock. IOW: I copied the algorithm but of course adjusted the code
to my use case.
My version basically runs as follows:
* Create one queue of ByteBuffers
* Create multiple threads
* Each thread runs their own RNG instance
* Upon finishing the creation of a buffer, it enqueues
the resulting ByteBuffer into the queue (this is the only
part where multiple threads access concurrently)
* The main thread dequeues from the queue and writes the
buffers to the output file
> Is it possible to obtain parallel operation on an SMP machine with multiple
> virtual processors? (Other than multiple OS processes with one PRNG on one
> JVM each?)
Even the locked random could be instantiated multiple times (each instance
gets their own lock) and this could still be faster than running just
one of it. However, since the computation itself is fast, I suppose the
performance hit from managing the locks could be significant. Multiple OS
processes would also work, but is pretty uncommon in Java land AFAIR.
>> I found it during the development of another application where I needed a
>> lot of random data for simulation purposes :)
>>
>> My implementation code is here:
>> https://github.com/m7a/bo-big/blob/master/latest/Big4.java
See the end of that file to compare with the “Numerical Recipes” RNG linked
further above to observe the difference wrt. locking :)
>> If I were to do it again today, I'd probably switch to any of these PRNGS:
>>
>> * https://burtleburtle.net/bob/rand/smallprng.html
>> * https://www.pcg-random.org/
>
> Hard core. I'll let the experts figure it out; and then I will use their
> libraries and programs.
IIRC one of the findings of PCG was that the default RNGs of many
programming languages and environments are surprisingly bad. I only arrived at
using a non-default implementation after facing some issues with the Java
integrated ThreadLocalRandom ”back then” :)
It may indeed be worth pointing out (as Jeffrey Walton already mentioned in
another subthread) that these RNGs discussed here are _not_ cryptographic
RNGs. I think for disk testing purposes it is OK to use fast non-
cryptographic RNGs, but other applications may have higher demands on their
RNGs.
HTH
Linux-Fan
öö
[...]
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2024-02-12 22:30 +0100 |
| Subject | Re: Fast Random Data Generation (Was: Re: Unidentified subject!) |
| Message-ID | <I6M2d-9Jqf-9@gated-at.bofh.it> |
| In reply to | #267327 |
On Mon, Feb 12, 2024 at 3:02 PM Linux-Fan <Ma_Sys.ma@web.de> wrote: > > David Christensen writes: > > > On 2/11/24 02:26, Linux-Fan wrote: > >> I wrote a program to automatically generate random bytes in multiple threads: > >> https://masysma.net/32/big4.xhtml > >> > >> Before knowing about `fio` this way my way to benchmark SSDs :) > >> > >> Example: > >> > >> | $ big4 -b /dev/null 100 GiB > >> | Ma_Sys.ma Big 4.0.2, Copyright (c) 2014, 2019, 2020 Ma_Sys.ma. > >> | For further info send an e-mail to Ma_Sys.ma@web.de. > > [...] > > >> | 99.97% +8426 MiB 7813 MiB/s 102368/102400 MiB > >> | Wrote 102400 MiB in 13 s @ 7812.023 MiB/s > > > > > > What algorithm did you implement? > > I copied the algorithm from here: > https://www.javamex.com/tutorials/random_numbers/numerical_recipes.shtml > > I found it during the development of another application where I needed a > lot of random data for simulation purposes :) A PRNG for a simulation has different requirements than a PRNG for cryptographic purposes. A simulation usually needs numbers fast from a uniform distribution. Simulations can use predictable numbers. Often a Linear Congurential Generator (LCG) will do just fine even though they were broken about 35 years ago. See Also see Joan Boyer's Inferring Sequences Produced by Pseudo-Random Number Generators, <https://asterix.cs.gsu.edu/crypto/p129-boyar.pdf>. A cryptographic application will have more stringent requirements. A cryptographic generator may (will?) take longer to generate a number, the numbers need to come from a uniform distribution, and the numbers need to be prediction resistant. You can read about the cryptographic qualities of random numbers in NIST SP800-90 and friends. > My implementation code is here: > https://github.com/m7a/bo-big/blob/master/latest/Big4.java > > If I were to do it again today, I'd probably switch to any of these PRNGS: > > * https://burtleburtle.net/bob/rand/smallprng.html > * https://www.pcg-random.org/ > > >> Secure Random can be obtained from OpenSSL: > >> > >> | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 > >> * 1024)); done > >> | > >> | real 0m49.288s > >> | user 0m44.710s > >> | sys 0m4.579s > >> > >> Effectively 2078 MiB/s (quite OK for single-threaded operation). It is not > >> designed to generate large amounts of random data as the size is limited by > >> integer range... Jeff
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-11 12:20 +0100 |
| Message-ID | <I6g2l-9pWM-1@gated-at.bofh.it> |
| In reply to | #267276 |
Hi,
David Christensen wrote:
> Concurrency:
> threads throughput
> 8 205+198+180+195+205+184+184+189=1,540 MB/s
There remains the question how to join these streams without losing speed
in order to produce a single checksum. (Or one would have to divide the
target into 8 areas which get checked separately.)
Does this 8 thread generator cause any problems with the usability of
the rest of the system ? Sluggish program behavior or so ?
The main reason to have my own low-quality implementation of a random
stream was that /dev/urandom was too slow for 12x speed (= 1.8 MB/s) CD-RW
media and that higher random quality still put too much load on a
single-core 600 MHz Pentium system. That was nearly 25 years ago.
I wrote:
> > Last time i tested /dev/urandom it was much slower on comparable machines
> > and also became slower as the amount grew.
> Did you figure out why the Linux random number subsystem slowed, and at what
> amount?
No. I cannot even remember when and why i had reason to compare it with
my own stream generator. Maybe 5 or 10 years ago. The throughput was
more than 100 times better.
I have to correct my previous measurement on the 4 GHz Xeon, which was
made with a debuggable version of the program that produced the stream.
The production binary which is compiled with -O2 can write 2500 MB/s into
a pipe with a pacifier program which counts the data:
$ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni | $(scdbackup -where bin)/raedchen -step 100m -no_output -print_count
100.0g bytes
real 0m39.884s
user 0m30.629s
sys 0m41.013s
(One would have to install scdbackup to reproduce this and to see raedchen
count the bytes while spinning the classic SunOS boot wheel: |/-\|/-\|/-\
http://scdbackup.webframe.org/main_eng.html
http://scdbackup.webframe.org/examples.html
Oh nostalgy ...
)
Totally useless but yielding nearly 4000 MB/s:
$ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni >/dev/null
real 0m27.064s
user 0m23.433s
sys 0m3.646s
The main bottleneck in my proposal would be the checksummer:
$ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni | md5sum
5a6ba41c2c18423fa33355005445c183 -
real 2m8.160s
user 2m25.599s
sys 0m22.663s
That's quite exactly 800 MiB/s ~= 6.7 Gbps.
Still good enough for vanilla USB-3 with a fast SSD, i'd say.
> TIMTOWTDI. :-)
Looks like another example of a weak random stream. :))
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2024-02-11 16:20 +0100 |
| Message-ID | <I6jMB-9scf-3@gated-at.bofh.it> |
| In reply to | #267280 |
On Sun, Feb 11, 2024 at 9:52 AM Thomas Schmitt <scdbackup@gmx.net> wrote: > > David Christensen wrote: > > Concurrency: > > threads throughput > > 8 205+198+180+195+205+184+184+189=1,540 MB/s > > There remains the question how to join these streams without losing speed > in order to produce a single checksum. (Or one would have to divide the > target into 8 areas which get checked separately.) Hash Tree or Merkle Tree. They are used in blockchains. > Does this 8 thread generator cause any problems with the usability of > the rest of the system ? Sluggish program behavior or so ? > > The main reason to have my own low-quality implementation of a random > stream was that /dev/urandom was too slow for 12x speed (= 1.8 MB/s) CD-RW > media and that higher random quality still put too much load on a > single-core 600 MHz Pentium system. That was nearly 25 years ago. Jeff
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-11 23:00 +0100 |
| Message-ID | <I6q1I-9vVL-15@gated-at.bofh.it> |
| In reply to | #267280 |
On 2/11/24 03:13, Thomas Schmitt wrote: > Hi, > > David Christensen wrote: >> Concurrency: >> threads throughput >> 8 205+198+180+195+205+184+184+189=1,540 MB/s > > There remains the question how to join these streams without losing speed > in order to produce a single checksum. (Or one would have to divide the > target into 8 areas which get checked separately.) I had similar thoughts. A FIFO should be able to join the streams. But, dividing the device by the number of virtual cores and putting a thread on each makes more sense. Either done right should fill the drive I/O capacity. > Does this 8 thread generator cause any problems with the usability of > the rest of the system ? Sluggish program behavior or so ? CPU Graph shows all eight virtual cores at 100%, so everything else on the system would be sluggish (unless you use nice(1)). Here is a processor with Intel Secure Key and otherwise unloaded: 2024-02-11 11:48:21 dpchrist@taz ~ $ lscpu | grep 'Model name' Model name: Intel(R) Xeon(R) E-2174G CPU @ 3.80GHz 2024-02-11 11:59:55 dpchrist@taz ~ $ cat /etc/debian_version ; uname -a 11.8 Linux taz 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux 2024-02-11 12:02:52 dpchrist@taz ~ $ dd if=/dev/urandom of=/dev/null bs=1M count=10K 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 20.0469 s, 536 MB/s threads throughput 1 536 MB/s 2 512+512 = 1,024 MB/s 3 502+503+503 = 1,508 MB/s 4 492+491+492+492 = 1,967 MB/s 5 492+384+491+385+491 = 2,243 MB/s 6 379+491+492+379+379+379 = 2,499 MB/s 7 352+491+356+388+352+357+388 = 2,684 MB/s 8 355+354+344+348+344+354+353+349 = 2,801 MB/s > I have to correct my previous measurement on the 4 GHz Xeon, which was > made with a debuggable version of the program that produced the stream. > The production binary which is compiled with -O2 can write 2500 MB/s into > a pipe with a pacifier program which counts the data: > > $ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni | $(scdbackup -where bin)/raedchen -step 100m -no_output -print_count > 100.0g bytes > > real 0m39.884s > user 0m30.629s > sys 0m41.013s > > (One would have to install scdbackup to reproduce this and to see raedchen > count the bytes while spinning the classic SunOS boot wheel: |/-\|/-\|/-\ > http://scdbackup.webframe.org/main_eng.html > http://scdbackup.webframe.org/examples.html > Oh nostalgy ... > ) > > Totally useless but yielding nearly 4000 MB/s: > > $ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni >/dev/null > > real 0m27.064s > user 0m23.433s > sys 0m3.646s > > The main bottleneck in my proposal would be the checksummer: > > $ time $(scdbackup -where bin)/cd_backup_planer -write_random - 100g 2s62gss463ar46492bni | md5sum > 5a6ba41c2c18423fa33355005445c183 - > > real 2m8.160s > user 2m25.599s > sys 0m22.663s > > That's quite exactly 800 MiB/s ~= 6.7 Gbps. > Still good enough for vanilla USB-3 with a fast SSD, i'd say. Yes -- more than enough throughput. Before I knew of fdupes(1) and jdupes(1), I wrote a Perl script to find duplicate files. It uses the Digest module, and supports any algorithm supported by that module. Here are some runs against a local ext4 on LUKS (with AES-NI) on Intel SSD 520 Series 60 GB and check summing whole files: 2024-02-11 13:32:47 dpchrist@taz ~ $ time finddups --filter w --digest MD4 .thunderbird/ >/dev/null real 0m0.878s user 0m0.741s sys 0m0.137s 2024-02-11 13:33:14 dpchrist@taz ~ $ time finddups --filter w --digest MD5 .thunderbird/ >/dev/null real 0m1.110s user 0m0.977s sys 0m0.132s 2024-02-11 13:33:19 dpchrist@taz ~ $ time finddups --filter w --digest SHA-1 .thunderbird/ >/dev/null real 0m1.306s user 0m1.151s sys 0m0.156s 2024-02-11 13:36:40 dpchrist@taz ~ $ time finddups --filter w --digest SHA-256 .thunderbird/ >/dev/null real 0m2.545s user 0m2.424s sys 0m0.121s 2024-02-11 13:36:51 dpchrist@taz ~ $ time finddups --filter w --digest SHA-384 .thunderbird/ >/dev/null real 0m1.808s user 0m1.652s sys 0m0.157s 2024-02-11 13:37:00 dpchrist@taz ~ $ time finddups --filter w --digest SHA-512 .thunderbird/ >/dev/null real 0m1.814s user 0m1.673s sys 0m0.141s It is curious that SHA-384 and SHA-512 are faster than SHA-256. I can confirm similar results on: 2024-02-11 13:39:58 dpchrist@laalaa ~ $ lscpu | grep 'Model name' Model name: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz David
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-02-10 15:40 +0100 |
| Message-ID | <I5WGm-9eeC-3@gated-at.bofh.it> |
| In reply to | #267218 |
>> AFAIK the bogus 128TB drives do properly report such ridiculous sizes:
>> the reality only hits when you try to actually store that amount of
>> information on them.
>> [ I'm not sure how it works under the hood, but since SSDs store their
>> data "anywhere" in the flash, they can easily pretend to have any size
>> they want, and allocate the physical flash blocks only on-the-fly as
>> logical blocks are being written.
>> Also, some Flash controllers use compression, so if you store data
>> that compresses well, they can let you store a lot more than if you
>> store already compressed data. ]
>> IOW, to really check, try to save 2TB of videos (or other already
>> compressed data), and then try and read it back.
>>
> Sounds like a lawsuit to me. If I can get Alexanders script from a few days
> back to run. Is bash not actually bash these days? It is not doing for
> loops for me.
As discussed in related threads, there's the `f3` package in Debian
designed specifically for that.
You can try `f3probe /dev/sdX` (or use `f3write` and `f3read` if you
prefer to test at the filesystem level rather than at the block level).
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-02-08 16:40 +0100 |
| Subject | Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5eFj-8Lz2-1@gated-at.bofh.it> |
| In reply to | #267123 |
Hello, On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: > [629241.074187] scsi host37: usb-storage 1-2:1.0 USB storage is for phones and cameras etc, not for serious computing. Many people will disagree with that statement and say they use it all the time and it is fine. They will keep saying that until it isn't fine, and then they'll be in a world of hurt. I learned not to go there a long time ago and have seen plenty of reminders along the way from others' misfortunes to not ever go there again myself. > Looks like a reasonable facsimile of a 2T disk to me. Good luck. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <scott-andrews@columbus.rr.com> |
|---|---|
| Date | 2024-02-08 17:20 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5fi1-8M1f-1@gated-at.bofh.it> |
| In reply to | #267137 |
On 2/8/24 10:36, Andy Smith wrote: > Hello, > > On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: >> [629241.074187] scsi host37: usb-storage 1-2:1.0 > > USB storage is for phones and cameras etc, not for serious > computing. Many people will disagree with that statement and say > they use it all the time and it is fine. They will keep saying that > until it isn't fine, and then they'll be in a world of hurt. > LOL, So my main desktop a raspberry pi 4 is not serious computing? Or is it that my name server, web server email server which is a raspberry pi 4 not serious computing? They both boot to USB SSDs and only have USB SSD drives, so they are not serious computing? The desktop RPI has an NVME drive as the boot drive connected by you guessed it USB. > I learned not to go there a long time ago and have seen plenty of > reminders along the way from others' misfortunes to not ever go > there again myself. >
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-02-08 17:30 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5frH-8M4e-11@gated-at.bofh.it> |
| In reply to | #267138 |
Hi, On Thu, Feb 08, 2024 at 11:14:24AM -0500, Gremlin wrote: > On 2/8/24 10:36, Andy Smith wrote: > > USB storage is for phones and cameras etc, not for serious > > computing. Many people will disagree with that statement and say > > they use it all the time and it is fine. They will keep saying that > > until it isn't fine, and then they'll be in a world of hurt. > > > > LOL, So my main desktop a raspberry pi 4 is not serious computing? Or is it > that my name server, web server email server which is a raspberry pi 4 not > serious computing? Not in my opinion, no¹, but I don't mind at all if you don't agree and I also wish you the best of ongoing luck! Thanks, Andy ¹ Of course, sometimes you just have a device that only has USB and there's no way around it. If I have to go there, I try to make it serious by preparing for the storage of those devices to just disappear one day and take steps to minimise the downtime lost to that. -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-02-09 09:50 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) |
| Message-ID | <I5uK5-8VfA-1@gated-at.bofh.it> |
| In reply to | #267138 |
On 2/8/24 11:15, Gremlin wrote: > On 2/8/24 10:36, Andy Smith wrote: >> Hello, >> >> On Wed, Feb 07, 2024 at 03:30:29PM -0500, gene heskett wrote: >>> [629241.074187] scsi host37: usb-storage 1-2:1.0 >> >> USB storage is for phones and cameras etc, not for serious >> computing. Many people will disagree with that statement and say >> they use it all the time and it is fine. They will keep saying that >> until it isn't fine, and then they'll be in a world of hurt. >> > > LOL, So my main desktop a raspberry pi 4 is not serious computing? Or > is it that my name server, web server email server which is a raspberry > pi 4 not serious computing? > > They both boot to USB SSDs and only have USB SSD drives, so they are not > serious computing? The desktop RPI has an NVME drive as the boot drive > connected by you guessed it USB. > > >> I learned not to go there a long time ago and have seen plenty of >> reminders along the way from others' misfortunes to not ever go >> there again myself. >> Well, most of what you attributed to me came from an earlier post. I'd never call a pi4b inadequate. Its running an 11x54 lathe just like a wintel box can. All the other stuff that makes a desktop computer, web browsing, the office suites, web server, you name it, it Just Works. Not as fast, but it works as advertised. And does all that on a 5x5 psu, with an AOC monitors whose label claim it uses 10 watts. I don't even shut them off. > > > . Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Ralph Aichinger <ra@h5.or.at> |
|---|---|
| Date | 2024-02-08 18:00 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5fUJ-8Mdz-3@gated-at.bofh.it> |
| In reply to | #267137 |
On Thu, 2024-02-08 at 15:36 +0000, Andy Smith wrote: > USB storage is for phones and cameras etc, not for serious > computing. Many people will disagree with that statement and say > they use it all the time and it is fine. I am clearly in the latter camp. This mail is delivered via a Raspberry Pi 4 that has a 500G USB SSD. Before the Pi4 I used a Pi3 and a Pi2 (I think) with USB disks (first rotating, then SSD). Probably for 5 years or so. Never had a problem (unlike with the SD cards I used before, SD cards always died on me from to many writes after a few months). > They will keep saying that > until it isn't fine, and then they'll be in a world of hurt. This is the same with any hard disk or SSD. If you buy the most expensive "enterprise" disk, with SAS or whatever, it still can break on the next day, taking all your data with you. Actually with USB disks, sometimes you can remove the USB controller, replace it in case of breakage, giving you more or less the same reliability as any "normal" disk. I've never had USB controllers break, though, so I do not care. I just take backups as with any other disk. > I learned not to go there a long time ago and have seen plenty of > reminders along the way from others' misfortunes to not ever go > there again myself. How does a breaking USB disk differ from a breaking SATA disk? /ralph
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2024-02-08 20:30 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5ifU-8NJi-3@gated-at.bofh.it> |
| In reply to | #267143 |
On Thu, Feb 8, 2024 at 11:57 AM Ralph Aichinger <ra@h5.or.at> wrote: > > On Thu, 2024-02-08 at 15:36 +0000, Andy Smith wrote: > > USB storage is for phones and cameras etc, not for serious > > computing. Many people will disagree with that statement and say > > they use it all the time and it is fine. > > I am clearly in the latter camp. This mail is delivered via a Raspberry > Pi 4 that has a 500G USB SSD. Before the Pi4 I used a Pi3 and a Pi2 (I > think) with USB disks (first rotating, then SSD). Probably for 5 years > or so. Never had a problem (unlike with the SD cards I used before, SD > cards always died on me from to many writes after a few months). > > > They will keep saying that > > until it isn't fine, and then they'll be in a world of hurt. > > This is the same with any hard disk or SSD. If you buy the most > expensive "enterprise" disk, with SAS or whatever, it still can > break on the next day, taking all your data with you. > > Actually with USB disks, sometimes you can remove the USB > controller, replace it in case of breakage, giving you more > or less the same reliability as any "normal" disk. > I've never had USB controllers break, though, so I do not > care. I just take backups as with any other disk. > > > I learned not to go there a long time ago and have seen plenty of > > reminders along the way from others' misfortunes to not ever go > > there again myself. > > How does a breaking USB disk differ from a breaking SATA disk? I may be mistaken, but I believe AS is talking about USB thumb drives, SDcards and the like. I don't think he's talking about external SSD's and NVME's over USB. But I don't want to put words in his mouth. My experience with SDcards and thumb drives is along the lines of AS's. I own a lot of dev boards (dating back to the early 2010's) for testing, and I could go through a storage device, like an SDcard, in about 6 months. But I would also add a swap file to the installation because the dev boards were so resource constrained. You simply can't run a C++ compiler on a Beagleboard with 256MB of RAM. The swap file, even with a low swappiness, would eat up SDcards and thumb drives. Jeff
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-02-08 21:50 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5jvj-8Ook-3@gated-at.bofh.it> |
| In reply to | #267151 |
On Thu, Feb 08, 2024 at 08:43:17PM +0000, Andy Smith wrote:
> I really do mean all forms of USB that come over a USB port.
That line was meant to read
I really do mean all forms of storage that come over a USB port.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-02-08 21:50 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5jvj-8Ook-5@gated-at.bofh.it> |
| In reply to | #267151 |
Hello, On Thu, Feb 08, 2024 at 02:20:59PM -0500, Jeffrey Walton wrote: > On Thu, Feb 8, 2024 at 11:57 AM Ralph Aichinger <ra@h5.or.at> wrote: > > How does a breaking USB disk differ from a breaking SATA disk? > > I may be mistaken, but I believe AS is talking about USB thumb drives, > SDcards and the like. I don't think he's talking about external SSD's > and NVME's over USB. But I don't want to put words in his mouth. I really do mean all forms of USB that come over a USB port. I wouldn't have much issue with taking a USB drive out of its caddy to get the SATA drive from inside, except that it would have to be an amazingly good deal to make it worth voiding the warranty, so I generally wouldn't bother. If I need directly attached storage I'd much rather explore options like SAS and eSATA, or even networked storage, before I would ever consider USB for a permanent installation. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <scott-andrews@columbus.rr.com> |
|---|---|
| Date | 2024-02-08 22:00 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5jEZ-8OrE-9@gated-at.bofh.it> |
| In reply to | #267158 |
On 2/8/24 15:43, Andy Smith wrote: > Hello, > > On Thu, Feb 08, 2024 at 02:20:59PM -0500, Jeffrey Walton wrote: >> On Thu, Feb 8, 2024 at 11:57 AM Ralph Aichinger <ra@h5.or.at> wrote: >>> How does a breaking USB disk differ from a breaking SATA disk? >> >> I may be mistaken, but I believe AS is talking about USB thumb drives, >> SDcards and the like. I don't think he's talking about external SSD's >> and NVME's over USB. But I don't want to put words in his mouth. > > I really do mean all forms of USB that come over a USB port. > > I wouldn't have much issue with taking a USB drive out of its caddy > to get the SATA drive from inside, except that it would have to be > an amazingly good deal to make it worth voiding the warranty, so I > generally wouldn't bother. Why would it void the warranty? I put it in the caddy > > If I need directly attached storage I'd much rather explore options > like SAS and eSATA, or even networked storage, before I would ever > consider USB for a permanent installation. You need to start thinking outside the box.
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-02-08 22:20 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5jYl-8ON5-7@gated-at.bofh.it> |
| In reply to | #267159 |
On Thu, Feb 08, 2024 at 03:56:19PM -0500, Gremlin wrote: > On 2/8/24 15:43, Andy Smith wrote: > > I wouldn't have much issue with taking a USB drive out of its caddy > > to get the SATA drive from inside, except that it would have to be > > an amazingly good deal to make it worth voiding the warranty, so I > > generally wouldn't bother. > > Why would it void the warranty? I put it in the caddy I mean the USB drives that come as a sealed unit that you can sometimes find a lot cheaper than the same model SATA drive that is actually inside them. Some people do enjoy taking those apart to get the SATA drive out. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-02-08 22:30 +0100 |
| Subject | Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) |
| Message-ID | <I5k82-8OQh-5@gated-at.bofh.it> |
| In reply to | #267162 |
Hello, On Thu, Feb 08, 2024 at 04:22:49PM -0500, Gremlin wrote: > On Thu, Feb 08, 2024 at 08:43:17PM +0000, Andy Smith wrote: > > I really do mean all forms of USB that come over a USB port. > > That line was meant to read > > I really do mean all forms of storage that come over a USB port. > > Changing the goal post now are we..... Erm no, it was a simple mistaken repetition of the word "USB" that I only noticed when I read it back. It would be clearly very difficult to refuse to use any kind of USB device at all! I have been consistently talking about storage devices. You have been very clear that you do not agree though, so let's just agree to disagree. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web