Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #24329 > unrolled thread
| Started by | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| First post | 2016-06-24 13:37 -0500 |
| Last post | 2016-07-14 20:44 +0000 |
| Articles | 20 on this page of 196 — 27 participants |
Back to article view | Back to comp.arch.embedded
Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-24 13:37 -0500
Re: Common name for a "Task Loop" Lanarcam <lanarcam1@yahoo.fr> - 2016-06-24 21:04 +0200
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-24 15:21 -0500
Re: Common name for a "Task Loop" Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-06-24 22:46 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-24 14:51 -0500
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-24 15:10 -0500
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-24 20:11 +0000
Re: Common name for a "Task Loop" gtwrek@sonic.net (Mark Curry) - 2016-06-24 20:31 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-24 13:21 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-24 18:31 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-24 17:03 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-25 10:52 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 01:07 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-25 14:00 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 08:27 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-25 15:50 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 14:45 -0700
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-25 17:28 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 00:40 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 12:41 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-25 15:46 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 14:42 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-25 15:43 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 14:36 -0700
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-25 17:25 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 00:14 -0700
Re: Common name for a "Task Loop" Paul Rubin <no.email@nospam.invalid> - 2016-06-24 14:00 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 15:27 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 09:41 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-25 17:59 +0000
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-25 16:24 -0500
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:36 +0000
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-26 19:00 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-27 05:53 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-27 09:43 -0500
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-28 02:39 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 15:08 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-26 23:54 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 18:12 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-06-28 02:54 +0000
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-28 06:20 +0300
Re: Common name for a "Task Loop" raimond.dragomir@gmail.com - 2016-06-27 22:57 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-28 09:40 -0500
Re: Common name for a "Task Loop" Mel Wilson <mwilson@the-wire.com> - 2016-06-28 15:38 +0000
Re: Common name for a "Task Loop" raimond.dragomir@gmail.com - 2016-06-28 08:57 -0700
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 16:49 +0000
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-28 15:35 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 13:54 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 14:04 -0700
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 21:09 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 15:14 -0700
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 22:30 +0000
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 16:06 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 16:18 -0700
Re: Common name for a "Task Loop" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-06-29 01:32 +0200
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 01:00 +0300
Re: Common name for a "Task Loop" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-06-29 00:20 +0200
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:07 +0300
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-28 22:21 +0000
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:20 +0300
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-06-28 17:39 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:29 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-29 09:50 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 15:43 -0700
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-29 02:40 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 16:56 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-29 08:04 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 23:22 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-30 09:02 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-30 02:33 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-02 14:27 +0300
Re: Common name for a "Task Loop" Wouter van Ooijen <wouter@voti.nl> - 2016-07-02 14:50 +0200
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-02 20:18 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-02 07:36 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-02 21:44 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-02 14:36 -0700
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-03 06:23 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-03 00:43 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-29 11:36 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-29 09:55 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-29 12:53 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-29 11:29 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-29 13:41 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-29 11:49 -0700
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-02 20:48 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-03 03:07 -0500
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-03 08:06 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-03 12:39 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-03 21:44 +0300
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-03 16:39 -0700
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-03 23:57 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-04 14:39 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-05 06:04 +0300
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-07-05 11:58 -0500
Re: Common name for a "Task Loop" Reinhardt Behm <rbehm@hushmail.com> - 2016-07-06 10:39 +0800
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-07-06 10:11 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-05 21:57 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-05 12:20 -0700
Re: Common name for a "Task Loop" Richard Damon <Richard@Damon-Family.org> - 2016-07-04 10:08 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-05 11:59 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-05 22:51 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-05 13:16 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-06 11:31 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-06 03:06 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-06 21:37 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-07 00:50 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-06 23:16 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-07 21:36 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-07 12:06 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-07 23:09 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-07-08 11:06 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 12:50 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-08 23:33 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 16:40 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-08 23:47 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 16:48 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 21:37 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-09 14:26 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 00:48 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-10 03:29 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-11 06:51 +0300
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-11 16:11 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-11 12:04 -0500
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-12 11:31 +0300
Re: Common name for a "Task Loop" mac <acolvin@efunct.com> - 2016-07-12 15:08 +0000
Re: Common name for a "Task Loop" Robert Wessel <robertwessel2@yahoo.com> - 2016-07-12 21:24 -0500
Memory scrubbing [Was Re: Common name for a "Task Loop"] Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-12 21:11 +0300
Re: Common name for a "Task Loop" Robert Wessel <robertwessel2@yahoo.com> - 2016-07-12 21:11 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-08 23:35 +0300
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-08 23:54 +0300
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-09 09:34 +0300
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-09 10:28 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-09 14:39 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-07-08 16:56 -0500
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 15:46 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-10 02:41 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 17:55 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-16 16:34 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-17 09:56 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-18 00:08 -0400
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-18 21:16 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-18 23:54 -0400
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-19 10:02 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-25 02:56 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-25 02:40 -0700
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-25 17:32 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-25 16:56 -0700
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-26 06:27 -0400
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-26 15:59 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-26 06:55 -0700
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-26 17:14 +0300
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-26 12:50 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-26 22:07 -0700
Re: Common name for a "Task Loop" George Neuner <gneuner2@comcast.net> - 2016-07-27 14:22 -0400
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-08-03 04:58 -0700
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-26 06:38 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-07-09 01:28 +0300
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-09 09:25 +0300
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 21:47 +0300
Re: Common name for a "Task Loop" Mike Perkins <spam@spam.com> - 2016-07-09 11:18 +0100
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-09 21:41 +0300
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-07-09 20:52 -0500
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-07-10 02:01 -0700
Re: Common name for a "Task Loop" Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-10 17:34 +0300
Re: Common name for a "Task Loop" [long] Don Y <blockedofcourse@foo.invalid> - 2016-07-17 01:17 -0700
Re: Common name for a "Task Loop" Tim Wescott <seemywebsite@myfooter.really> - 2016-07-07 16:02 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-30 04:14 +0300
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-30 17:07 -0500
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-07-01 02:28 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 12:02 -0700
Re: Common name for a "Task Loop" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-06-28 23:19 +0200
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-28 11:51 -0700
Re: Common name for a "Task Loop" Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2016-07-01 06:54 +0000
Re: Common name for a "Task Loop" Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-25 21:08 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-25 15:24 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-25 21:52 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 01:04 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 13:46 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 05:11 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 15:35 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 06:57 -0700
Re: Common name for a "Task Loop" Reinhardt Behm <rbehm@hushmail.com> - 2016-06-26 21:18 +0800
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 07:07 -0700
Re: Common name for a "Task Loop" upsidedown@downunder.com - 2016-06-26 17:35 +0300
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 07:50 -0700
Re: Common name for a "Task Loop" Reinhardt Behm <rbehm@hushmail.com> - 2016-06-26 22:37 +0800
Re: Common name for a "Task Loop" Don Y <blockedofcourse@foo.invalid> - 2016-06-26 08:18 -0700
Re: Common name for a "Task Loop" Dave Nadler <drn@nadler.com> - 2016-06-25 22:00 -0700
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-26 11:01 -0500
Re: Common name for a "Task Loop" Les Cargill <lcargill99@comcast.com> - 2016-06-26 19:28 -0500
Re: Common name for a "Task Loop" FreeRTOS info <noemail@given.com> - 2016-06-27 08:33 +0100
Re: Common name for a "Task Loop" Tim Wescott <tim@seemywebsite.com> - 2016-06-28 09:48 -0500
Re: Common name for a "Task Loop" raimond.dragomir@gmail.com - 2016-06-28 08:25 -0700
Re: Common name for a "Task Loop" Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-07-03 17:39 +0000
Re: Common name for a "Task Loop" WangoTango <Asgard24@mindspring.com> - 2016-07-14 16:27 -0400
Re: Common name for a "Task Loop" Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-14 20:44 +0000
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-07-11 06:51 +0300 |
| Message-ID | <rf56ob943svogiv3lvmsvlhvcmtn8s8bl3@4ax.com> |
| In reply to | #24594 |
On Sun, 10 Jul 2016 03:29:01 -0500, Les Cargill <lcargill99@comcast.com> wrote: >>> It could be that the instrumentation necessary for the memory scrubber >>> to figure out it needs to swap, costs too much. And I understand that. >>> >>> And I'm not talking about randomly inserting "sleep()" calls as if >>> you were balancing a wheel :) - I mean constructing a "memory >>> scrubber" object that understands its CPU budget. Running the >>> memory scrubber on constraints based on estimated CPU utilization. >> >> My current memory scubber object understands its CPU budget: it is >> allowed (and even required) to use all the CPU time available at its >> priority level. >> > >Ah, then that mainly follows what I mean then. I've just seen lots of >things where there was no concept of CPU budget and then people are >surprised to find that one was needed. You'd have a cluster >of events occur within some horizon and things would go wonky. What exactly is your "memory scrubber" actually doing ? * Read/ECC correction/writeback a memory location to avoid cosmic ray problems ? * Dynamic memory garbage collection ? * Virtual memory "dirty page" write to the page file ? * Something completely different ? These could all be done in the background in the null task with no knowledge of the CPU budget. Of course, the actual useful work load must be below 100 %, but that is the case for any hard/soft RT to operate properly with or without a scrubber.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-11 16:11 +0300 |
| Message-ID | <duhk7vFojfrU1@mid.individual.net> |
| In reply to | #24603 |
On 16-07-11 06:51 , upsidedown@downunder.com wrote:
> On Sun, 10 Jul 2016 03:29:01 -0500, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>>>> It could be that the instrumentation necessary for the memory scrubber
>>>> to figure out it needs to swap, costs too much. And I understand that.
>>>>
>>>> And I'm not talking about randomly inserting "sleep()" calls as if
>>>> you were balancing a wheel :) - I mean constructing a "memory
>>>> scrubber" object that understands its CPU budget. Running the
>>>> memory scrubber on constraints based on estimated CPU utilization.
>>>
>>> My current memory scubber object understands its CPU budget: it is
>>> allowed (and even required) to use all the CPU time available at its
>>> priority level.
>>>
>>
>> Ah, then that mainly follows what I mean then. I've just seen lots of
>> things where there was no concept of CPU budget and then people are
>> surprised to find that one was needed. You'd have a cluster
>> of events occur within some horizon and things would go wonky.
>
> What exactly is your "memory scrubber" actually doing ?
>
> * Read/ECC correction/writeback a memory location to avoid cosmic ray
> problems ?
Yes. I thought this was the (only) common meaning of "memory scrubbing",
but perhaps I was wrong.
> These could all be done in the background in the null task with no
> knowledge of the CPU budget.
Rest easy, my memory scrubber *is* the background task (as I said in my
original mention of the scrubber, a number of posts ago) in the sense
that it has the lowest priority of all tasks and never blocks.
But the point of the discussion is more general: for real-time SW using
priority-based scheduling, it is IMO nonsense to demand that the SW
behaviour should not depend on the priority assignment. It may be that I
misunderstood that initial statement by Les Cargill, and that we have
been discussing and resolving only this misunderstanding, but at least
it seems that Les now accepts that the priority-dependence in this
example application is not reprehensible.
Furthermore, IMO each task should be designed according to its own
timing requirements, with inter-task conflicts and scheduling handled in
the global design (decomposition into tasks and their priorities). This
principle cannot always be followed strictly (for example when tasks are
triggered with known offsets relative to some periodic activity) but it
should IMO always be the starting point.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-11 12:04 -0500 |
| Message-ID | <nm0jaa$6o8$1@dont-email.me> |
| In reply to | #24604 |
Niklas Holsti wrote: > On 16-07-11 06:51 , upsidedown@downunder.com wrote: >> On Sun, 10 Jul 2016 03:29:01 -0500, Les Cargill >> <lcargill99@comcast.com> wrote: >> >>>>> It could be that the instrumentation necessary for the memory scrubber >>>>> to figure out it needs to swap, costs too much. And I understand that. >>>>> >>>>> And I'm not talking about randomly inserting "sleep()" calls as if >>>>> you were balancing a wheel :) - I mean constructing a "memory >>>>> scrubber" object that understands its CPU budget. Running the >>>>> memory scrubber on constraints based on estimated CPU utilization. >>>> >>>> My current memory scubber object understands its CPU budget: it is >>>> allowed (and even required) to use all the CPU time available at its >>>> priority level. >>>> >>> >>> Ah, then that mainly follows what I mean then. I've just seen lots of >>> things where there was no concept of CPU budget and then people are >>> surprised to find that one was needed. You'd have a cluster >>> of events occur within some horizon and things would go wonky. >> >> What exactly is your "memory scrubber" actually doing ? >> >> * Read/ECC correction/writeback a memory location to avoid cosmic ray >> problems ? > > Yes. I thought this was the (only) common meaning of "memory scrubbing", > but perhaps I was wrong. > >> These could all be done in the background in the null task with no >> knowledge of the CPU budget. > > Rest easy, my memory scrubber *is* the background task (as I said in my > original mention of the scrubber, a number of posts ago) in the sense > that it has the lowest priority of all tasks and never blocks. > > But the point of the discussion is more general: for real-time SW using > priority-based scheduling, it is IMO nonsense to demand that the SW > behaviour should not depend on the priority assignment. It may be that I > misunderstood that initial statement by Les Cargill, and that we have > been discussing and resolving only this misunderstanding, but at least > it seems that Les now accepts that the priority-dependence in this > example application is not reprehensible. > I certainly didn't mean to imply anything "reprehensible" about this state of affairs. Indeed, as you described the design in question in detail, it looks to be perfectly acceptable. > Furthermore, IMO each task should be designed according to its own > timing requirements, with inter-task conflicts and scheduling handled in > the global design (decomposition into tasks and their priorities). This > principle cannot always be followed strictly (for example when tasks are > triggered with known offsets relative to some periodic activity) but it > should IMO always be the starting point. > Also agreed. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-07-12 11:31 +0300 |
| Message-ID | <3m99obhcejjmegrfphb58n3gst3hm6inis@4ax.com> |
| In reply to | #24604 |
On Mon, 11 Jul 2016 16:11:27 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >On 16-07-11 06:51 , upsidedown@downunder.com wrote: >> On Sun, 10 Jul 2016 03:29:01 -0500, Les Cargill >> <lcargill99@comcast.com> wrote: >> >>>>> It could be that the instrumentation necessary for the memory scrubber >>>>> to figure out it needs to swap, costs too much. And I understand that. >>>>> >>>>> And I'm not talking about randomly inserting "sleep()" calls as if >>>>> you were balancing a wheel :) - I mean constructing a "memory >>>>> scrubber" object that understands its CPU budget. Running the >>>>> memory scrubber on constraints based on estimated CPU utilization. >>>> >>>> My current memory scubber object understands its CPU budget: it is >>>> allowed (and even required) to use all the CPU time available at its >>>> priority level. >>>> >>> >>> Ah, then that mainly follows what I mean then. I've just seen lots of >>> things where there was no concept of CPU budget and then people are >>> surprised to find that one was needed. You'd have a cluster >>> of events occur within some horizon and things would go wonky. >> >> What exactly is your "memory scrubber" actually doing ? >> >> * Read/ECC correction/writeback a memory location to avoid cosmic ray >> problems ? > >Yes. I thought this was the (only) common meaning of "memory scrubbing", >but perhaps I was wrong. That had earlier been my impression too, but googling, quite a lot of strange hits emerged :-). IIRC, when the Hubble (HST) had problems flying through the SAA radiation zone, it was called memory "flushing". Any earlier space usage of scrubbing/flushing ? >> These could all be done in the background in the null task with no >> knowledge of the CPU budget. > >Rest easy, my memory scrubber *is* the background task (as I said in my >original mention of the scrubber, a number of posts ago) in the sense >that it has the lowest priority of all tasks and never blocks. Doing the scrubbing in the null task is easy, as long as the hardware supports uninterruptable memory to memory instructions, so no need to disable interrupts an hence task switching. Things get more problematic with RISC style load/store architectures. Also caches complicates the situation. A single byte read is sufficient to load a full cache line such as 32 bytes, but the writeback is an other issue (write through or write back) how to handle it.
[toc] | [prev] | [next] | [standalone]
| From | mac <acolvin@efunct.com> |
|---|---|
| Date | 2016-07-12 15:08 +0000 |
| Message-ID | <202402274.490028727.312027.acolvin-efunct.com@news.eternal-september.org> |
| In reply to | #24606 |
>but the writeback is an other issue (write through or write back) how to handle it. Is writeback necessary? Does reading RAM clear it, with the controller doing a rewrite? Or was that just core? mac the naïf
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-07-12 21:24 -0500 |
| Message-ID | <2s8bob1d9k255nldehs287mvhgfje4l3g6@4ax.com> |
| In reply to | #24608 |
On Tue, 12 Jul 2016 15:08:39 -0000 (UTC), mac <acolvin@efunct.com> wrote: >>but the writeback is an other issue (write through or write back) how to handle it. > >Is writeback necessary? Does reading RAM clear it, with the controller >doing a rewrite? Or was that just core? DRAM cell read-out is destructive - the charge (or lack-thereof) in the capacitor makes a blip (or not) on the sense line. It's not the controller doing the rewrite, since the entire row is read at once (and all the bits in the row are destroyed), the rewrite is done on the memory chip. Refresh performed by the DRAM controller is just an abbreviated read cycle (the chip reads and rewrites the selected row, but does not return any data so does not need the column address). But ECC detection/correction is almost always done in the DRAM controller (or something nearby), and usually does force a rewrite of the corrected word. Writeback in this context refers to caches not immediately writing modified data back to RAM. To do scrubbing in software, you need to bypass the caches (both for proper operation, and to avoid flushing useful data from your caches), and generally you'd like to do it with something approximating real (as opposed to virtual) addresses. You also need to make sure scrubbing happens at some minimum rate - if there no idle time, there won't be any scrubbing if that's the only time you do it. There's a lot to be said for leaving it to the DRAM controller...
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-12 21:11 +0300 |
| Subject | Memory scrubbing [Was Re: Common name for a "Task Loop"] |
| Message-ID | <dukq66FhvgeU1@mid.individual.net> |
| In reply to | #24606 |
I've changed the Subject according to the veering of the discussion.
On 16-07-12 11:31 , upsidedown@downunder.com wrote:
> On Mon, 11 Jul 2016 16:11:27 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> wrote:
>
>> On 16-07-11 06:51 , upsidedown@downunder.com wrote:
[snip]
>>> What exactly is your "memory scrubber" actually doing ?
>>>
>>> * Read/ECC correction/writeback a memory location to avoid cosmic ray
>>> problems ?
>>
>> Yes. I thought this was the (only) common meaning of "memory scrubbing",
>> but perhaps I was wrong.
>
> That had earlier been my impression too, but googling, quite a lot of
> strange hits emerged :-).
>
> IIRC, when the Hubble (HST) had problems flying through the SAA
> radiation zone, it was called memory "flushing".
>
> Any earlier space usage of scrubbing/flushing ?
I've been working with ESA projects since 1995, and "scrubbing" is the
only word I've seen used.
> Doing the scrubbing in the null task is easy, as long as the hardware
> supports uninterruptable memory to memory instructions, so no need to
> disable interrupts an hence task switching.
>
> Things get more problematic with RISC style load/store architectures.
In this application, the processor is a SPARC v8 (a LEON2, to be exact).
It is load/store. The EDAC corrects loaded data on the fly, but does not
write the corrected data back.
The scrubber will read every word in a block of memory (non-atomically),
then check the EDAC control registers to find out if the EDAC corrected
an error, and which was the first corrected address. If an error was
corrected, the scrubber atomically loads and stores the first corrected
address, then continues with a new block of memory from the next address.
> Also caches complicates the situation. A single byte read is
> sufficient to load a full cache line such as 32 bytes, but the
> writeback is an other issue (write through or write back) how to
> handle it.
The LEON2 D-cache is unusual in that a cache miss loads only the missing
word, not a whole cache line.
This application will probably keep the D-cache disabled. The RAM is
pretty fast (2 wait states) and it is doubtful (but to be measured) if
the D-cache will really speed things up or mainly increase jitter.
The kernel can manage cache-state (enable/disable) as part of the task
context, so if necesssary we can disable the D-cache just for the
scrubber task but enable it for other tasks. There is also the option of
making the scrubber load data using a special form of the load
instruction that bypasses the D-cache and always reads from RAM.
In addition to the cache, DMA input also complicates scrubbing because
even an interrupt-atomic load-store pair is non-atomic with respect to
DMA. One common work-around, which we will also use in this application,
is to use all DMA buffers in a round-robin fashion and show by analysis
that no data stays long enough in RAM, between a store and a load, to
risk accumulating more than a correctable one-bit error.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-07-12 21:11 -0500 |
| Message-ID | <ij8bob5tmqb6aq375qt5b42t2rj228s59t@4ax.com> |
| In reply to | #24604 |
On Mon, 11 Jul 2016 16:11:27 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >On 16-07-11 06:51 , upsidedown@downunder.com wrote: >> On Sun, 10 Jul 2016 03:29:01 -0500, Les Cargill >> <lcargill99@comcast.com> wrote: >> >>>>> It could be that the instrumentation necessary for the memory scrubber >>>>> to figure out it needs to swap, costs too much. And I understand that. >>>>> >>>>> And I'm not talking about randomly inserting "sleep()" calls as if >>>>> you were balancing a wheel :) - I mean constructing a "memory >>>>> scrubber" object that understands its CPU budget. Running the >>>>> memory scrubber on constraints based on estimated CPU utilization. >>>> >>>> My current memory scubber object understands its CPU budget: it is >>>> allowed (and even required) to use all the CPU time available at its >>>> priority level. >>>> >>> >>> Ah, then that mainly follows what I mean then. I've just seen lots of >>> things where there was no concept of CPU budget and then people are >>> surprised to find that one was needed. You'd have a cluster >>> of events occur within some horizon and things would go wonky. >> >> What exactly is your "memory scrubber" actually doing ? >> >> * Read/ECC correction/writeback a memory location to avoid cosmic ray >> problems ? > >Yes. I thought this was the (only) common meaning of "memory scrubbing", >but perhaps I was wrong. > >> These could all be done in the background in the null task with no >> knowledge of the CPU budget. > >Rest easy, my memory scrubber *is* the background task (as I said in my >original mention of the scrubber, a number of posts ago) in the sense >that it has the lowest priority of all tasks and never blocks. I know of a system which did not have hardware scrubbing, and it was (reasonably) thought to do software scrubbing in the idle loop. The only problem was that the original implementation did not anticipate the effect of an uncorrectable error being hit by the scrubber, the resulting machine check panicked the kernel...
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-08 23:35 +0300 |
| Message-ID | <duah4bF44pfU1@mid.individual.net> |
| In reply to | #24572 |
On 16-07-08 19:06 , Tim Wescott wrote:
> On Thu, 07 Jul 2016 23:09:08 +0300, Niklas Holsti wrote:
>> Don Y wrote:
>> [snips]
>>> Or, is it just "some suggestive feeling"
>>> that led to the small integers chosen?
>>
>> No. From the requirements, I derive a set of tasks and deadlines, and
>> then assign priorities in deadline-monotonic order. Then I analyse or
>> measure WCETs and crank the response-time algorithm to check
>> schedulability. The main problem is that the task interactions are often
>> more complex than assumed by the simpler schedulability analysis
>> methods. Fortunately, in my projects it is usually possible to separate
>> hard-real-time tasks from soft-real-time tasks, and the interactions of
>> the hard-real-time tasks tend to be rather simple.
>
> I have never had a problem doing this separation myself, although I've
> inherited code from other people that fails at this, and rather badly.
> The most egregious example of this was code that put the most important
> two jobs into one superloop inside of one task -- and did so in such a
> way that bollixed up the whole system if incoming commands exceeded a
> rather moderate rate.
>
> I'm not entirely sure, but I think there's a possibility that if your
> code _does_ have such an interaction between tasks, then it means that
> there's something fundamentally wrong with your software design, or
> possibly your system design as a whole.
I agree that some troublesome task-to-task interactions are design flaws
and can be eliminated by design changes, sometimes by splitting some
task into one hard-real-time task and another less urgent task. But I
have not always succeeded at that.
One example of interactions I find difficult is a shared I/O channel or
bus that must be used by various tasks, for various purposes, with most
transmissions being sporadic and such that the sending task must wait
for and check a response transmission. I believe that there are analysis
methods which can find bounds on the response times for these tasks,
including queueing delays and communication latencies, but I haven't
studied or tried them yet. I may have to do so in my current project,
however, because the system has three inter-communicating computers,
with each computer connected by one SpaceWire link to a central router.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2016-07-08 23:54 +0300 |
| Message-ID | <nlp3tg$il4$1@dont-email.me> |
| In reply to | #24575 |
On 08.7.2016 г. 23:35, Niklas Holsti wrote: > On 16-07-08 19:06 , Tim Wescott wrote: >> On Thu, 07 Jul 2016 23:09:08 +0300, Niklas Holsti wrote: >>> Don Y wrote: >>> [snips] >>>> Or, is it just "some suggestive feeling" >>>> that led to the small integers chosen? >>> >>> No. From the requirements, I derive a set of tasks and deadlines, and >>> then assign priorities in deadline-monotonic order. Then I analyse or >>> measure WCETs and crank the response-time algorithm to check >>> schedulability. The main problem is that the task interactions are often >>> more complex than assumed by the simpler schedulability analysis >>> methods. Fortunately, in my projects it is usually possible to separate >>> hard-real-time tasks from soft-real-time tasks, and the interactions of >>> the hard-real-time tasks tend to be rather simple. >> >> I have never had a problem doing this separation myself, although I've >> inherited code from other people that fails at this, and rather badly. >> The most egregious example of this was code that put the most important >> two jobs into one superloop inside of one task -- and did so in such a >> way that bollixed up the whole system if incoming commands exceeded a >> rather moderate rate. >> >> I'm not entirely sure, but I think there's a possibility that if your >> code _does_ have such an interaction between tasks, then it means that >> there's something fundamentally wrong with your software design, or >> possibly your system design as a whole. > > I agree that some troublesome task-to-task interactions are design flaws > and can be eliminated by design changes, sometimes by splitting some > task into one hard-real-time task and another less urgent task. But I > have not always succeeded at that. > > One example of interactions I find difficult is a shared I/O channel or > bus that must be used by various tasks, for various purposes, with most > transmissions being sporadic and such that the sending task must wait > for and check a response transmission. I believe that there are analysis > methods which can find bounds on the response times for these tasks, > including queueing delays and communication latencies, but I haven't > studied or tried them yet. I may have to do so in my current project, > however, because the system has three inter-communicating computers, > with each computer connected by one SpaceWire link to a central router. > Well sending (tcp over ethernet, let's be just practical) can be controlled by task priorities quite well. Reception is another beast, the quick fix which usually works is to throw more buffer RAM at it; then if it works you may not have to seek the right fix :-). Dimiter
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-07-09 09:34 +0300 |
| Message-ID | <ae51obtg2kkklr5fu7mo9u1s3qothf99o4@4ax.com> |
| In reply to | #24577 |
On Fri, 8 Jul 2016 23:54:15 +0300, Dimiter_Popoff <dp@tgi-sci.com> wrote: >On 08.7.2016 ?. 23:35, Niklas Holsti wrote: >> On 16-07-08 19:06 , Tim Wescott wrote: >>> I have never had a problem doing this separation myself, although I've >>> inherited code from other people that fails at this, and rather badly. >>> The most egregious example of this was code that put the most important >>> two jobs into one superloop inside of one task -- and did so in such a >>> way that bollixed up the whole system if incoming commands exceeded a >>> rather moderate rate. >>> >>> I'm not entirely sure, but I think there's a possibility that if your >>> code _does_ have such an interaction between tasks, then it means that >>> there's something fundamentally wrong with your software design, or >>> possibly your system design as a whole. >> >> I agree that some troublesome task-to-task interactions are design flaws >> and can be eliminated by design changes, sometimes by splitting some >> task into one hard-real-time task and another less urgent task. But I >> have not always succeeded at that. >> >> One example of interactions I find difficult is a shared I/O channel or >> bus that must be used by various tasks, for various purposes, with most >> transmissions being sporadic and such that the sending task must wait >> for and check a response transmission. I believe that there are analysis >> methods which can find bounds on the response times for these tasks, >> including queueing delays and communication latencies, but I haven't >> studied or tried them yet. I may have to do so in my current project, >> however, because the system has three inter-communicating computers, >> with each computer connected by one SpaceWire link to a central router. > >Well sending (tcp over ethernet, let's be just practical) can be >controlled by task priorities quite well. Reception is another beast, >the quick fix which usually works is to throw more buffer RAM at it; >then if it works you may not have to seek the right fix :-). I consider TCP/IP directly harmful for hard real-time systems :-) due to the congestion handling. In hard real-time systems, a message with correct contents but arriving after deadline is useless and possibly even harmful. Anyway, I would use a high priority Ethernet task that handles hardware access and for received packets forward them as raw MAC or UDP frames to other appropriate hard real-time tasks (according to port number for UDP). If messages are lost during the forwarding, this is just the same if lost already on the wire. TCP packets would go to a lower priority TCP task that would handle the TCP/IP connections and then transfer received data to appropriate soft real-time task. Alternatively, run TCP part of the TCP/IP stack in each soft real-time task using TCP/IP connections. The Ethernet task would forward packets to the correct SRT tasks using the port number. Those SRT tasks could run at different low priorities and hence the TCP/IP connections would have similar priority relationship. Even if some of the SRT tasks could not immediately handle new data, adjusting the TCP/IP window size would impellent the flow control.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2016-07-09 10:28 +0300 |
| Message-ID | <nlq927$jnr$1@dont-email.me> |
| In reply to | #24583 |
On 09.7.2016 г. 09:34, upsidedown@downunder.com wrote: > On Fri, 8 Jul 2016 23:54:15 +0300, Dimiter_Popoff <dp@tgi-sci.com> > wrote: > >> On 08.7.2016 ?. 23:35, Niklas Holsti wrote: >>> On 16-07-08 19:06 , Tim Wescott wrote: > >>>> I have never had a problem doing this separation myself, although I've >>>> inherited code from other people that fails at this, and rather badly. >>>> The most egregious example of this was code that put the most important >>>> two jobs into one superloop inside of one task -- and did so in such a >>>> way that bollixed up the whole system if incoming commands exceeded a >>>> rather moderate rate. >>>> >>>> I'm not entirely sure, but I think there's a possibility that if your >>>> code _does_ have such an interaction between tasks, then it means that >>>> there's something fundamentally wrong with your software design, or >>>> possibly your system design as a whole. >>> >>> I agree that some troublesome task-to-task interactions are design flaws >>> and can be eliminated by design changes, sometimes by splitting some >>> task into one hard-real-time task and another less urgent task. But I >>> have not always succeeded at that. >>> >>> One example of interactions I find difficult is a shared I/O channel or >>> bus that must be used by various tasks, for various purposes, with most >>> transmissions being sporadic and such that the sending task must wait >>> for and check a response transmission. I believe that there are analysis >>> methods which can find bounds on the response times for these tasks, >>> including queueing delays and communication latencies, but I haven't >>> studied or tried them yet. I may have to do so in my current project, >>> however, because the system has three inter-communicating computers, >>> with each computer connected by one SpaceWire link to a central router. >> >> Well sending (tcp over ethernet, let's be just practical) can be >> controlled by task priorities quite well. Reception is another beast, >> the quick fix which usually works is to throw more buffer RAM at it; >> then if it works you may not have to seek the right fix :-). > > I consider TCP/IP directly harmful for hard real-time systems :-) due > to the congestion handling. In hard real-time systems, a message with > correct contents but arriving after deadline is useless and possibly > even harmful. Well real time ad tcp may be intersecting at some point but even if they do your "harmful" logic still applies. The thing is, in tcp the timing does not depend only on your system but on its peer(s) and proxies. However, this does not preclude real time systems from using tcp - just not for their real time part. It just has to be designed such that its timing impredictability does not interfere with the real time jobs the system has. For example a netMCA uses tcp for viewing over VNC (RFB), system backup over ftp, http access to data etc., however the real time part - several megasamples/s of ADC data being processed without missing a sample or an event in the stream just does not know about tcp. All this under DPS of course, I have yet to witness someone manage all that under another OS. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-09 14:39 -0500 |
| Message-ID | <nlrjlc$t9s$1@dont-email.me> |
| In reply to | #24583 |
upsidedown@downunder.com wrote: > On Fri, 8 Jul 2016 23:54:15 +0300, Dimiter_Popoff <dp@tgi-sci.com> > wrote: > >> On 08.7.2016 ?. 23:35, Niklas Holsti wrote: >>> On 16-07-08 19:06 , Tim Wescott wrote: > >>>> I have never had a problem doing this separation myself, although I've >>>> inherited code from other people that fails at this, and rather badly. >>>> The most egregious example of this was code that put the most important >>>> two jobs into one superloop inside of one task -- and did so in such a >>>> way that bollixed up the whole system if incoming commands exceeded a >>>> rather moderate rate. >>>> >>>> I'm not entirely sure, but I think there's a possibility that if your >>>> code _does_ have such an interaction between tasks, then it means that >>>> there's something fundamentally wrong with your software design, or >>>> possibly your system design as a whole. >>> >>> I agree that some troublesome task-to-task interactions are design flaws >>> and can be eliminated by design changes, sometimes by splitting some >>> task into one hard-real-time task and another less urgent task. But I >>> have not always succeeded at that. >>> >>> One example of interactions I find difficult is a shared I/O channel or >>> bus that must be used by various tasks, for various purposes, with most >>> transmissions being sporadic and such that the sending task must wait >>> for and check a response transmission. I believe that there are analysis >>> methods which can find bounds on the response times for these tasks, >>> including queueing delays and communication latencies, but I haven't >>> studied or tried them yet. I may have to do so in my current project, >>> however, because the system has three inter-communicating computers, >>> with each computer connected by one SpaceWire link to a central router. >> >> Well sending (tcp over ethernet, let's be just practical) can be >> controlled by task priorities quite well. Reception is another beast, >> the quick fix which usually works is to throw more buffer RAM at it; >> then if it works you may not have to seek the right fix :-). > > I consider TCP/IP directly harmful for hard real-time systems :-) due > to the congestion handling. In hard real-time systems, a message with > correct contents but arriving after deadline is useless and possibly > even harmful. > What I think you'll find is that limiting the number of sockets used and exploiting ethernet switching, plus under utilizing the physical layer will lead to much more deterministic operation. You can use Ethernet as-if it were SPI/I2C with better deployment ability. These days, there's nothing wrong with having a "soft" realtime processor ( as in say, a Beaglebone ) as the only connection to a hard-realtime processor. The only advantage of this over SPI is the flexibility in deployment. It's darned nice to have the number of hard realtime boards connected to the soft realtime gateway be somewhat variable. And there are very small Ethernet switches these days. If it's sufficiently hard realtime that Ethernet bit times are a consideration, then this is more challenging or just not worth it. > Anyway, I would use a high priority Ethernet task that handles > hardware access and for received packets forward them as raw MAC or > UDP frames to other appropriate hard real-time tasks (according to > port number for UDP). If messages are lost during the forwarding, this > is just the same if lost already on the wire. > > TCP packets would go to a lower priority TCP task that would handle > the TCP/IP connections and then transfer received data to appropriate > soft real-time task. > SFAIK, most small micros offer low-latency lightweight TCP/UDP/IP stacks. > Alternatively, run TCP part of the TCP/IP stack in each soft > real-time task using TCP/IP connections. The Ethernet task would > forward packets to the correct SRT tasks using the port number. Those > SRT tasks could run at different low priorities and hence the TCP/IP > connections would have similar priority relationship. Even if some of > the SRT tasks could not immediately handle new data, adjusting the > TCP/IP window size would impellent the flow control. > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-07-08 16:56 -0500 |
| Message-ID | <nlp7ag$u04$1@dont-email.me> |
| In reply to | #24575 |
Niklas Holsti wrote: > On 16-07-08 19:06 , Tim Wescott wrote: >> On Thu, 07 Jul 2016 23:09:08 +0300, Niklas Holsti wrote: >>> Don Y wrote: >>> [snips] >>>> Or, is it just "some suggestive feeling" >>>> that led to the small integers chosen? >>> >>> No. From the requirements, I derive a set of tasks and deadlines, and >>> then assign priorities in deadline-monotonic order. Then I analyse or >>> measure WCETs and crank the response-time algorithm to check >>> schedulability. The main problem is that the task interactions are often >>> more complex than assumed by the simpler schedulability analysis >>> methods. Fortunately, in my projects it is usually possible to separate >>> hard-real-time tasks from soft-real-time tasks, and the interactions of >>> the hard-real-time tasks tend to be rather simple. >> >> I have never had a problem doing this separation myself, although I've >> inherited code from other people that fails at this, and rather badly. >> The most egregious example of this was code that put the most important >> two jobs into one superloop inside of one task -- and did so in such a >> way that bollixed up the whole system if incoming commands exceeded a >> rather moderate rate. >> >> I'm not entirely sure, but I think there's a possibility that if your >> code _does_ have such an interaction between tasks, then it means that >> there's something fundamentally wrong with your software design, or >> possibly your system design as a whole. > > I agree that some troublesome task-to-task interactions are design flaws > and can be eliminated by design changes, sometimes by splitting some > task into one hard-real-time task and another less urgent task. But I > have not always succeeded at that. > > One example of interactions I find difficult is a shared I/O channel or > bus that must be used by various tasks, for various purposes, with most > transmissions being sporadic and such that the sending task must wait > for and check a response transmission. So the sender sends asynchronously then blocks on a receive ( presumably with a timeout ) , with other tasks/ISRs handling the details. You may even have separate send and receive loops, with state indicating the timeout for each receive. If you do this right, very few tasks are marked "ready" at any given instant and you'll get more deterministic operation. > I believe that there are analysis > methods which can find bounds on the response times for these tasks, > including queueing delays and communication latencies, but I haven't > studied or tried them yet. It might be worth adding references to a high-res free-running timer and accumulating data. If you then wish to construct a latency model, you can then have data to see if your model makes any sense. I've even been able to make the cycle count for the high-res timer instrumentation come out even with measurement before :) Plus, a "soak loop" like that can help clarify stress behavior. > I may have to do so in my current project, > however, because the system has three inter-communicating computers, > with each computer connected by one SpaceWire link to a central router. > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-09 15:46 +0300 |
| Message-ID | <duca0oFgjjvU1@mid.individual.net> |
| In reply to | #24580 |
On 16-07-09 00:56 , Les Cargill wrote:
> Niklas Holsti wrote:
>> [snips]
>> One example of interactions I find difficult is a shared I/O channel or
>> bus that must be used by various tasks, for various purposes, with most
>> transmissions being sporadic and such that the sending task must wait
>> for and check a response transmission.
>
> So the sender sends asynchronously then blocks on a receive
> ( presumably with a timeout ) , with other tasks/ISRs handling
> the details. You may even have separate send and receive loops,
> with state indicating the timeout for each receive.
I have no problem *implementing* such things, my problem is *analysing*
the timing to compute worst-case task response times under various load
scenarios. This computation must also consider the possible latencies of
response-generation at the remote end of the channel.
> If you do this right, very few tasks are marked "ready" at any given
> instant and you'll get more deterministic operation.
Whenever a task is "not ready", it is blocked waiting for something.
These blockings, and in particular blockings caused by dynamic task
interactions that may or may not occur at run time, create problems for
the timing *analysis*.
>> I believe that there are analysis
>> methods which can find bounds on the response times for these tasks,
>> including queueing delays and communication latencies, but I haven't
>> studied or tried them yet.
>
> It might be worth adding references to a high-res free-running timer
> and accumulating data. If you then wish to construct a latency model,
> you can then have data to see if your model makes any sense.
I don't want to rely on such measurements, which always depend on the
scenarios and test cases used. I want to have a method for computing
response times from the design, and proving by analysis that deadlines
are met in all possible scenarios.
I know how to do that for systems where tasks interact in simple ways,
but I don't yet know how to do it for cases like the above shared
channel. There are tools that should be able to do it, but I have yet to
try them out.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-07-10 02:41 -0700 |
| Message-ID | <nlt589$3lr$1@dont-email.me> |
| In reply to | #24586 |
On 7/9/2016 5:46 AM, Niklas Holsti wrote: > On 16-07-09 00:56 , Les Cargill wrote: >> Niklas Holsti wrote: >>> [snips] >>> One example of interactions I find difficult is a shared I/O channel or >>> bus that must be used by various tasks, for various purposes, with most >>> transmissions being sporadic and such that the sending task must wait >>> for and check a response transmission. >> >> So the sender sends asynchronously then blocks on a receive >> ( presumably with a timeout ) , with other tasks/ISRs handling >> the details. You may even have separate send and receive loops, >> with state indicating the timeout for each receive. > > I have no problem *implementing* such things, my problem is *analysing* the > timing to compute worst-case task response times under various load scenarios. > This computation must also consider the possible latencies of > response-generation at the remote end of the channel. It's no different than a uniprocessor implementation -- *if* you "migrate" the "scheduling criteria" (in your case, "priorities") *with* the communication... THROUGHOUT the system! I.e., the (local) network stack doesn't just treat enqueued outgoing packets in FIFO order but, rather, "assumes" the priority of each "client" associated with each packet. So, the packet associated with the "highest priority" (using your scheduling lexicon) gets placed on the wire, "first". I.e., gets *scheduled* onto the resource (wire) first. Similarly, the incoming packet on the receiving end doesn't just get "enqueued" on a socket but, rather, gets promoted up the stack with the priority associated with its sender. I.e., gets *scheduled* through the stack, first (assuming its "priority" now exceeds those associated with other packets previously received. And, thereafter, the task that is waiting on that socket *assumes* the priority conveyed by that packet in how the task is scheduled, locally. The "scheduling criteria" of the original task (way back on the sending node) follows the packet as it "migrates" through the system -- and, the actions that it initiates! I.e., if the task that receives it (now operating with its "assumed" priority) [I'm trying to avoid using the word "inherited"] then needs to send a message to some other task (IPC or RPC), the same sort of "scheduling criteria migration" takes place. Until, ultimately, the "reply" is generated or the action "consumed". [This is why my earlier comments regarding scaling "scheduling criteria" to multiple nodes is problematic if they are just "small integers" that only make sense in a "local context"; you can't predict how the actions initiated by a task will propagate through the system as node boundaries (and subsystem boundaries!) present opportunities for those criteria (priorities) to lose meaning -- apples may reign supreme on one node while tangerines are revered on another!] >> If you do this right, very few tasks are marked "ready" at any given >> instant and you'll get more deterministic operation. > > Whenever a task is "not ready", it is blocked waiting for something. These > blockings, and in particular blockings caused by dynamic task interactions that > may or may not occur at run time, create problems for the timing *analysis*. > >>> I believe that there are analysis >>> methods which can find bounds on the response times for these tasks, >>> including queueing delays and communication latencies, but I haven't >>> studied or tried them yet. >> >> It might be worth adding references to a high-res free-running timer >> and accumulating data. If you then wish to construct a latency model, >> you can then have data to see if your model makes any sense. > > I don't want to rely on such measurements, which always depend on the scenarios > and test cases used. I want to have a method for computing response times from > the design, and proving by analysis that deadlines are met in all possible > scenarios. IME, you can only do that in small/trivial systems with predictable execution environments. Aperiodic tasks, "random" events, etc. leave you with a boundless range of possible scenarios that you're trying to cram into a neat little, well dimensioned, box. So, you make a best effort approach and GUARANTEE that you can detect exceptions/failures/faults and respond accordingly. If the Juno probe hadn't fired its engine at the "right" time, it would have used more of its reserve fuel to make a deferred course adjustment. But, there's still VALUE to it performing that operation even AFTER missing its (ideal) deadline. There's a point at which attempting a burn would be pointless -- for the *original* mission goal. But, you can be sure the scientists wouldn't just turn off all the ground equipment and walk home, head in hand! They'd find some *other*, possibly "less VALUable" use for the probe and see how the (fuel) resources could be applied to that OTHER goal -- with an entirely new deadline! > I know how to do that for systems where tasks interact in simple ways, but I > don't yet know how to do it for cases like the above shared channel. There are > tools that should be able to do it, but I have yet to try them out.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-07-10 17:55 +0300 |
| Message-ID | <duf5ufF6qkkU1@mid.individual.net> |
| In reply to | #24597 |
On 16-07-10 12:41 , Don Y wrote:
> On 7/9/2016 5:46 AM, Niklas Holsti wrote:
>> On 16-07-09 00:56 , Les Cargill wrote:
>>> Niklas Holsti wrote:
>>>> [snips]
>>>> One example of interactions I find difficult is a shared I/O channel or
>>>> bus that must be used by various tasks, for various purposes, with most
>>>> transmissions being sporadic and such that the sending task must wait
>>>> for and check a response transmission.
>>>
>>> So the sender sends asynchronously then blocks on a receive
>>> ( presumably with a timeout ) , with other tasks/ISRs handling
>>> the details. You may even have separate send and receive loops,
>>> with state indicating the timeout for each receive.
>>
>> I have no problem *implementing* such things, my problem is
>> *analysing* the timing to compute worst-case task response times
>> under various load scenarios. This computation must also consider
>> the possible latencies of response-generation at the remote end of
>> the channel.
>
> It's no different than a uniprocessor implementation -- *if* you
> "migrate" the "scheduling criteria" (in your case, "priorities")
> *with* the communication... THROUGHOUT the system!
Sure it is different from a uniprocessor, as there are now multiple
processors. I haven't yet used any multi-core/multi-processor
schedulability-analysis methods, but I know they exist.
> I.e., the (local) network stack doesn't just treat enqueued
> outgoing packets in FIFO order but, rather, "assumes" the
> priority of each "client" associated with each packet. So,
> the packet associated with the "highest priority" (using
> your scheduling lexicon) gets placed on the wire, "first".
In my current application, there are separate transmission queues
according to a (rough) priority order of the kind of data, command, or
response being transmitted. This will certainly help to limit the
queueing delays for high-priority traffic.
>>> It might be worth adding references to a high-res free-running timer
>>> and accumulating data. If you then wish to construct a latency model,
>>> you can then have data to see if your model makes any sense.
>>
>> I don't want to rely on such measurements, which always depend on the
>> scenarios and test cases used. I want to have a method for computing
>> response times from the design, and proving by analysis that deadlines
>> are met in all possible scenarios.
>
> IME, you can only do that in small/trivial systems with predictable
> execution environments.
I don't disagree. But this happens to be my situation. My applications
may be "trivial" in this sense, but they provide my bread & butter (or
margarine, as the case may be), so they are non-trivial to me.
> Aperiodic tasks, "random" events, etc.
> leave you with a boundless range of possible scenarios that you're
> trying to cram into a neat little, well dimensioned, box.
Aperiodic tasks can be limited by minimum inter-arrival times, agreed
with the SW customer and (if required) enforced in the SW, and then they
can be analysed in the same way as periodic tasks. Alternatively,
scheduling methods called "servers" exist that can handle aperiodic or
sporadic stuff, in a priority-based or EDF-based environment, while
using at most a defined fraction of the resources.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-07-16 16:34 -0700 |
| Message-ID | <nmeg9e$j64$1@dont-email.me> |
| In reply to | #24600 |
On 7/10/2016 7:55 AM, Niklas Holsti wrote:
> On 16-07-10 12:41 , Don Y wrote:
>> On 7/9/2016 5:46 AM, Niklas Holsti wrote:
>>> On 16-07-09 00:56 , Les Cargill wrote:
>>>> Niklas Holsti wrote:
>>>>> [snips]
>>>>> One example of interactions I find difficult is a shared I/O channel or
>>>>> bus that must be used by various tasks, for various purposes, with most
>>>>> transmissions being sporadic and such that the sending task must wait
>>>>> for and check a response transmission.
>>>>
>>>> So the sender sends asynchronously then blocks on a receive
>>>> ( presumably with a timeout ) , with other tasks/ISRs handling
>>>> the details. You may even have separate send and receive loops,
>>>> with state indicating the timeout for each receive.
>>>
>>> I have no problem *implementing* such things, my problem is
>>> *analysing* the timing to compute worst-case task response times
>>> under various load scenarios. This computation must also consider
>>> the possible latencies of response-generation at the remote end of
>>> the channel.
>>
>> It's no different than a uniprocessor implementation -- *if* you
>> "migrate" the "scheduling criteria" (in your case, "priorities")
>> *with* the communication... THROUGHOUT the system!
>
> Sure it is different from a uniprocessor, as there are now multiple processors.
> I haven't yet used any multi-core/multi-processor schedulability-analysis
> methods, but I know they exist.
I think you will be very disappointed when you start "looking under
the hood" of most of those methods. Esp if you are looking for a
simple "relation" (i.e., if X then PASS else FAIL) to summarize your
task *set*! For example, "if the sum of the utilizations is less
than..."
Virtually all of the algorithms place preconditions on the task sets
*and* require concrete information on their release rates, utilization
factors, etc.
On top of that, you will find most are designed for SMP environments;
adding transport delays complicates the analysis.
(for starters, look for BAK, BCL, GFB, Dhall, etc.)
I approach systems differently: treat everything as possible
to fail. And, ensure you can respond rationally in that case!
This lets me reduce the number of things that I'd really like
NOT to fail to something more manageable... something that I
can analyze manually to determine the conditions under which
it can be expected to perform *best* in the system.
In my current system, tasks can "migrate" (I need a better term
as that has been overloaded, historically) between physical
processors. It's notion of "importance" (avoiding the term
"priority") shouldn't change just because it has "physically"
moved to a different CPU. It's *relative* importance when
competing for resources on that new node may (almost certainly!)
change. But, the criteria by which that node's scheduling decisions
are made should still be consistent with the criteria that was
used "in its original home".
[N.B. The scheduling ALGORITHM is free to change!]
Even in those cases where the task is bound to a particular physical
processor, the actions performed by other tasks (local and remote)
ON ITS BEHALF must be scheduled with its schedulability criteria.
Otherwise, asking any other task (service) to perform an action
effectively alters the performance of the current task.
[I.e., if a task calls a subroutine/function, that code executes
with it's scheduling criteria, right? Why should a *process*
that implements that subroutine/function -- i.e., IPC/RPC -- not
behave the same way? Does the task, instead, need to be aware of which
function invocations are backed by IPC/RPC vs. "simple" function calls?]
If, instead, a task's "importance" ("priority", in your case) magically
changes because it has crossed a subsystem (i.e., work is now being performed
in the network stack on its behalf) or node (work being performed on anotehr
physical processor), then the complexity of the scheduling analysis
grows exponentially. I.e., even tiny tak sets will prove to be difficult
to analyze with any certainty.
In a very real sense, I let the actual tasks' execution do that analysis
FOR me: let them run under a scheduling algorithm AFTER DEPLOYMENT and
trap each deadline that is missed -- with a suitably constructed handler
to "fix up" the system (and the task's role in it) in light of this
MISSED deadline (i.e., THIS INSTANCE of THIS TASKSET was NOT schedulable!).
For example, there are ~dozen tasks in one of my speech synthesizers.
I *know* the hardware is seriously underprovisioned -- despite being
"PC class" dedicated JUST to that one task!
[As "proof", a speech channel is a few hundred BITS per second. Yet, I
can deliver thousands of BYTES of data, per second, to the synthesizer
to "speak". Endlessly. Build ANY finite buffer and it WILL overflow.]
The algorithm knows it has to rely on the benevolence of anything feeding
it. Yet, also knows that it can't *gag* just because the upstream
data source "misbehaved". So, it uses some inherent knowledge of grammar
to ensure what it *can* "speak" makes some sort of sense. It doesn't
just process whatever "word" happens to be available at its input -- without
concern for any intervening words that may have been elided!
Instead, it deals with phrases and sentences (which, of course, have
no *definite* lengths!) and tries to present them, intact. With an
indication of any elided portions (i.e., "BEEP -- something is missing
at this point in the dialog").
Similarly, the constituent synthesis tasks know they can be preempted
or overridden by more "important" tasks. So, they do their work in
manageable pieces -- words and phrases at a time. So, the actual
waveforms presented to the user don't represent partial words. Or,
partial phrases.
Much better
for
the algorithm
to speak
in little
phrases
than
to speak
in
partial words.
(i.e., each time the algorithm had to place such an "arbitrary"
constraint on its output is a sign of a missed deadline; the "next
word" wasn't ready in time to be spoken when it should have been)
[Humans don't have very good "aural memories". You can watch
choppy video and still track the "action". But, listening to
choppy speech is virtually unintelligible]
>> I.e., the (local) network stack doesn't just treat enqueued
>> outgoing packets in FIFO order but, rather, "assumes" the
>> priority of each "client" associated with each packet. So,
>> the packet associated with the "highest priority" (using
>> your scheduling lexicon) gets placed on the wire, "first".
>
> In my current application, there are separate transmission queues according to
> a (rough) priority order of the kind of data, command, or response being
> transmitted. This will certainly help to limit the queueing delays for
> high-priority traffic.
But, there's no way of predicting (on paper) the delay incurred
by any message knowing the "priority" of its issuing task!
You've introduced an elastic delay by allowing the workload
of one particular task (with one set of known scheduling criteria)
to be intermixed with the workload of another -- in a manner that
no longer reflects the "ranking" that the scheduling criteria
had been applying to the tasks, up to that point.
>>>> It might be worth adding references to a high-res free-running timer
>>>> and accumulating data. If you then wish to construct a latency model,
>>>> you can then have data to see if your model makes any sense.
>>>
>>> I don't want to rely on such measurements, which always depend on the
>>> scenarios and test cases used. I want to have a method for computing
>>> response times from the design, and proving by analysis that deadlines
>>> are met in all possible scenarios.
>>
>> IME, you can only do that in small/trivial systems with predictable
>> execution environments.
>
> I don't disagree. But this happens to be my situation. My applications may be
> "trivial" in this sense, but they provide my bread & butter (or margarine, as
> the case may be), so they are non-trivial to me.
"Trivial" isn't meant as a denigration/dismissal of the problems you
face. It is, instead, chosen as an antonym for "complex". In complex
systems, the interactions become too numerous, subtle and *layered*
for most analysis techniques to apply. There are too many balls in
the air.
>> Aperiodic tasks, "random" events, etc.
>> leave you with a boundless range of possible scenarios that you're
>> trying to cram into a neat little, well dimensioned, box.
>
> Aperiodic tasks can be limited by minimum inter-arrival times, agreed with the
> SW customer and (if required) enforced in the SW, and then they can be analysed
> in the same way as periodic tasks. Alternatively, scheduling methods called
> "servers" exist that can handle aperiodic or sporadic stuff, in a
> priority-based or EDF-based environment, while using at most a defined fraction
> of the resources.
You can *agree* to anything you want. But, when the product fails to
*work* -- because the USER had their own idea of what those limits
should be -- suddenly your past agreements are just a leg to stand on
in a court of law... but, don't leave you *or* the customer happy!
When your reservations are exceeded, the system breaks. How do
you get a *user* to accept the fact that *you* (or your customer)
decided that *he* (the user) should only be expected to perform
a certain set of tasks in a certain amount of time, etc.?
IME, a better approach is to let the entire system "flex" to
accommodate the user -- in ways that you can't always predict
with a static reservation. Allow it to operate *into* overload
and for the user to find that sweet spot between "too much" and
"not enough" -- without arbitrarily enforcing a hard limit
because you *thought* (and contractually agreed) that a certain
reservation was "adequate".
If you carefully examine the systems around you, you should be able
to identify those that have been designed to "bend" vs. those that
simply "break". Each is "annoying" in that it doesn't implicitly
meet our needs. But, the ones that force us to STOP and GO at
their defined pace tend to be more annoying than those who will
let us "get ahead of them" -- but, eventually, catch up!
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2016-07-17 09:56 +0300 |
| Message-ID | <omamobptpqm8kck50u3qf5cldo7bpqkeof@4ax.com> |
| In reply to | #24600 |
On Sun, 10 Jul 2016 17:55:10 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >On 16-07-10 12:41 , Don Y wrote: >> On 7/9/2016 5:46 AM, Niklas Holsti wrote: >>> On 16-07-09 00:56 , Les Cargill wrote: >>>> Niklas Holsti wrote: >>>>> [snips] >>>>> One example of interactions I find difficult is a shared I/O channel or >>>>> bus that must be used by various tasks, for various purposes, with most >>>>> transmissions being sporadic and such that the sending task must wait >>>>> for and check a response transmission. >>>> >>>> So the sender sends asynchronously then blocks on a receive >>>> ( presumably with a timeout ) , with other tasks/ISRs handling >>>> the details. You may even have separate send and receive loops, >>>> with state indicating the timeout for each receive. >>> >>> I have no problem *implementing* such things, my problem is >>> *analysing* the timing to compute worst-case task response times >>> under various load scenarios. This computation must also consider >>> the possible latencies of response-generation at the remote end of >>> the channel. >> >> It's no different than a uniprocessor implementation -- *if* you >> "migrate" the "scheduling criteria" (in your case, "priorities") >> *with* the communication... THROUGHOUT the system! If you have the luxury of multiple cores/processors, just set the task affinities so that the critical tasks are locking on one core/processors and do the timing analysis with that. The other noncritical tasks will run on the remaining core(s)/processor(s). This is especially important in multiprocessor applications with large private caches. If the scheduler is allowed to through around the task among all processors, there is a lot of cache invalidation.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2016-07-18 00:08 -0400 |
| Message-ID | <bukoobtf9jlla92kmtpateh75krud655nm@4ax.com> |
| In reply to | #24633 |
On Sun, 17 Jul 2016 09:56:32 +0300, upsidedown@downunder.com wrote: >On Sun, 10 Jul 2016 17:55:10 +0300, Niklas Holsti ><niklas.holsti@tidorum.invalid> wrote: > >>On 16-07-10 12:41 , Don Y wrote: >>> On 7/9/2016 5:46 AM, Niklas Holsti wrote: >>>> On 16-07-09 00:56 , Les Cargill wrote: >>>>> Niklas Holsti wrote: >>>>>> [snips] >>>>>> One example of interactions I find difficult is a shared I/O channel or >>>>>> bus that must be used by various tasks, for various purposes, with most >>>>>> transmissions being sporadic and such that the sending task must wait >>>>>> for and check a response transmission. >>>>> >>>>> So the sender sends asynchronously then blocks on a receive >>>>> ( presumably with a timeout ) , with other tasks/ISRs handling >>>>> the details. You may even have separate send and receive loops, >>>>> with state indicating the timeout for each receive. >>>> >>>> I have no problem *implementing* such things, my problem is >>>> *analysing* the timing to compute worst-case task response times >>>> under various load scenarios. This computation must also consider >>>> the possible latencies of response-generation at the remote end of >>>> the channel. >>> >>> It's no different than a uniprocessor implementation -- *if* you >>> "migrate" the "scheduling criteria" (in your case, "priorities") >>> *with* the communication... THROUGHOUT the system! > >If you have the luxury of multiple cores/processors, just set the task >affinities so that the critical tasks are locking on one >core/processors and do the timing analysis with that. The other >noncritical tasks will run on the remaining core(s)/processor(s). > >This is especially important in multiprocessor applications with large >private caches. If the scheduler is allowed to through around the task >among all processors, there is a lot of cache invalidation. Don is talking about both multicores and physically separate processors connected by network. As he has described it elsewhere - his system is able to migrate a running task to any suitable platform anywhere within the network. There have been some other operating systems capable of doing this. AIUI, the interesting thing about Don's system is that he is attempting to do real-time, real-world control ... not simply to distribute processing over a bunch of networked "compute servers". George
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web