On 2014-08-06, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:> On Wed, 6 Aug 2014 05:16:13 +0000 (UTC) > Grant Edwards <invalid@invalid.invalid> wrote: > >> I do a _lot_ of desktop serial port stuff in support of embedded work, >> and all the desktop stuff is in Python -- and some of it needs >> response time measured in tens of microseconds. I know a lot of other >> embedded developers do that as well.> I'll bite. I do most of my desktop support in Python as well, but > always assume that at any time the combination of Python and the OS > may wallop me for any number of milliseconds, and that I just need to > suck up and deal, and find some other way to handle it when I need to > ensure realtimeyness. > > How do you guarantee microsecond level response from Python (and I > assume Linux)?Well, it probably isn't guaranteed, but running the programs on a lightly loaded system that isn't running X always seemed to work well enough for my needs. [I don't often need that sort of response time, but when I did, I didn't have any problems.] If you want, you can jump through some hoops to run programs using real-time priorities, but on a lightly loaded system, I never say any difference. -- Grant Edwards grant.b.edwards Yow! I demand IMPUNITY! at gmail.com
Linux question -- how to tell if serial port in /dev is for real?
Started by ●August 4, 2014
Reply by ●August 11, 20142014-08-11
Reply by ●August 11, 20142014-08-11
On 2014-08-07, Randy Yates <yates@digitalsignallabs.com> wrote:>> No, and once an MMU is involved all the paging information >> might or might not be cached. Double whammy. > > So you're telling me that Intel made a processor that, by design, could > not service interrupts in a deterministic fashion? Hard to believe.What's hard to believe? Intel has been building slow, hot, crappily designed processors for decades.> Is that also the case for the present-day Intel architectures?The desktop ones, yes. -- Grant Edwards grant.b.edwards Yow! ONE LIFE TO LIVE for at ALL MY CHILDREN in ANOTHER gmail.com WORLD all THE DAYS OF OUR LIVES.
Reply by ●August 11, 20142014-08-11
On 11/08/14 16:29, Grant Edwards wrote:> On 2014-08-07, Randy Yates <yates@digitalsignallabs.com> wrote: > >>> No, and once an MMU is involved all the paging information >>> might or might not be cached. Double whammy. >> >> So you're telling me that Intel made a processor that, by design, could >> not service interrupts in a deterministic fashion? Hard to believe. > > What's hard to believe? Intel has been building slow, hot, crappily > designed processors for decades.Don't be silly. Their devices are excellent for their market.>> Is that also the case for the present-day Intel architectures? > > The desktop ones, yes.And, of course, for many other processor families from many other manufacturers.
Reply by ●August 11, 20142014-08-11
On 11/08/14 16:27, Grant Edwards wrote:> On 2014-08-06, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: >> On Wed, 6 Aug 2014 05:16:13 +0000 (UTC) >> Grant Edwards <invalid@invalid.invalid> wrote: >> >>> I do a _lot_ of desktop serial port stuff in support of embedded work, >>> and all the desktop stuff is in Python -- and some of it needs >>> response time measured in tens of microseconds. I know a lot of other >>> embedded developers do that as well. > >> I'll bite. I do most of my desktop support in Python as well, but >> always assume that at any time the combination of Python and the OS >> may wallop me for any number of milliseconds, and that I just need to >> suck up and deal, and find some other way to handle it when I need to >> ensure realtimeyness. >> >> How do you guarantee microsecond level response from Python (and I >> assume Linux)? > > Well, it probably isn't guaranteed, but running the programs on a > lightly loaded system that isn't running X always seemed to work well > enough for my needs. [I don't often need that sort of response time, > but when I did, I didn't have any problems.]Did your "needs" include devices where, even when they functioned according to design, could kill someone?> If you want, you can jump through some hoops to run programs using > real-time priorities, but on a lightly loaded system, I never say any > difference.Look harder.
Reply by ●August 12, 20142014-08-12
On 11/08/14 17:36, Tom Gardner wrote:> On 11/08/14 16:27, Grant Edwards wrote: >> On 2014-08-06, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: >>> On Wed, 6 Aug 2014 05:16:13 +0000 (UTC) >>> Grant Edwards <invalid@invalid.invalid> wrote: >>> >>>> I do a _lot_ of desktop serial port stuff in support of embedded work, >>>> and all the desktop stuff is in Python -- and some of it needs >>>> response time measured in tens of microseconds. I know a lot of other >>>> embedded developers do that as well. >> >>> I'll bite. I do most of my desktop support in Python as well, but >>> always assume that at any time the combination of Python and the OS >>> may wallop me for any number of milliseconds, and that I just need to >>> suck up and deal, and find some other way to handle it when I need to >>> ensure realtimeyness. >>> >>> How do you guarantee microsecond level response from Python (and I >>> assume Linux)? >> >> Well, it probably isn't guaranteed, but running the programs on a >> lightly loaded system that isn't running X always seemed to work well >> enough for my needs. [I don't often need that sort of response time, >> but when I did, I didn't have any problems.] > > Did your "needs" include devices where, even when they functioned > according to design, could kill someone?It seems like there is the age-old mix-up between "fast" and "real-time" here. I think Grant is claiming to have had fast response times - faster than many would think possible with Python on a Linux system - but it is not real-time. Unplanned delays /could/ happen.> >> If you want, you can jump through some hoops to run programs using >> real-time priorities, but on a lightly loaded system, I never say any >> difference. > > Look harder. >If it does the job he needs, then why should he? I too have made Python code on a PC that has reaction times of under a millisecond. Would I use such code for a sampling system recording data? Absolutely. Would I use it for controlling the steering on a car? Absolutely not.
Reply by ●August 12, 20142014-08-12
I completely agree. My point was simply to tie his comments to the points made elsewhere on this thread about the infrequent problems found in many modern processors. On 12/08/14 07:46, David Brown wrote:> On 11/08/14 17:36, Tom Gardner wrote: >> On 11/08/14 16:27, Grant Edwards wrote: >>> On 2014-08-06, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: >>>> On Wed, 6 Aug 2014 05:16:13 +0000 (UTC) >>>> Grant Edwards <invalid@invalid.invalid> wrote: >>>> >>>>> I do a _lot_ of desktop serial port stuff in support of embedded work, >>>>> and all the desktop stuff is in Python -- and some of it needs >>>>> response time measured in tens of microseconds. I know a lot of other >>>>> embedded developers do that as well. >>> >>>> I'll bite. I do most of my desktop support in Python as well, but >>>> always assume that at any time the combination of Python and the OS >>>> may wallop me for any number of milliseconds, and that I just need to >>>> suck up and deal, and find some other way to handle it when I need to >>>> ensure realtimeyness. >>>> >>>> How do you guarantee microsecond level response from Python (and I >>>> assume Linux)? >>> >>> Well, it probably isn't guaranteed, but running the programs on a >>> lightly loaded system that isn't running X always seemed to work well >>> enough for my needs. [I don't often need that sort of response time, >>> but when I did, I didn't have any problems.] >> >> Did your "needs" include devices where, even when they functioned >> according to design, could kill someone? > > It seems like there is the age-old mix-up between "fast" and "real-time" > here. I think Grant is claiming to have had fast response times - > faster than many would think possible with Python on a Linux system - > but it is not real-time. Unplanned delays /could/ happen. > >> >>> If you want, you can jump through some hoops to run programs using >>> real-time priorities, but on a lightly loaded system, I never say any >>> difference. >> >> Look harder. >> > > If it does the job he needs, then why should he? > > I too have made Python code on a PC that has reaction times of under a > millisecond. Would I use such code for a sampling system recording > data? Absolutely. Would I use it for controlling the steering on a > car? Absolutely not. > > >
