Jihad needs scientists
in [Design]
|
From: jmfbahciv on 17 Feb 2007 09:23 In article <er4g1l$1ln$5(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <er49e9$8qk_004(a)s897.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <er33t7$8jq$1(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <be273$45d50d69$49ecf9d$20196(a)DIALUPUSA.NET>, >>>nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >>>[.....] >>>>None of the has anything to do with the OS biz. >>> >>> >>>We just had another wonderful experience with XP. Characters pumped into >>>the serial port may take up to 5 seconds before a DOS application running >>>under XP gets to see them. >> >>I would expect that. Why aren't you expecting that? >> >>> Most of them eventually come through. >>> >>>Tomorrow, we may try it with "dosemu" to see how well that works. >> >><shrug> Change the threshold number that causes the DOS emulator >>to hand over bits. There's gotta be one. > >I believe that neither XP nor dosemu use a threshold. It has to have a threshold (we may be using this term differently). > The delay under XP >appears more random. It's not random (from the gut feels I'm getting from your description). > Chances are the timing under XP runs the DOS stuff >at a priority level equal to other tasks. There is some task between the >DOS stuff and the hardware that runs at some other time and priority. > >I believe that under dosemu, the serial stream gets checked every time the >emulator needs to pretend to access a serial port. Here's my guesstimate about what may be happening. Note that I have not read the sources nor have I watched the failure happen... You start things up. The serial starts dumping bits into a memory buffer on your machine. From your specs, it is a slow filler. So there has to be some kind of mechanism that allows the buffer filler and buffer reader to not get ahead of the other (depending on which way the bits are moving). When this stops working on your system, I would guess that the pointers which are used to fill/empty are in error. If the system is hung, the error is that one side is waiting for the other side to finish. If the error is a crash, the pointers pointed to a vital memory part that was used by the OS. I suppose it is also possible the the two loose track of each other where the reader is waiting for bits from the filler but the filler is dumping them at the wrong address. That could happen with a memory management bug in the OS's address fixups after swapping. I'd try to make the buffer filler's buffer size smaller than the buffer reader's buffer size. /BAH
From: Phil Carmody on 17 Feb 2007 09:44 jmfbahciv(a)aol.com writes: > In article <87fy94udes.fsf(a)nonospaz.fatphil.org>, > Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: > >jmfbahciv(a)aol.com writes: > >> In article <aaict21nu9t1faaiodh912qu7en2240379(a)4ax.com>, > >> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: > >> >On Fri, 16 Feb 07 12:25:03 GMT, jmfbahciv(a)aol.com Gave us: > >> > > >> >> Other > >> >>than instrumentation, there usually isn't any computing task that > >> >>has to have the CPU pay attention to it *right now*. > >> > > >> > > >> > A/V stream decoding does. Hell, even MP3 stream decoding does. > >> > > >> > When I watch Lost episodes on ABC.com, those streams get a LOT of > >> >CPU time slices simply because the stream MUST be processed > >> >continually. > >> > >> Son, it is time you learned about buffered mode I/O. > > > >Idiot. Presume the stream is all buffered in memory - how does that > >affect the fact that the processor must constantly be throwing > >up frame after frame to the screen? > > The CPU isn't doing that work. That's what the video card > does. So the CPU doesn't do bistream parsing, DCTs, deblocking, interpolation, etc? > > It doesn't. So the buffering > >or otherwise is irrelevant. You're completely hatstand. > > Why does the CPU have to be latched with the video card painting? > Not even your computer games work this way. The CPU does not > say throw this pixel at that TTY x,y address and then get back to me > when you have lit it. Was that supposed to make sense? > >Sure, a reasonably capable processor will only spend a fraction > >of the time doing the decoding/filtering/scaling/whatever, but > >for that timeslice, it's working on something that must be > >processed in real time. > > Why real time? Because watching vids is a real time process. Sheesh. > The CPU is sitting idle most of time. That's what I said. > The idle > time can be used for other stuff. I am fully aware of this. However, when there is a new field for processing, it needs to be processed, it can't be ignored without loss of quality. > This is not a new concept; it's > been around since females had to cook, rear kids, and entertain > the males so they would stick around for a while. Females do not have to do that. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: Phil Carmody on 17 Feb 2007 09:50 jmfbahciv(a)aol.com writes: > In article <8764a0ucl2.fsf(a)nonospaz.fatphil.org>, > Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: > >jmfbahciv(a)aol.com writes: > >> >I think that Linux has reached the point where it is good enough for all > >> >practical purposes. > >> > >> Nope. It is not a product (in the sense that we called things > >> a product). It is still a toy; it has a little bit more growing > >> up to do. > > > >Odd. The *world's largest manufacturer* of the kit that > >holds the internet together think that they want to run > >linux on their kit, and have done for years. Your > >perspective on the IT world is as skewed as your perspective > >on pretty much everything else, it appears. > > I am not talking about the IT world. That's just a small niche > of the computing biz. There is more to Real Life than IT. A small niche where one single linux-using company can make nearly $6B net profit in a year. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: Phil Carmody on 17 Feb 2007 09:59 jmfbahciv(a)aol.com writes: > In article <er4g1l$1ln$5(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: > >In article <er49e9$8qk_004(a)s897.apx1.sbo.ma.dialup.rcn.com>, > > <jmfbahciv(a)aol.com> wrote: > >>In article <er33t7$8jq$1(a)blue.rahul.net>, > >> kensmith(a)green.rahul.net (Ken Smith) wrote: > >>>In article <be273$45d50d69$49ecf9d$20196(a)DIALUPUSA.NET>, > >>>nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: > >>>[.....] > >>>>None of the has anything to do with the OS biz. > >>> > >>> > >>>We just had another wonderful experience with XP. Characters pumped into > >>>the serial port may take up to 5 seconds before a DOS application running > >>>under XP gets to see them. > >> > >>I would expect that. Why aren't you expecting that? > >> > >>> Most of them eventually come through. > >>> > >>>Tomorrow, we may try it with "dosemu" to see how well that works. > >> > >><shrug> Change the threshold number that causes the DOS emulator > >>to hand over bits. There's gotta be one. > > > >I believe that neither XP nor dosemu use a threshold. > > It has to have a threshold (we may be using this term differently). > > > The delay under XP > >appears more random. > > It's not random (from the gut feels I'm getting from your description). > > > Chances are the timing under XP runs the DOS stuff > >at a priority level equal to other tasks. There is some task between the > >DOS stuff and the hardware that runs at some other time and priority. > > > > >I believe that under dosemu, the serial stream gets checked every time the > >emulator needs to pretend to access a serial port. > > Here's my guesstimate about what may be happening. Note that > I have not read the sources nor have I watched the failure happen... > > You start things up. The serial starts dumping bits into a > memory buffer on your machine. From your specs, it is a slow > filler. So there has to be some kind of mechanism that > allows the buffer filler and buffer reader to not get ahead > of the other (depending on which way the bits are moving). > > When this stops working on your system, I would guess that > the pointers which are used to fill/empty are in error. > If the system is hung, the error is that one side is waiting > for the other side to finish. If the error is a crash, the > pointers pointed to a vital memory part that was used by the > OS. > > I suppose it is also possible the the two loose track of each > other where the reader is waiting for bits from the filler but > the filler is dumping them at the wrong address. That could > happen with a memory management bug in the OS's > address fixups after swapping. > > > I'd try to make the buffer filler's buffer size smaller > than the buffer reader's buffer size. That has got to be the biggest pile of IT-related gibbering I've seen you come up with in a long time. It's so meaningless much of it /isn't even wrong/. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: Ken Smith on 17 Feb 2007 11:32
In article <er734o$8qk_001(a)s994.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <er4g1l$1ln$5(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <er49e9$8qk_004(a)s897.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <er33t7$8jq$1(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>In article <be273$45d50d69$49ecf9d$20196(a)DIALUPUSA.NET>, >>>>nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >>>>[.....] >>>>>None of the has anything to do with the OS biz. >>>> >>>> >>>>We just had another wonderful experience with XP. Characters pumped into >>>>the serial port may take up to 5 seconds before a DOS application running >>>>under XP gets to see them. >>> >>>I would expect that. Why aren't you expecting that? >>> >>>> Most of them eventually come through. >>>> >>>>Tomorrow, we may try it with "dosemu" to see how well that works. >>> >>><shrug> Change the threshold number that causes the DOS emulator >>>to hand over bits. There's gotta be one. >> >>I believe that neither XP nor dosemu use a threshold. > >It has to have a threshold (we may be using this term differently). If you include one as a threshold then yes, but I don't generally consider that as a case of a threshold. A UART generally makes an interrupt upon receiving the first character. The built in FIFO is to give the OS enough time to service the interrupt. When coding your own DOS serial handler, you usually can turn off the FIFO in the UART and have the software continue to work normally. The exception is in some laptops where for some silly reason there is code that turns the interrupts off while it fiddles with the LCD. >> The delay under XP >>appears more random. > >It's not random (from the gut feels I'm getting from your description). I is likely it is not really random. The rule isn't "every N characters" or "every n milliseconds" as far as I can see. It is likely based on a combination of numbers of milliseconds. >> Chances are the timing under XP runs the DOS stuff >>at a priority level equal to other tasks. There is some task between the >>DOS stuff and the hardware that runs at some other time and priority. > >> >>I believe that under dosemu, the serial stream gets checked every time the >>emulator needs to pretend to access a serial port. > >Here's my guesstimate about what may be happening. Note that >I have not read the sources nor have I watched the failure happen... > >You start things up. The serial starts dumping bits into a >memory buffer on your machine. From your specs, it is a slow >filler. So there has to be some kind of mechanism that >allows the buffer filler and buffer reader to not get ahead >of the other (depending on which way the bits are moving). The FIFO inside the UART is 16 bytes long. The next FIFO action is done by some OS code. Eventually 99,999 of every 100,000 characters do make it to the end application. We are not talking about a case where the bulk of the data is lost. The problem is that the OS is sticking a delay in the characters getting to the application of up to 5 seconds. [.....] >I'd try to make the buffer filler's buffer size smaller >than the buffer reader's buffer size. We don't really have any options on adjusting stuff. This is an XP system you have to write a bunch of windows code if you want to be able to change anything about how serial ports work. > >/BAH -- -- kensmith(a)rahul.net forging knowledge |