Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #111589 > unrolled thread
| Started by | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| First post | 2025-05-10 11:38 +0000 |
| Last post | 2025-05-20 18:31 -0700 |
| Articles | 20 on this page of 219 — 27 participants |
Back to article view | Back to comp.arch
Is Parallel Programming Hard, And, If So, What Can You Do About It? Thomas Koenig <tkoenig@netcologne.de> - 2025-05-10 11:38 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-11 00:04 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-11 13:59 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Al Kossow <aek@bitsavers.org> - 2025-05-11 07:47 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-11 23:46 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-12 00:30 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-12 01:19 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-12 02:03 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-12 22:34 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Terje Mathisen <terje.mathisen@tmsw.no> - 2025-05-12 08:05 +0200
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-12 08:41 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-12 22:39 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-12 17:14 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-12 22:35 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-12 21:50 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-13 03:03 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-12 23:25 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-13 08:39 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-13 12:55 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-13 07:40 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-13 08:12 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-13 08:33 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-14 00:18 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-13 17:49 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-18 01:35 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-18 14:10 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-18 18:41 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Vir Campestris <vir.campestris@invalid.invalid> - 2025-05-19 21:46 +0100
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-19 14:58 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Vir Campestris <vir.campestris@invalid.invalid> - 2025-05-20 11:22 +0100
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-20 16:38 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 20:49 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-19 00:18 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-19 01:13 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-19 23:33 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-20 00:36 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-20 00:16 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-20 10:49 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-20 12:42 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 11:35 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:29 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-20 20:08 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:46 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 20:58 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-21 12:25 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-21 12:47 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-21 17:19 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-21 15:06 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? George Neuner <gneuner2@comcast.net> - 2025-05-21 22:19 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-22 01:51 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Torbjorn Lindgren <tl@none.invalid> - 2025-05-22 12:12 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-22 12:39 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 22:41 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-22 18:36 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 13:20 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 14:18 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? jseigh <jseigh_es00@xemaps.com> - 2025-05-23 12:34 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 11:39 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-23 14:21 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 15:17 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-23 09:57 -0700
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 17:43 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 19:26 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-24 15:25 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 12:32 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-24 20:36 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Michael S <already5chosen@yahoo.com> - 2025-05-25 00:45 +0300
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 16:54 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Terje Mathisen <terje.mathisen@tmsw.no> - 2025-05-26 22:09 +0200
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-24 21:07 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 17:26 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-05-25 20:24 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-25 20:47 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-25 15:51 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-25 23:23 +0000
Re: recycling "Brian G. Lucas" <bagel99@gmail.com> - 2025-05-24 17:17 -0500
Re: recycling George Neuner <gneuner2@comcast.net> - 2025-05-25 02:24 -0400
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 10:53 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 17:03 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 12:34 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 00:38 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-24 16:57 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 14:24 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Thomas Koenig <tkoenig@netcologne.de> - 2025-05-30 09:20 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-24 20:38 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 16:45 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-05-22 11:32 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 20:54 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 05:39 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 23:42 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-21 02:08 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 13:39 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:57 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-14 13:31 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-14 18:01 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-14 18:12 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Thomas Koenig <tkoenig@netcologne.de> - 2025-05-14 18:45 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? antispam@fricas.org (Waldek Hebisch) - 2025-05-23 00:18 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 05:35 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 01:09 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 12:36 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 11:29 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-24 03:17 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-23 08:28 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-23 17:03 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-24 09:23 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? antispam@fricas.org (Waldek Hebisch) - 2025-05-25 18:05 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-25 12:13 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-25 19:36 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-25 21:23 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-26 17:42 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 11:16 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-26 14:58 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-26 19:19 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 21:52 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-27 08:34 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-27 07:34 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-27 16:19 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-27 20:57 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-28 07:47 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-28 14:50 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 08:48 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 08:46 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-28 12:08 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 09:20 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-28 12:52 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 10:15 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-28 14:16 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 13:37 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-28 22:28 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 16:00 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 14:23 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-29 09:56 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-29 01:54 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-28 12:32 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 13:36 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-26 23:26 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-26 20:31 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 13:45 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-26 23:24 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-25 19:16 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-25 16:27 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-26 03:01 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-25 23:58 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-26 15:36 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-05-26 20:14 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-26 07:13 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 07:31 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? antispam@fricas.org (Waldek Hebisch) - 2025-05-26 19:20 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 14:12 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 01:42 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-29 20:25 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 05:53 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-31 12:53 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-06-02 18:04 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-03 07:14 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-25 15:21 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-26 06:46 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Michael S <already5chosen@yahoo.com> - 2025-05-26 16:06 +0300
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-26 16:30 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 13:00 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 13:04 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 14:15 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 15:20 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 15:40 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 16:02 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 16:07 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Brett <ggtgp@yahoo.com> - 2025-05-27 18:40 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-27 12:28 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-27 12:42 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Brett <ggtgp@yahoo.com> - 2025-05-29 05:10 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 15:31 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Brett <ggtgp@yahoo.com> - 2025-05-30 01:17 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 15:33 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-27 12:28 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-26 23:12 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-26 23:32 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 19:00 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? David Brown <david.brown@hesbynett.no> - 2025-05-27 09:43 +0200
Drive Caches (Re: Is Parallel Programming Hard, ...) Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-05-25 20:55 +0000
Re: Drive Caches (Re: Is Parallel Programming Hard, ...) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-26 00:07 -0400
Re: Drive Caches (Re: Is Parallel Programming Hard, ...) BGB <cr88192@gmail.com> - 2025-05-26 00:59 -0500
Re: Drive Caches (Re: Is Parallel Programming Hard, ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-26 07:13 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 22:19 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-23 20:51 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-17 23:57 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? quadibloc <quadibloc@gmail.com> - 2025-05-19 21:33 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-20 00:43 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 13:53 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-20 13:19 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-20 16:06 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-20 22:11 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? David Schultz <david.schultz@earthlink.net> - 2025-05-20 19:34 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:00 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:34 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? George Neuner <gneuner2@comcast.net> - 2025-05-20 21:30 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-20 18:39 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:41 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? George Neuner <gneuner2@comcast.net> - 2025-05-21 12:09 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-21 15:30 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 02:45 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-21 07:06 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? jseigh <jseigh_es00@xemaps.com> - 2025-05-21 17:32 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-21 07:05 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 02:48 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-21 08:23 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-21 14:08 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 02:49 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-22 17:34 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-22 17:42 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 01:54 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 22:42 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? George Neuner <gneuner2@comcast.net> - 2025-05-22 23:47 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:32 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-20 18:29 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-20 18:04 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-22 16:49 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-22 18:04 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-20 18:31 -0700
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-25 19:16 -0400 |
| Message-ID | <jwvwma47086.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111789 |
> No, when the disk receives a write command, it accepts the write data
> immediately (up to some large limit). That way, when the heads settle on
> the track, if the disk happens to be positioned in the middle of the
> transfer, it can write the last part of the data to the disk immediately,
> then wait for the disk to spin to where the transfer starts to finish the
> transferring the first part of the write data. This reduces average
> latency, i.e. improves performance.
Really? I had the impression that it would be very hard to start writing
from the middle of a sector because of the need to be sure exactly where
in the sector we are. IOW, the drive needs to see the inter-sector markers
before it can start writing to a sector.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-25 16:27 -0700 |
| Message-ID | <1010910$1k3iu$1@dont-email.me> |
| In reply to | #111798 |
On 5/25/2025 4:16 PM, Stefan Monnier wrote: >> No, when the disk receives a write command, it accepts the write data >> immediately (up to some large limit). That way, when the heads settle on >> the track, if the disk happens to be positioned in the middle of the >> transfer, it can write the last part of the data to the disk immediately, >> then wait for the disk to spin to where the transfer starts to finish the >> transferring the first part of the write data. This reduces average >> latency, i.e. improves performance. > > Really? I had the impression that it would be very hard to start writing > from the middle of a sector because of the need to be sure exactly where > in the sector we are. IOW, the drive needs to see the inter-sector markers > before it can start writing to a sector. I am not sure what you mean by sector. If you mean a disk block, typically used to be 512 bytes, now typically 4K bytes, then you are right that you can't start writing in the middle of one. But a track typically has many blocks and you can start writing at any one of them. So if a write is say 16K bytes and you have 4K blocks on the disk, then the drive could start at say the second 4K block, complete the last 12K of the transfer, wait for the rotation then finish the first 4K block. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-26 03:01 +0000 |
| Message-ID | <7f82e47dc3147a3a185ad0615e90874f@www.novabbs.org> |
| In reply to | #111800 |
On Sun, 25 May 2025 23:27:28 +0000, Stephen Fuld wrote: > On 5/25/2025 4:16 PM, Stefan Monnier wrote: >>> No, when the disk receives a write command, it accepts the write data >>> immediately (up to some large limit). That way, when the heads settle >>> on >>> the track, if the disk happens to be positioned in the middle of the >>> transfer, it can write the last part of the data to the disk >>> immediately, >>> then wait for the disk to spin to where the transfer starts to finish >>> the >>> transferring the first part of the write data. This reduces average >>> latency, i.e. improves performance. >> >> Really? I had the impression that it would be very hard to start >> writing >> from the middle of a sector because of the need to be sure exactly where >> in the sector we are. IOW, the drive needs to see the inter-sector >> markers >> before it can start writing to a sector. > > I am not sure what you mean by sector. If you mean a disk block, > typically used to be 512 bytes, now typically 4K bytes, then you are > right that you can't start writing in the middle of one. But a track > typically has many blocks and you can start writing at any one of them. It used to be that the heads were in read-mode looking for the sector start symbol (preamble), before starting to write a sector. > So if a write is say 16K bytes and you have 4K blocks on the disk, > then the drive could start at say the second 4K block, complete the last > 12K of the transfer, wait for the rotation then finish the first 4K > block. > >
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-25 23:58 -0400 |
| Message-ID | <jwvr00c6n3h.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111800 |
> I am not sure what you mean by sector. If you mean a disk block, typically
> used to be 512 bytes, now typically 4K bytes, then you are right that you
> can't start writing in the middle of one.
Yes, that's what I meant.
> But a track typically has many blocks and you can start writing at any
> one of them. So if a write is say 16K bytes and you have 4K blocks
> on the disk, then the drive could start at say the second 4K block,
> complete the last 12K of the transfer, wait for the rotation then
> finish the first 4K block.
Oh, you were talking about a multi-block write command.
It all makes sense now, thank you,
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2025-05-26 15:36 -1000 |
| Message-ID | <87ldqi6dih.fsf@localhost> |
| In reply to | #111800 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: > Yup. And IIRC the IBM 3380 had a linear actuator with two heads per > arm, one covering the outer cylinders, the other the inner > cylinders. The tradeoff was shorter seeks, thus smaller seek time but > higher cost due to more heads. original 3380 had 20 track spacings per data track, they then cut the spacing in half, doubling number of tracks per platter (and double the capacity), then cut it again for triple the number of tracks per platter (and triple capacity). doing some analysis moving data from 3350s to 3380s ... avg 3350 accesses per second divided by drive megabytes ... for avg access/sec/mbyte. 3380 mbytes increased significantly more than avg. access/sec ... could move all 3350 data to much smaller number of 3380s but with much worse performance/throughput. at customer user group get-togethers there were discussions about how to convince bean counters that performance/throughput sensitive data needed to have much higher accesses/sec/mbyte. Eventually IBM offers a 3380 with the 1/3 data track spacing as the original 3380, but only enabled for the same number of tracks as the original 3380 (as a high performance/throughput drive, since head only had to travel 1/3rd as far). other trivia: 2301 fixed head drum was effectively same as 2303 fixed head drum, but transferred four heads in parallel, 1/4 the number of tracks, tracks four times larger and four times the transfer rate (still same avg. rotational delay). late 60s, 2305 fixed head disk first appeared with 360/85 and block mux channels. There were two models, one with single head per track and one with pairs of heads per data track, half the number of data tracks and half the total capacity (same number of total heads). The were offset 180 degrees, and would transfer from both heads concurrently for double the data rate with a quarter avg rotational delay (instead half avg rotational delay), 2305 http://www.bitsavers.org/pdf/ibm/2835/GA26-1589-5_2835_2305_Reference_Oct83.pdf -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Lars Poulsen <lars@cleo.beagle-ears.com> |
|---|---|
| Date | 2025-05-26 20:14 +0000 |
| Message-ID | <slrn1039ist.2qi09.lars@cleo.beagle-ears.com> |
| In reply to | #111798 |
On 2025-05-25, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > I had the impression that it would be very hard to start writing > from the middle of a sector because of the need to be sure exactly where > in the sector we are. IOW, the drive needs to see the inter-sector markers > before it can start writing to a sector. You absolutely cannot start writing in the middle of a sector. A sector is a sequence of bytes written as a unit, with the drive controller adding a preamble on the front (to know that "this is the start of the sector") and a checksum at the end. A *track* may hold a single jumbo sector or several sectors. Between sectors there are gaps (to allow of minute variations in positioning/timing), so fewer sectors per track mean more efficient packing of the data onto the physical area.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-26 07:13 +0000 |
| Message-ID | <10114a8$1t4hg$1@dont-email.me> |
| In reply to | #111789 |
On Sun, 25 May 2025 12:13:08 -0700, Stephen Fuld wrote: > No, when the disk receives a write command, it accepts the write data > immediately (up to some large limit). That way, when the heads settle > on the track, if the disk happens to be positioned in the middle of the > transfer, it can write the last part of the data to the disk > immediately, then wait for the disk to spin to where the transfer starts > to finish the transferring the first part of the write data. This > reduces average latency, i.e. improves performance. But it requires reordering of writes.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-26 07:31 -0700 |
| Message-ID | <1011tv9$21m5v$1@dont-email.me> |
| In reply to | #111811 |
On 5/26/2025 12:13 AM, Lawrence D'Oliveiro wrote: > On Sun, 25 May 2025 12:13:08 -0700, Stephen Fuld wrote: > >> No, when the disk receives a write command, it accepts the write data >> immediately (up to some large limit). That way, when the heads settle >> on the track, if the disk happens to be positioned in the middle of the >> transfer, it can write the last part of the data to the disk >> immediately, then wait for the disk to spin to where the transfer starts >> to finish the transferring the first part of the write data. This >> reduces average latency, i.e. improves performance. > > But it requires reordering of writes. No, it doesn't. In my earlier post, I showed how with just using the DRAM for buffering, not caching, it is still advantageous to take the write data with the command, as it may allow you to complete the write faster if, when the heads come on cylinder, it happens to be in the middle of the transfer. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-05-26 19:20 +0000 |
| Message-ID | <1012euo$1fclb$1@paganini.bofh.team> |
| In reply to | #111789 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> On 5/25/2025 11:05 AM, Waldek Hebisch wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>> On 5/23/2025 2:03 PM, Stefan Monnier wrote:
>>>> Stephen Fuld [2025-05-23 08:28:44] wrote:
>>>>> On 5/22/2025 5:18 PM, Waldek Hebisch wrote:
>>>>>> It is pretty clear that due to drive mechanics track cache/buffer
>>>>>> is useful.
>>>>> Pretty clear to everyone except one person. :-)
>>>>
>>>> 🙂
>>>>
>>>>>> However, the real question is about size: how big
>>>>>> should it be. For "consumer" drives I see claims of 256 MB
>>>>>> cache. Given rather optimistic 200 MB/s transfer rate it is
>>>>>> about 1.25s of drive data, that is 80-150 rotations. I would
>>>>>> expect that say 4 tracks should be enough for reading. For
>>>>>> writing one could use few more tracks. Still, advertised cache
>>>>>> sizes seem to be much bigger than necessary.
>>>>> It's not just the rotations, but the seek time. So your example is fewer
>>>>> "operations" than the 80-150 you get when just including rotations.
>>>>
>>>> I don't understand what you're getting at, here.
>>>> I think Waldek's argument is that 256MB corresponds approximately
>>>> to the amount of data stored in 80-150 tracks, and seek time doesn't
>>>> change that fact.
>>>
>>> Yes, I didn't express myself well. :-( And once again, I have to say
>>> that my information may be obsolete.
>>>
>>> I think it is useful to separate talking about read data from write
>>> data. For read data, as with any cache, more is always better than
>>> less, though with diminishing returns. Why pick 1.25 sec as the "cut
>>> off point"? If the host re-references data that it hasn't read for say
>>> 3 seconds, having it in cache still saves, probably a seek time and on
>>> average 1/2 rotation time. Plus, it means the heads will be free to
>>> handle other requests. All of this is standard cache benefits. I see
>>> no reason to limit the cache size and reduce this benefit.
>>
>> We are talking here about common case, that is when disc is accessed
>> via OS cache. OS cache is significantly larger than disc cache, so
>> hit ratio for data sent to host is going to be quite low. Disc
>> cache has an advantage: it gets "for free" some data that host did
>> not request. But it is rather unlikely that keeping such data
>> for long time has significant advantage.
>>
>>>>> And if you are caching writes, more cache gives you more blocks to choose
>>>>> from when optimizing the write back order, which reduces the time to write
>>>>> them all back.
>>>>
>>>> IIUC, for SATA drives, NCQ is still limited to 32 in-flight commands, so
>>>> unless the drive is allowed to do write-back caching it seems the amount
>>>> of space used for write-buffering is likely small (compared to 256MB).
>>>> [ Unless it is common for individual write commands to cover multi-MB
>>>> chunks of data? ]
>>>
>>>
>>> For write data, I was unaware of the 32 operation limit. I was used to
>>> SCSI, which, IIRC was larger, and for server type applications, where
>>> some sort of UPS is more common, the site may choose to enable write
>>> caching in the disk. For a disk vendor, given the small cost of the
>>> DRAM, it is an easy choice.
>>
>> I do not look at details of disc protocol. But with protocal done
>> right host would first transfer commands and then deliver data
>> in order requested by the drive. So most buffering would be in
>> the host and disc would need just enough buffering to ensure
>> smooth transmission and low interrupt rate. 4 track looks like
>> plenty for this purpose.
>
> No, when the disk receives a write command, it accepts the write data
> immediately (up to some large limit). That way, when the heads settle
> on the track, if the disk happens to be positioned in the middle of the
> transfer, it can write the last part of the data to the disk
> immediately, then wait for the disk to spin to where the transfer starts
> to finish the transferring the first part of the write data. This
> reduces average latency, i.e. improves performance.
Latency of writes typically is of little importance, host buffers
several seconds of of write data and writes only after delay
(ratinale for this is that data may be overwritten, by dealying
host may avoid actual disc operation). To allow scheduling in
the drive one wants commands to be sent as fast as possible.
Sending possibly bulky write data before sending next command
looks counterpoductive. There could be some data that host
wants to be in persistent storage as fast as possible, but
making it the only option clearly would be a design error in
the disc protocol.
>>>>> The larger DRAM is a small component of drive cost, so the
>>>>> manufacturers think it is worth including more.
>>>>
>>>> In some markets (e.g. home routers), the size of DRAM seems to be enough
>>>> of a cost factor that it took many years until reaching 256MBs, even
>>>> though those boxes *need* that RAM for all kinds of purposes (the 128MB
>>>> of my current home-router seems to be its main source of instability).
>>>> but HDDs are pretty damn expensive beasts nowadays (because prices have
>>>> not gone down for the last 10 years or so), so I guess that makes
>>>> the relative cost of 512MB of DRAM "negligible"?
>>>
>>> I can't comment on routers, but for disks, while the cost of the disk
>>> may not have come down, increasing capacity allows reduced cost per
>>> gigabyte. A substantial portion of the cost is not subject to Moore's
>>> law (e.g. drive motor, magnets and arm assembly, etc.) and some capacity
>>> increasing technologies cost more (but not enough more to overwhelm the
>>> capacity advantage).
>>
>> In nineties I read that for motherboard manufactures 1 cent was
>> "negligible", but 10 cents was significant: In volume transactions
>> margins were low and no party were willing to absorb 10 cents
>> per piece "loss". Discs probably are less competitive than
>> motherboards, but I would expect adding 256 MB to lead to 1
>> dollar or more increase of cost.
>
> I can't comment on your specific numbers, but assuming you are right,
> adding $1 to the cost is is small, at least in the part of the market I
> was familiar with. And remember, you are not "adding" 256MB, as some of
> that is needed for various internal operations.
Generously, buffering could do with about 8MB. I am not sure
how drives handle bad sector map, that potentially could be
quite large. But in principle drive could read infor about bad
sectors from the track, keeping in RAM only info about say bad
tracks and current track. In such case I see no reason for
large internal RAM.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-26 14:12 -0700 |
| Message-ID | <1012lf9$23l9t$2@dont-email.me> |
| In reply to | #111822 |
On 5/26/2025 12:20 PM, Waldek Hebisch wrote: > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote: >> On 5/25/2025 11:05 AM, Waldek Hebisch wrote: >>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote: >>>> On 5/23/2025 2:03 PM, Stefan Monnier wrote: >>>>> Stephen Fuld [2025-05-23 08:28:44] wrote: >>>>>> On 5/22/2025 5:18 PM, Waldek Hebisch wrote: >>>>>>> It is pretty clear that due to drive mechanics track cache/buffer >>>>>>> is useful. >>>>>> Pretty clear to everyone except one person. :-) >>>>> >>>>> 🙂 >>>>> >>>>>>> However, the real question is about size: how big >>>>>>> should it be. For "consumer" drives I see claims of 256 MB >>>>>>> cache. Given rather optimistic 200 MB/s transfer rate it is >>>>>>> about 1.25s of drive data, that is 80-150 rotations. I would >>>>>>> expect that say 4 tracks should be enough for reading. For >>>>>>> writing one could use few more tracks. Still, advertised cache >>>>>>> sizes seem to be much bigger than necessary. >>>>>> It's not just the rotations, but the seek time. So your example is fewer >>>>>> "operations" than the 80-150 you get when just including rotations. >>>>> >>>>> I don't understand what you're getting at, here. >>>>> I think Waldek's argument is that 256MB corresponds approximately >>>>> to the amount of data stored in 80-150 tracks, and seek time doesn't >>>>> change that fact. >>>> >>>> Yes, I didn't express myself well. :-( And once again, I have to say >>>> that my information may be obsolete. >>>> >>>> I think it is useful to separate talking about read data from write >>>> data. For read data, as with any cache, more is always better than >>>> less, though with diminishing returns. Why pick 1.25 sec as the "cut >>>> off point"? If the host re-references data that it hasn't read for say >>>> 3 seconds, having it in cache still saves, probably a seek time and on >>>> average 1/2 rotation time. Plus, it means the heads will be free to >>>> handle other requests. All of this is standard cache benefits. I see >>>> no reason to limit the cache size and reduce this benefit. >>> >>> We are talking here about common case, that is when disc is accessed >>> via OS cache. OS cache is significantly larger than disc cache, so >>> hit ratio for data sent to host is going to be quite low. Disc >>> cache has an advantage: it gets "for free" some data that host did >>> not request. But it is rather unlikely that keeping such data >>> for long time has significant advantage. >>> >>>>>> And if you are caching writes, more cache gives you more blocks to choose >>>>>> from when optimizing the write back order, which reduces the time to write >>>>>> them all back. >>>>> >>>>> IIUC, for SATA drives, NCQ is still limited to 32 in-flight commands, so >>>>> unless the drive is allowed to do write-back caching it seems the amount >>>>> of space used for write-buffering is likely small (compared to 256MB). >>>>> [ Unless it is common for individual write commands to cover multi-MB >>>>> chunks of data? ] >>>> >>>> >>>> For write data, I was unaware of the 32 operation limit. I was used to >>>> SCSI, which, IIRC was larger, and for server type applications, where >>>> some sort of UPS is more common, the site may choose to enable write >>>> caching in the disk. For a disk vendor, given the small cost of the >>>> DRAM, it is an easy choice. >>> >>> I do not look at details of disc protocol. But with protocal done >>> right host would first transfer commands and then deliver data >>> in order requested by the drive. So most buffering would be in >>> the host and disc would need just enough buffering to ensure >>> smooth transmission and low interrupt rate. 4 track looks like >>> plenty for this purpose. >> >> No, when the disk receives a write command, it accepts the write data >> immediately (up to some large limit). That way, when the heads settle >> on the track, if the disk happens to be positioned in the middle of the >> transfer, it can write the last part of the data to the disk >> immediately, then wait for the disk to spin to where the transfer starts >> to finish the transferring the first part of the write data. This >> reduces average latency, i.e. improves performance. > > Latency of writes typically is of little importance, host buffers > several seconds of of write data and writes only after delay > (ratinale for this is that data may be overwritten, by dealying > host may avoid actual disc operation). That makes sense, but even if the advantage is small, the cost is essentially zero, so why not do it. > To allow scheduling in > the drive one wants commands to be sent as fast as possible. > Sending possibly bulky write data before sending next command > looks counterpoductive. Note that I did say, "up to some large limit" above. > There could be some data that host > wants to be in persistent storage as fast as possible, but > making it the only option clearly would be a design error in > the disc protocol. I think we switched topics. The decision to accept write data immediately after the write command is independent of whether or not to present completion status before the data is on the persistent media (the disk). snip >> >> I can't comment on your specific numbers, but assuming you are right, >> adding $1 to the cost is is small, at least in the part of the market I >> was familiar with. And remember, you are not "adding" 256MB, as some of >> that is needed for various internal operations. > > Generously, buffering could do with about 8MB. I am not sure > how drives handle bad sector map, that potentially could be > quite large. My now standard caveat, but different vendors do it differently. And there is a difference between bad sectors detected in initial formatting (at the factory) versus detected in normal operation. > But in principle drive could read infor about bad > sectors from the track, keeping in RAM only info about say bad > tracks and current track. In such case I see no reason for > large internal RAM. The bad sector map is usually kept on a "hidden" area of the disk, read into RAM at power-on, and written back to disk if it is changed due to a newly bad sector encountered. Consider a possible algorithm for when you get a request to mark a sector bad. You don't want the host to have to keep a bad sector map, and you want to minimize the performance disruption on future read and write operations, so you want to "push" the data from all the sectors from the bad one until the first available spare sector. That could be on the same track or different track on the same cylinder. In order to minimize the time to do that, you use RAM to temporarily hold the data being pushed. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-30 01:42 +0000 |
| Message-ID | <101b2dk$4vts$2@dont-email.me> |
| In reply to | #111833 |
On Mon, 26 May 2025 14:12:09 -0700, Stephen Fuld wrote: > That makes sense, but even if the advantage is small, the cost is > essentially zero, so why not do it. Additional complexity, leading to additional points of failure.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-29 20:25 -0700 |
| Message-ID | <101b8ei$a20i$1@dont-email.me> |
| In reply to | #111890 |
On 5/29/2025 6:42 PM, Lawrence D'Oliveiro wrote: > On Mon, 26 May 2025 14:12:09 -0700, Stephen Fuld wrote: > >> That makes sense, but even if the advantage is small, the cost is >> essentially zero, so why not do it. > > Additional complexity, leading to additional points of failure. I was too flip in my answer, so here is, I think, a better one. The "it" to which we are referring here is caching of write data. So let's look at a possible scenario. Let's say the heads are at cylinder 100. A write comes in for data that is at cylinder 300. Without write caching, the disk will move the heads to cylinder 300. Now lets say the next request is a read for data at cylinder 150. If the write had been cached, the disk can handle the read with only a 50 cylinder move, then the write with a 150 cylinder move for a total of 200 cylinders. Without write caching, the first move is 200 cylinders for the write, followed by 150 back for the read for a total of 350. Thus the read data, which is presumably more time critical, is delayed. Overall, write caching improves performance, but if you don't want it, then you can essentially not use it, either by forcing the writes to go to the media, or not using command queuing at all. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-30 05:53 +0000 |
| Message-ID | <101bh3t$bcd6$2@dont-email.me> |
| In reply to | #111891 |
On Thu, 29 May 2025 20:25:05 -0700, Stephen Fuld wrote: > On 5/29/2025 6:42 PM, Lawrence D'Oliveiro wrote: >> >> On Mon, 26 May 2025 14:12:09 -0700, Stephen Fuld wrote: >> >>> That makes sense, but even if the advantage is small, the cost is >>> essentially zero, so why not do it. >> >> Additional complexity, leading to additional points of failure. > > The "it" to which we are referring here is caching of write data. So was I.
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2025-05-31 12:53 -1000 |
| Message-ID | <87y0uc8k8o.fsf@localhost> |
| In reply to | #111891 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: > I was too flip in my answer, so here is, I think, a better one. The > "it" to which we are referring here is caching of write data. > > So let's look at a possible scenario. Let's say the heads are at > cylinder 100. A write comes in for data that is at cylinder > 300. Without write caching, the disk will move the heads to cylinder > 300. Now lets say the next request is a read for data at cylinder 150. > If the write had been cached, the disk can handle the read with only a > 50 cylinder move, then the write with a 150 cylinder move for a total > of 200 cylinders. Without write caching, the first move is 200 > cylinders for the write, followed by 150 back for the read for a total > of 350. Thus the read data, which is presumably more time critical, is > delayed. > > Overall, write caching improves performance, but if you don't want it, > then you can essentially not use it, either by forcing the writes to > go to the media, or not using command queuing at all. Early 70s, as mainstream IBM was converting everything to virtual memory, I got into a battle. Somebody came up with a (LRU?) page replacement algorithm that would replace non-changed pages (didn't require a write before the read replacement) before changed pages (which needed a write before being able to fetch the needed page). Nearly a decade later, they finally realized that they were replacing highly used, highly shared RO/non-changed pages ... before replacing, private, single-task, changed data page (before they realized it was possible to keep a pool of immediately available, changed pages that had been pre-written). ATM financial started using the IBM (airline) TPF operating system ... light-weight but had simple ordered arm queuing algorithm for reads/updates/writes. Then a little later in 70s an IBM tech in LA at a financial institution redid it looking at ATM use history and anticipating account requests (that would result in reads/updates/writes ordering that hadn't happened yet). Under heavy load, it improved aggregate throughput (and under lighter load it make little difference) ... sort of delaying a 300cyl seek anticipating likelyhood of transaction (as yet to happen), that would involve a shorter seek. since sometime in the 80s, (at least) RDBMS have been using "write caching" (write behind) where the sequential log/journal of "committed" transactions is made and actual RDBMS writes happen in the background. Failure recovery requires rereading the log and forcing pending writes for committed transactions. Originally in cluster environment, any (RDBNS) pending writes for transaction lock request from a different system would force pending writes before granting a different system the requested lock. I did a hack where I could append queued/pending writes to passing the transaction lock to a different system ... in the era of mbyte (shared, multi-system, cluster) disks and gbyte interconnect. -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-06-02 18:04 +0000 |
| Message-ID | <101kp3e$12tt$1@gal.iecc.com> |
| In reply to | #111909 |
According to Lynn Wheeler <lynn@garlic.com>: >Early 70s, as mainstream IBM was converting everything to virtual >memory, I got into a battle. Somebody came up with a (LRU?) page >replacement algorithm that would replace non-changed pages (didn't >require a write before the read replacement) before changed pages (which >needed a write before being able to fetch the needed page). Nearly a >decade later, they finally realized that they were replacing highly >used, highly shared RO/non-changed pages ... before replacing, private, >single-task, changed data page (before they realized it was possible to >keep a pool of immediately available, changed pages that had been >pre-written). They didn't look at the page reference bits? They were added to S/370 I would think specifically to avoid this mistake. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-06-03 07:14 +0000 |
| Message-ID | <101m7df$3sba8$1@dont-email.me> |
| In reply to | #111909 |
On Sat, 31 May 2025 12:53:59 -1000, Lynn Wheeler wrote: > since sometime in the 80s, (at least) RDBMS have been using "write > caching" (write behind) where the sequential log/journal of "committed" > transactions is made and actual RDBMS writes happen in the background. > Failure recovery requires rereading the log and forcing pending writes > for committed transactions. You need a guarantee that the journal entries have been safely written before doing the corresponding record data updates. Otherwise bad things can happen. Journalled filesystems provide data integrity guarantees in the same sort of way.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-25 15:21 -0500 |
| Message-ID | <100vuf8$1icjh$1@dont-email.me> |
| In reply to | #111788 |
On 5/25/2025 1:05 PM, Waldek Hebisch wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>> On 5/23/2025 2:03 PM, Stefan Monnier wrote:
>>> Stephen Fuld [2025-05-23 08:28:44] wrote:
>>>> On 5/22/2025 5:18 PM, Waldek Hebisch wrote:
>>>>> It is pretty clear that due to drive mechanics track cache/buffer
>>>>> is useful.
>>>> Pretty clear to everyone except one person. :-)
>>>
>>> 🙂
>>>
>>>>> However, the real question is about size: how big
>>>>> should it be. For "consumer" drives I see claims of 256 MB
>>>>> cache. Given rather optimistic 200 MB/s transfer rate it is
>>>>> about 1.25s of drive data, that is 80-150 rotations. I would
>>>>> expect that say 4 tracks should be enough for reading. For
>>>>> writing one could use few more tracks. Still, advertised cache
>>>>> sizes seem to be much bigger than necessary.
>>>> It's not just the rotations, but the seek time. So your example is fewer
>>>> "operations" than the 80-150 you get when just including rotations.
>>>
>>> I don't understand what you're getting at, here.
>>> I think Waldek's argument is that 256MB corresponds approximately
>>> to the amount of data stored in 80-150 tracks, and seek time doesn't
>>> change that fact.
>>
>> Yes, I didn't express myself well. :-( And once again, I have to say
>> that my information may be obsolete.
>>
>> I think it is useful to separate talking about read data from write
>> data. For read data, as with any cache, more is always better than
>> less, though with diminishing returns. Why pick 1.25 sec as the "cut
>> off point"? If the host re-references data that it hasn't read for say
>> 3 seconds, having it in cache still saves, probably a seek time and on
>> average 1/2 rotation time. Plus, it means the heads will be free to
>> handle other requests. All of this is standard cache benefits. I see
>> no reason to limit the cache size and reduce this benefit.
>
> We are talking here about common case, that is when disc is accessed
> via OS cache. OS cache is significantly larger than disc cache, so
> hit ratio for data sent to host is going to be quite low. Disc
> cache has an advantage: it gets "for free" some data that host did
> not request. But it is rather unlikely that keeping such data
> for long time has significant advantage.
>
>>>> And if you are caching writes, more cache gives you more blocks to choose
>>>> from when optimizing the write back order, which reduces the time to write
>>>> them all back.
>>>
>>> IIUC, for SATA drives, NCQ is still limited to 32 in-flight commands, so
>>> unless the drive is allowed to do write-back caching it seems the amount
>>> of space used for write-buffering is likely small (compared to 256MB).
>>> [ Unless it is common for individual write commands to cover multi-MB
>>> chunks of data? ]
>>
>>
>> For write data, I was unaware of the 32 operation limit. I was used to
>> SCSI, which, IIRC was larger, and for server type applications, where
>> some sort of UPS is more common, the site may choose to enable write
>> caching in the disk. For a disk vendor, given the small cost of the
>> DRAM, it is an easy choice.
>
> I do not look at details of disc protocol. But with protocal done
> right host would first transfer commands and then deliver data
> in order requested by the drive. So most buffering would be in
> the host and disc would need just enough buffering to ensure
> smooth transmission and low interrupt rate. 4 track looks like
> plenty for this purpose.
>
>>>> The larger DRAM is a small component of drive cost, so the
>>>> manufacturers think it is worth including more.
>>>
>>> In some markets (e.g. home routers), the size of DRAM seems to be enough
>>> of a cost factor that it took many years until reaching 256MBs, even
>>> though those boxes *need* that RAM for all kinds of purposes (the 128MB
>>> of my current home-router seems to be its main source of instability).
>>> but HDDs are pretty damn expensive beasts nowadays (because prices have
>>> not gone down for the last 10 years or so), so I guess that makes
>>> the relative cost of 512MB of DRAM "negligible"?
>>
>> I can't comment on routers, but for disks, while the cost of the disk
>> may not have come down, increasing capacity allows reduced cost per
>> gigabyte. A substantial portion of the cost is not subject to Moore's
>> law (e.g. drive motor, magnets and arm assembly, etc.) and some capacity
>> increasing technologies cost more (but not enough more to overwhelm the
>> capacity advantage).
>
> In nineties I read that for motherboard manufactures 1 cent was
> "negligible", but 10 cents was significant: In volume transactions
> margins were low and no party were willing to absorb 10 cents
> per piece "loss". Discs probably are less competitive than
> motherboards, but I would expect adding 256 MB to lead to 1
> dollar or more increase of cost.
>
Dunno, I would maybe expect an 8 or 16MB chip, unless either:
Tracks have become so large that large RAM is needed to deal with them;
These larger RAM chips have actually become the cheapest usable option.
Had noted a correlation between RAM type and module size on FPGA boards:
512K/1MB: QSPI
32/64 MB: SDR SDRAM
64/128MB: DDR1
128MB: DDR2
256MB: DDR3
So, maybe, this is the cheapest commodity option if they want a given
RAM type.
Like, for example, when I was last looking at SDcards, 16GB was the
cheapest option being sold.
Smaller sizes had fallen off the bottom, and plenty of larger sizes
existed (say, 128 or 256GB).
So, even if a 4 or 8 GB SDcard would be sufficient, 16GB was what was
available (in the projects I was doing, typically the biggest file on
the SDcard ended up being the swapfile...).
> So IMO it is highly unclear why manufacturers use large caches.
> One possible explanation could be benchmarketing and using
> obsolete benchmarks. Another could be inertia with customers
> thinking that "larger cache is better".
>
Cache, and RPM, probably...
> Another things is fragmenting market into different "kinds" of
> drives. Rationally, high performance drives should get
> better mechanical parts. But in given performance area there
> seem to be no reason for different mechanics, so I suspect
> that they use the same. They may get different firmware.
> "Green" consumer parts seem to be quite aggressive powering
> down (IIUC on recent WD parts it is impossible to permanently
> disable this), but beyond this it is not clear to me if there
> are rational reasons for significantly different firmware.
>
My experience:
WD Green, Power-use optimized
Drives worked pretty well, but WD seemingly phased it out for HDDs.
WD Green is back, but mostly for SSDs.
WD Blue, marked as general purpose;
Not great and worse reliability IME.
Seems to be actually the more "budget optimized" line.
WD Black, marketed as performance optimized.
Typically 7200RPM
Not much notable difference IME from the WD Reds
WD Red, optimized for NAS
Typically 5400RPM
Have had mostly good results with these.
WD Purple, optimized for video usage and similar.
Typically 5400RPM.
No first hand experience.
Doesn't seem to be an obvious difference in cache sizes between the
drive families.
There does seem to be a weak positive correlation between cache size and
drive size.
RPM seems to be negatively correlated with capacity:
10K RPM: Seemingly mostly under 1TB
7200RPM, mostly 1TB to 4TB drives
5400RPM, most of the bigger drives.
In my use, I had seemingly been seeing the best results from WD Red drives.
As for the specifics of what they have tuned exactly, I am not sure.
Did see claims that there are apparently no real functional differences
between WD Red and WD Purple drives.
Though, apparently the WD Purple drives do have more going on in terms
of corrosion resistance (possibly hydrophobic coatings or similar?, for
whatever reason...). Marketing doesn't seem to say anything about being
optimized for use in damp conditions though.
But, dampness and oil resistance could make sense if one had an
"industrial use" optimized drive. But, in this case, would likely expect
a sealed drive with something like a butyl rubber and/or PTFE coating,
and possibly gold plated contacts (well, and/or a 2.5" HDD inside of a
special 3.5" enclosure, made from PTFE and butyl rubber and TPU, also
optimizing for shock resistance, *1).
*1: Say, if you had an HDD that was designed to be thrown around the
room and subjected to other high G-force shocks, while also being
periodically submerged in water, oil, and various corrosive liquids.
Outer shell could be mostly PTFE, possibly then PET, butyl, then TPU,
possibly with some internal heat-transfer structures (possibly a small
heat pump), with gold contacts, circuits to protect from voltage
transients, ... Bonus points if it can also withstand operating at high
pressures (such as being sunk to the bottom of the ocean, and/or driven
over by a car or large truck, ...).
Though this implies that the enclosure partly be made out of stainless
steel or similar, probably still with a PTFE outer layer (where, PTFE
has a stronger chemical resistance than stainless steel, but stainless
steel would be needed for crush resistance).
So, layers (outer to inner): PTFE (first line chemical defense),
Stainless (crush resistance), PTFE (physical damage + corrosives), butyl
(shock, second line chem), TPU (shock). Then, a small heat pump between
the inner HDD and stainless shell (likely primarily PTFE construction).
Well, sadly, even with all this, it would still not likely be able to
operate in Venus-like conditions (if the first layer of PTFE got damaged
and/or the heat pump were insufficient). Chances could maybe be improved
here if one added an gold or iridium coating to the stainless steel
layer, and possibly using 316 stainless (say, if the PTFE gets
scratched, the stainless doesn't get corroded by all the sulfuric acid,
if the coating is breached, 316 would at least corrode slower than 304,
...).
Gold contacts have decent chemical resistance. Iridium has stronger
chemical and thermal resistance than gold, but is also more expensive.
While cheaper and moderately chemical resistant, lead would be
insufficient for Venus like conditions. Though, in these conditions,
loss of power would also ruin the drive (I would not expect the drive
proper to survive direct exposure to 230C temperatures, ...).
Though, such a thing would unlikely be a mass-market device (would
likely be impractically expensive).
...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-05-26 06:46 +0000 |
| Message-ID | <2025May26.084601@mips.complang.tuwien.ac.at> |
| In reply to | #111788 |
antispam@fricas.org (Waldek Hebisch) writes: >Discs probably are less competitive than >motherboards, I expect them to be just as competetive as motherboards, at least in the past. The fact that there are only 2-3 surviving HDD manufacturers indicates intense competition in the past, possible less today. >but I would expect adding 256 MB to lead to 1 >dollar or more increase of cost. What makes you think so. The DRAM chips on DDR4 DIMMs today hold 512MB (x8->4GB DIMM) up to 2GB (x16->32GB DIMM). There are 2GB DDR3 DIMMs (using 256MB chips), but they do not cost less than 4GB DDR3 DIMMs. Choosing a DRAM cache of 256MB rather than 512MB is unlikely to save even one cent. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-05-26 16:06 +0300 |
| Message-ID | <20250526160658.0000347d@yahoo.com> |
| In reply to | #111810 |
On Mon, 26 May 2025 06:46:01 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > antispam@fricas.org (Waldek Hebisch) writes: > >Discs probably are less competitive than > >motherboards, > > I expect them to be just as competetive as motherboards, at least in > the past. The fact that there are only 2-3 surviving HDD > manufacturers indicates intense competition in the past, possible less > today. > > >but I would expect adding 256 MB to lead to 1 > >dollar or more increase of cost. > > What makes you think so. The DRAM chips on DDR4 DIMMs today hold > 512MB (x8->4GB DIMM) up to 2GB (x16->32GB DIMM). There are 2GB DDR3 > DIMMs (using 256MB chips), but they do not cost less than 4GB DDR3 > DIMMs. Choosing a DRAM cache of 256MB rather than 512MB is unlikely > to save even one cent. > > - anton You are projecting computer memory prices on very different market. The memory used for HD cache is likely an individual memory chip or two chips and likely several generation older than devices used in computer DIMMs. I would expect something like x16 DDR3. Looking for price of such devices on Mauser I see following figures: 1 Gbit - $2.10 2 Gbit - $2.60 4 Gbit - $2.90 So, even assuming that disk manufacturer pays 1.5x to 2x less than what we see on Mauser, there exists measurable difference between 128, 256 and 512 MB. The difference is smaller than suggested by Waldek but much bigger than suggested by yourself.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-05-26 16:30 +0000 |
| Message-ID | <2025May26.183020@mips.complang.tuwien.ac.at> |
| In reply to | #111813 |
Michael S <already5chosen@yahoo.com> writes:
>You are projecting computer memory prices on very different market.
>The memory used for HD cache is likely an individual memory chip or two
>chips and likely several generation older than devices used in computer
>DIMMs. I would expect something like x16 DDR3. Looking for price of
>such devices on Mauser I see following figures:
>1 Gbit - $2.10
>2 Gbit - $2.60
>4 Gbit - $2.90
>So, even assuming that disk manufacturer pays 1.5x to 2x less than what
>we see on Mauser, there exists measurable difference between 128, 256
>and 512 MB.
My experience with Mauser prices suggest a much higher factor (but I
am too lazy to look up Chinese dealers on Aliexpress), and their
prices do not necessarily reflect a constant factor markup above their
buying price.
The business model of PC-part dealers has less markup than Mauser,
therefore I think the DIMM prices are a better indicator of what DRAM
chips cost.
Concerning x16 chips vs. x8 chips, I don't expect them to have much
difference in cost, and in a highly competetive market like DRAM,
consequently not much difference in price. And in any case, the
difference will be a constant cost offset for different DRAM sizes.
Ok, looking at DDR3 DIMM prices and discounting dealers that are far
cheaper than the meanstream (those dealers are probably just selling
off DIMMs that they got for cheap from OEM surplus or somesuch), I see
the following prices
<https://geizhals.eu/?cat=ramddr3&xf=1454_1024%7E1454_2048%7E1454_4096%7E256_1x%7E5828_DDR3>
DIMM chip EUR
2GB 8x2Gb 10 https://geizhals.eu/v7-dimm-2gb-v7128002gbd-a1528958.html
4GB 8x4Gb 12 https://geizhals.eu/patriot-signature-line-so-dimm-4gb-psd34g16002s-a624676.html
Only 2 1GB DIMMs are offered, by one dealer each, the cheapest at EUR
17. So it apparently no longer pays off to produce them; the cost
advantage of the smaller chips is too small.
Looking at the price difference between 2GB and 4GB DIMMs, this would
indicate a difference of EUR 0.25 per chip. But of course that
includes the distribution cost and VAT, so the difference for the
manufacturer may be in the area of EUR 0.1.
While I am at it: On <https://geizhals.eu/?cat=hde7s> I see for HDDs:
cache #drives #drives
#drives size >=20TB 10TB-18TB
1585 >=2MB
1579 >=8MB
1397 >=16MB
1248 >=32MB
1150 >=64MB
863 >=128MB 247
599 >=256MB 72 246
172 >=512MB 65 83
So they spend the extra buffer on the newest and most expensive
drives, while older drives often make do with less buffering. My
guess is that this reflects the prices of the DRAM chips at design
time, and there may be some thought given to the target price of the
HDD and the availability of the DRAM chips while the drive will be
manufactured.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.arch
csiph-web