From: tytso@mit.edu
To: Larry McVoy <lm@mcvoy.com>
Cc: tuhs@tuhs.org
Subject: Re: [TUHS] A/UX [was Linux is on-topic]
Date: Tue, 21 Jul 2020 23:13:13 -0400 [thread overview]
Message-ID: <20200722031313.GC1536749@mit.edu> (raw)
In-Reply-To: <20200721010411.GS26294@mcvoy.com>
On Mon, Jul 20, 2020 at 06:04:11PM -0700, Larry McVoy wrote:
> On Mon, Jul 20, 2020 at 05:11:48PM -0500, Ed Carp wrote:
> > On 7/20/20, Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > Clem should pay attention, in my opinion, this is how you do Unix and
> > > real time. Because Unix is time sharing and throughput, that is the
> > > opposite of what real time is. Wedging real time into Unix is a mistake.
> >
> > Agreed.
>
> So many people get this wrong, they want to make "real time" in Unix "good
> enough" and it messes with everything. Victor's idea was awesome.
>
> And you know what sucks? I was on the Usenix review committee and I gave
> it 2 thumbs up but someone else, looking at you, Rob, said it was not
> interesting because the real time kernel wasn't POSIX. Even though the
> real time kernel had pipes, signals, and shared memory with Linux.
>
> He was a bigger deal than me so it didn't get published.
>
> I love the Rob in question, not Pike, but this was one of the most bone
> headed calls I've ever seen him make. The world needed to see this.
Never fear, Victor's work got published in a number of Linux
conference, so it wasn't totally buried.
> Wind River bought it and buried it because it competed with their stuff
> that was nowhere near as good.
I can't get into the mind of Wind River. but having worked on a
commercial real-time extension to Linux, and having gotten a IBM
Systems Journal publication[1] out of it, I have a slightly different
perspective.
[1] https://ieeexplore.ieee.org/document/5386551
The issue is that there aren't that many good real-time programmers
Tavailable. Furthermore, many real-time applications need to do a lot
more than data acquisition, so having access to POSIX API's in the
real time task is very attractive. Sure, you can try to interchange
information between the real-time task and the POSIX task, but that's
a lot more complicated, and that's where the "not enough real-time
programmers" rears its head again.
This is even worse if you are working in a military application, since
small population of "can program real-time programmers" is further
reduced by "can get a security clearance".
Fortunately, with modern, fast CPU's, it's possible to do real-time
via brute force, and as it turns out, there are a very large number ofJ
real-time tasks which can deal with real-time latency that are tens of
milliseconds, at which point you even use real-time Java with a
real-time garbage collector running on a real-time Linux. And that's
what Raytheon and the US Navy chose to use on their Zumwalt Class
destroyers, and that's how I and my team got the IBM Systems Journal
publication. :-)
Sure, there will be some number of real-time task which needs
single-digit millisecond real-time guarantees --- in which case you
can write it in C using Real-time Linux. And for those really cases
where you need latencies which are in the tens of microsecnds; then
yeah, at that point you might need specialized OS's. But the cases
where you need fast, hard real-time is pretty rare compared to those
cases where real-time Java is sufficient.
Cheers,
- Ted
next prev parent reply other threads:[~2020-07-22 3:14 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 18:08 [TUHS] H.J. Lu Bootable Root & Base System disks Norman Wilson
2020-07-17 18:14 ` John Cowan
2020-07-17 18:19 ` Larry McVoy
2020-07-17 19:53 ` [TUHS] Linux is on-topic Warren Toomey
2020-07-17 19:57 ` Larry McVoy
2020-07-17 20:00 ` Adam Thornton
2020-07-17 20:04 ` Larry McVoy
2020-07-17 20:03 ` Dan Cross
2020-07-17 23:31 ` A. P. Garcia
2020-07-19 10:26 ` emanuel stiebler
2020-07-17 20:07 ` Warren Toomey
2020-07-17 20:12 ` Warner Losh
2020-07-17 20:19 ` Clem Cole
2020-07-19 9:54 ` Sergio Pedraja
2020-07-17 20:08 ` Michael Kjörling
2020-07-17 20:55 ` Grant Taylor via TUHS
2020-07-17 21:28 ` Michael Kjörling
2020-07-18 20:22 ` Ed Carp
2020-07-18 20:29 ` Warner Losh
2020-07-19 2:31 ` Gregg Levine
2020-07-19 3:46 ` Wesley Parish
2020-07-19 4:42 ` Grant Taylor via TUHS
2020-07-19 18:01 ` Michael Parson
2020-07-20 8:47 ` [TUHS] A/UX [was Linux is on-topic] arnold
2020-07-20 9:46 ` Arno Griffioen
2020-07-20 16:35 ` Arthur Krewat
2020-07-20 17:44 ` Arno Griffioen
2020-07-20 19:07 ` Rich Morin
2020-07-20 19:45 ` Al Kossow
2020-07-20 19:49 ` Al Kossow
2020-07-24 0:01 ` Chris Hanson
2020-07-20 20:20 ` Ed Carp
2020-07-20 21:02 ` John Cowan
2020-07-20 22:27 ` Ed Carp
2020-07-24 0:04 ` Chris Hanson
2020-07-31 23:02 ` Dave Horsfall
2020-07-31 23:12 ` Richard Salz
2020-08-01 1:36 ` Larry McVoy
2020-08-01 16:08 ` Nemo Nusquam
2020-08-01 17:01 ` Arthur Krewat
2020-08-13 0:00 ` Dave Horsfall
2020-08-13 1:47 ` Larry McVoy
2020-08-13 3:15 ` Grant Taylor via TUHS
2020-08-13 4:02 ` Larry Cashdollar via TUHS
2020-08-31 21:12 ` Dave Horsfall
2020-09-03 14:10 ` Michael Parson
2020-08-13 1:53 ` Nemo Nusquam
2020-08-13 17:14 ` Dan Cross
2020-08-13 17:19 ` Henry Bent
2020-08-13 17:58 ` Warner Losh
2020-08-13 20:04 ` John Cowan
2020-08-13 20:52 ` Dan Cross
2020-08-14 17:31 ` Paul Winalski
2020-08-15 1:24 ` Dave Horsfall
2020-08-18 13:57 ` Derek Fawcus
2020-08-18 14:11 ` John Cowan
2020-08-31 21:20 ` Dave Horsfall
2020-08-13 19:18 ` Adam Thornton
2020-08-13 19:28 ` Warner Losh
2020-08-13 20:15 ` [TUHS] AIX link repost [was " Charles H Sauer
2020-08-13 20:09 ` [TUHS] " Rich
2020-08-13 20:16 ` Larry McVoy
2020-08-13 20:17 ` Dr Iain Maoileoin
2020-08-14 1:04 ` Christopher Browne
2020-08-14 17:18 ` Jim Capp
2020-08-14 17:37 ` Jim Capp
2020-08-14 17:39 ` Jon Steinhart
2020-08-15 0:33 ` Rich
2020-08-15 1:20 ` Larry McVoy
2020-08-15 2:08 ` Dave Horsfall
2020-08-15 2:47 ` Warner Losh
2020-08-15 17:44 ` Paul Winalski
2020-08-15 12:05 ` Thomas Paulsen
2020-08-15 1:33 ` Jon Steinhart
2020-08-15 2:02 ` Dave Horsfall
2020-08-15 2:45 ` Andrew Hume
2020-08-15 16:55 ` William Cheswick
2020-08-15 3:29 ` Larry McVoy
2020-08-15 1:40 ` Gregg Levine
2020-08-13 22:24 ` Grant Taylor via TUHS
2020-07-24 0:02 ` Chris Hanson
2020-07-20 9:48 ` Andrew Warkentin
2020-07-20 11:49 ` Larry McVoy
2020-07-20 14:36 ` Clem Cole
2020-07-20 17:24 ` John Cowan
2020-07-20 22:11 ` Ed Carp
2020-07-21 1:04 ` Larry McVoy
2020-07-22 3:13 ` tytso [this message]
2020-07-22 5:40 ` Bakul Shah
2020-07-22 14:16 ` Larry McVoy
2020-07-20 12:32 ` Derrik Walker v2.0
2020-07-20 12:54 ` Andrew Warkentin
2020-07-21 1:50 ` Larry McVoy
2020-07-21 2:30 ` Gregg Levine
2020-07-22 3:44 ` Jason
2020-07-22 12:23 ` Derrik Walker v2.0
2020-07-20 14:28 ` Clem Cole
2020-07-22 3:50 ` Jason
2020-07-22 4:26 ` Henry Bent
2020-07-24 0:10 ` Chris Hanson
2020-07-20 0:24 ` [TUHS] Linux is on-topic Ed Carp
2020-07-22 3:41 ` Jason
2020-07-22 16:15 ` Michael Parson
2020-07-18 3:34 ` Tomasz Rola
2020-07-18 16:45 ` Christopher Browne
2020-07-19 7:32 ` Lars Brinkhoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200722031313.GC1536749@mit.edu \
--to=tytso@mit.edu \
--cc=lm@mcvoy.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).