Can extra processing threads help in this case?
in [MFC]
|
From: Joseph M. Newcomer on 11 Apr 2010 21:54 So prove any of us wrong. MEASURE a real system and tell us what numbers you get! There is no other truth than the actual system. You have two interesting parameters to measure end-to-end transaction time from the client end-to-end transaction time in the server I already pointed out your MQMS model can give MASSIVE end-to-end delays in the server, whereas a SQMS model with priority-inversion prevention can MINIMIZE end-to-end delays in the server. But then, performance clearly is not an important consideration, or you would want a design that minimizes end-to-end transaction time in the server under high load conditions. And you would not be so insistent that we acknowlege your design must be right, when I was able to demonstrate, with third-grade arithmetic, that it isn't very good. joe On Sun, 11 Apr 2010 10:23:53 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >news:ePWHPnY2KHA.5820(a)TK2MSFTNGP06.phx.gbl... >> Peter Olcott wrote: >> >>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>> message news:eHBz1FY2KHA.4332(a)TK2MSFTNGP02.phx.gbl... >>>> Peter Olcott wrote: >>>> >>>>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>>> message news:%23psrlWX2KHA.5660(a)TK2MSFTNGP04.phx.gbl... >>>>>> Peter Olcott wrote: >>>>>> >>>>>>> Since I only need to be able to process 100 >>>>>>> transactions per second the speed of these overhead >>>>>>> sort of things should not be too critical. I am >>>>>>> guessing that the sum total of these overhead sort of >>>>>>> things will only take about 10 ms per transaction >>>>>>> most of this being drive head seek time. >>>>>> No, 10 ms is a ONLY CONVENIENT # that can be >>>>>> calculated for 100 transactions per second. It was >>>>>> not based on any real results you did. You want 100 >>>>>> tps, the work load must be 10ms. You want 1000 TPS, >>>>>> the work load is 100 ms - period: >>>>>> >>>>>> TPS = 1000/ WORK LOAD >>>>>> >>>>>> Period, period, period. >>>>>> >>>>>> There is no way on earth you can: >>>>>> >>>>>> receive a HTTP request >>>>>> parse it >>>>>> authorize it via a database >>>>>> set some status points >>>>>> delete it to some queue >>>>>> wait for a respons <----> OCR process >>>>>> wait up >>>>>> set status points >>>>>> do image processing >>>>>> set status points >>>>>> send response >>>>>> >>>>>> send HTTP response >>>>>> >>>>>> all in 10 ms - you are SICK if you think you can do >>>>>> this in 10 ms. And thats just for 1 single request. >>>>>> Throw in 99 more per second, and you are are >>>>>> completely whacked to now realize the build up our >>>>>> your queuing where each subsequent request will be >>>>>> delayed by a factor of of magical 10 ms number. >>>>>> >>>>>> Until you realize this, nothing else you saw matters. >>>>>> >>>>>> -- >>>>>> HLS >>>>> It looks like you are wrong >>>>> http://www.kegel.com/c10k.html#top >>>> >>>> You can't read and that DOCUMENT is a blab of illusions. >>>> Tell me how *YOUR PRODJECT* can SQUEEZE more time that >>>> is not available to you? >>>> >>>> 100 TPS === 1000/10ms >>>> >>>> If you go 1 ms above, you are HOSED. >>>> >>>> Lets imagine that your great Linux will do every step in >>>> its 1 ms clock tick and it is the only process in the >>>> OS. In fact, there is no other OS process kernel logic >>>> or other anything else to interrupt you. >>>> >>>> 1ms receive a HTTP request >>>> 1ms log http header >>>> 1ms save posted data on disk >>>> 1ms read HTTP and authenticate via a database >>>> 1ms set some status point >>>> 1ms delegate it to some queue >>>> 1ms wait for a respons <----> OCR process wake >>>> up >>>> 1ms set status points >>>> 1ms read posted file >>>> 1ms do image >>>> processing >>>> 1ms set status points >>>> 1ms send response >>>> 1ms send HTTP response >>> >>> I you wouldn't be so rude with me I would tone down my >>> criticism of you, but, the above sequence does show a >>> enormous degree of ignorance. >> >> No it doesn't. Its reality. You're the one with a whole >> set of design assumption based on ignorance. I speak with >> engineering experience. > >Now you are being asinine, If every little thing takes 1 ms, >then it would be at least several days before a machine was >finished rebooting. I guess there is no sense in paying >attention to you any more. > >> >> The worst case for you is 1 ms PER clock tick on your >> LINUX system and the above assumes YOU have FULL attention >> and that isn't going to be reality. While some steps can >> happen far less than 1ms, the major interface points with >> the outside world (outside your OCR box), it can take 1 or >> more clock ticks! >> >> The reality is YOU will not full attention. You will have >> interrupts, especially at each FILE I/O at the most basic >> level. >> >> You WILL NOT BE ABLE TO DO WHAT YOU WANT in 10, 20 ms per >> transactions. I say more like at BEST 50-100ms and thats >> just good engineering estimating based on all the >> ENGINEERING you want to do. >> >> We already proved that your memory I/O for 1.5GB will be >> MORE greater than 10 ms. You proved it to yourself and >> admitted how you finally realized how memory >> virtualization and fragmentation plays a role and was not >> just a figment of everyone's imagination. >> >> You need to get REAL. >> >> -- >> HLS > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 11 Apr 2010 21:56 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:kbn4s5lkiiulqtpbcrlm490s9dotepah5p(a)4ax.com... > See below... > On Sat, 10 Apr 2010 21:01:20 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: >>Right thus preventing most every or every mutual >>dependency, >>and thus the possibility of priority inversion because >>priority inversion (according to several sources) can only >>occur with some sort of mutual dependency. > ***** > You really are clueless, you know.... > > You haven't any idea what you just said, and why it is > complete gibberish. http://en.wikipedia.org/wiki/Priority_inversion If there are no shared resources then there is no priority inversion. Try and provide a valid counter-example of priority inversion without shared resources. >>Oh so then you just lied about the address space being >>separate? The best that I can tell is that the separate >>address space by itself almost completely eliminates the >>possibility of any mutual dependency, and a mutual >>dependency is absolutely required for priority inversion. > **** > No, it is only in your fantasy world that having separate > address spaces changes the > nature of how threads operate in the scheduler. Note that > if you did the same trick using Apparently not with pthreads. > multiple threads in a single process, it would work just > like you want (but the design you > want would still be bad). Moving the threads to separate > processes changes NOTHING. > **** >> >>If you don't start explaining yourself more completely I >>will reasonably assume that your whole purpose here is to >>be >>a naysayer whose sole purpose is to provide discouragement >>and you have no intention at all of being helpful. > **** > By telling you > (a) your design is bad, and why You keep forgetting the why part. > (b) your have no idea what you are talking about > (c) you are rejecting design alternatives based on > rumor, bad memory, and hearsay > (d) you are spouting nonsense when you try to justify > your bad designs > You are not explaining with much of any reasoning why you think that one alternative is better than another, and when I finally do get you to explain, it is only that your alternative is better than your misconception of my design, not the design itself. > I'm not being helpful? No not really. What you are doing is about halfway between being helpful and pure harassment. > If you were paying attention, you would realize that I > keep saying "you are wrong" because > you ARE wrong, and because, as a consequence of these > cumulative errors of judgment, you > are producing a design that will not only not be optimal, exactly what is not optimal about it? > but will fail in ways you have > not accounted Exactly what are these ways, and precisely what have I failed to account for? > for because of your naive belief that your fantasy > implementation is > perfect, you are going to end up with something that in > rhe real world does not actually > solve your problem in a meaningful way, and will always be > a third-rate solution that does > not scale up. I'm trying real hard to be helpful, but > like the proverbial mule, I > sometimes have to whack you solidly with a 2x4 to get your > attention. See what I mean ALL rhetoric and no reasoning. Pure Bullshit. I know why you don't provide reasoning, you are just faking it, you don't have the reasoning that you fail to provide. You know that there are guys that successfully fake being a medical doctor and get away within this for years? Maybe you are one of those guys. Put up of shut up bud. > And by telling you that you had better get some sound > technological basis for your > decisions, I'm not being helpful? As far as I can tell I already have these. You provided little reasoning to the contrary. > > Overall, it has been a long time since I've had someone so > CONSISTENTLY spout complete > nonsense as if it were fact. > > >> >>> threads are in separate processes does not change the >>> nature of the problem, or change the >>> fundamental weaknesses of the design. >> >>Don't call it a weakness in the design unless you also >>point >>out detail by detail exactly why you think this is a >>weakness because more often than not your whole conception >>of my design weakness is entirely based on your own false >>assumptions about my design. > **** > I did. Did you read my reply about why you will ALWAYS > get worst-case performance from > your design? Never saw that. I was so annoyed with you last night that I skipped several of your messages. It is probably yet another misconception about what my design is. One message that you posted said that my design is no good because it would not work well on a quad-core. It is not supposed to work well on platforms that it will not be running on. It is only supposed to work well on its target platform. >>See there yet another false assumption. My four OCR >>processes will only have a single thread each. I NEVER >>SAID >>OR IMPLIED OTHERWISE > **** > And I'm saying that this is, for the purposes of thread > priorities, NO DIFFERENT from > having four threads in a single process! Only YOU think > that putting them into separate Not with pthreads. With pthreads there is an infeasible degree of difference. > processes chnages the problem. There would be no mutual > dependencies even if they were > threads in the SAME process! How often do I have to say > this? Enough times until you realize that you don't know pthreads very well. > **** >>I have a bad design because you measure my design against >>your misconception of it rather then the design itself. >>Unless you provide much more detailed reasoning I have no >>way to point out your false assumptions. > **** > No, I have shown by actual calculation why your design > doesn't work well, and shown that > it maximizes response time and minimizes concurrency > (utilization of available computing > resources). I had to work it out for you because you > couldn't figure it out on your own, > even though it only involves elementary arithmetic! On a machine that is was not designed for, duh! > > The only false assumptions are the ones you are making > about IPC systems, about how > threads work, about a LOT of things we've patiently tried > to point out to you for the last > several weeks! Your nonsensical views on memory > allocaiton, memory-mapped files, paging > behavior, etc. were clearly false assumptions on your > part. The deepest failure is to No the most important one of these proved you wrong and me right, the others weren't relevant enough to verify. A memory rich system really does not need to page out a process or its data if plenty of RAM is available. >>> scheduling OCR processing sucks. It allows almost no >>> concurrency, thus maximizing latency >>> time and severely underutilizing the available computing >>> resources. >> >>I don't want to maximize the overall throughput of all >>jobs, >>I only want to maximize the throughput of the high >>priority >>jobs. I don't care if this makes all of the rest of the >>jobs >>twice as inefficient. > **** > But those people paying for the 3-minute jobs are paying > customers, right? So you're > saying "screw you for wanting premium service"? I showed > how a SQMS architecture could > achieve fast turnaround for the small, high-priority jobs > while minimizing overall > response time for ALL jobs and maximizing CPU utlization, > but I guess those are not Really > Good Ideas; instead, pick a bad design, claim it solves > the problem when it solves only a > tiny piece of the problem, and move forward. And this design all depends on a quad core that I will not have. Quad-codes cost ten times as much as single cores so I will probably never have a quad core in the foreseeable future. >>That way is makes communication far too difficult because >>this masks you own false assumptions. This makes perfect >>sense to mask your own false assumptions if the purpose is >>to provide discouragement rather than to be helpful. If >>you >>continue to mask your false assumptions in this way I will >>give up on you. > **** > Please, please give up! I'm getting tired of saying the > same things over and over. Then start with something entirely new like explaining your reasoning. Whenever you do, then I can see where you went wrong. You proposed SQMS based on the false assumption of a quadcore, when I finally forced this out of you I could see it was a false assumption. > You have deeply false assumptions. Your statement that > TCP will drop packets shows a new I am 90% sure that this statement is true: If the local buffer is full, then subsequent packets are ignored. > But you did not state the assumptions of your design > decision, you just said "I reject > this because it has finite buffer size" and it is pretty > obvious to most people that ANY > mechanism that requires kernel buffers is going to have a > finite buffer size! I didn't I stated my assumption many times and you never refuted it. I still don't understand why the kernel buffer can not grow to arbitrary size, RAM is RAM right? > know it was 4K, but I knew it would be reasonably small > (perhaps, generously, 64K). You > rejected transacted file systems based on some myth about > performance (inability to do a > direct seek, as if this would matter in the slightest). > But it takes two or three > messages before you come out and give your rationale for > your choices, and then, and only > then, do we realize you are making decisions based on > either lack of information or > completely wrong-headed ideas about what is going on. I know full and well that the biggest overhead of the process is going to be disk access. I also know full and well that tripling the number of disk access would likely triple overhead. I am not sure that SQLite is not smart enough to do a record number based seek without requiring an index. Even if SQLite is not smart enough to do a record seek without an index, it might still be fast enough. You convinced me that using an existing provider would tend to result in higher reliability and/or lower development costs. So its worth a shot trying it. If SQLite does lack the ability to do a direct record number seek , and it is too slow without this capability, I could always add this feature myself. > > If you make silly statements, I will tell you that you are > clueless. Your discussion of > interrupts wasn't even CLOSE to how the hardware works, or > how any real operating system > works. After several days of making nonsensical > statements about transacted file systems > (apparently confusing atomic file actions with atomic > transactions), you finally located > an article that explained what was going on, and > essentially confirmed everything we had > been telling you for days. Has it occurred to you that we > might be right about a lot of > other things? > joe You (and Hector) are definitely right on some things. > ***** >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 11 Apr 2010 22:08 See below... On Sun, 11 Apr 2010 12:43:15 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >news:%237Nwl2Y2KHA.6048(a)TK2MSFTNGP06.phx.gbl... >> Peter Olcott wrote: >> >>>> No it doesn't. Its reality. You're the one with a whole >>>> set of design assumption based on ignorance. I speak >>>> with engineering experience. >>> >>> Now you are being asinine, If every little thing takes 1 >>> ms, then it would be at least several days before a >>> machine was finished rebooting. I guess there is no sense >>> in paying attention to you any more. >> >> >> Because YOU can't handle the TRUTH and I keep proving it >> and even and every step in this polluted thread. Joe >> tells you the truth and you can't handle it. I tell you >> the truth and you can't handle it. >> >> You have a MANY THREAD to 1 FIFO QUEUE >> >> - IGNORANCE EQUAL PRESSURE >> >> You want to use SQLITE in a WAY it was not designed to >> work with a complete unrealistic freedom for read/write >> I/O that even DESIGNED in SQLITE: >> >> - IGNORANCE EQUAL PRESSURE >> >> You think that because LINUX allows for 1 ms clock ticks >> that you can get 1 ms Unterrupted QUANTUMS. It doesn't >> mean you can get 1 ms of real time - but 1 ms of TOTAL >> time - that is not real time. > >Like I told Joe it is beginning to look like reading the >10,000 pages of books that I recently bought is going to be >much more efficient and effective in proceeding from here. >One of these books provides the details of internals of the >Linux kernel. **** We've read many of those books, and more importantly, we've built real systems and used real APIs and measured the hell out of them, and we know what works and what doesn't work. But when we tell you that you are completely wedged, you accuse us of being in "refute" mode, of "not being helpful". That's because we don't plan to spend 10,000 pages training you (although it feels like we have). Actually, I think it is a Really Good Idea that you would read some of those pages; given the nonsense you've been spouting recently, you could use a little fundamental education. In addition to most details of operating systems, you got nearly ever detail of hardware interrupts and their relationship to applications wrong; you got most of the details of paging and how it works wrong; you managed to get nearly every concept of virtual memory wrong. So yes, please, go read some books. And a student book on linux internals is not going to be really helpful, except to clear up your fundamental misunderstandings. But it won't help you build a high-performance system, because it is not the APIs, but how you assemble them into a functional sequence that matters (we call it "application architecture", in case you need to catch up to the jargon) joe **** > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 11 Apr 2010 22:11 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:O2mJq3d2KHA.2284(a)TK2MSFTNGP06.phx.gbl... > > Peter Olcott wrote: > > Joe, at least so far we got him to: > > - Admit to lack of understanding of memory and he > himself reduced > the loading requirement rather than code for any large > memory > efficiency methods. No. Joe was and continues to be wrong that a machine with plenty of extra RAM ever needs to page out either a process or its data. > > - Admit that his 100 TPS was unrealistic for a 10 ms > throughput > that lacked consideration for the interfacing > processing time > outside the vapor ware OCR processor. So he added > another > 10 ms and reduced the TPS now to 50. No, the latest analysis indicates that I am back up to 100 because the webserver and the OCR execute in parallel. > > Joe, I don't know about you, but I still got a few tooth > left to be > pulled! :) > > Next he needs to realize the request do not come in > equally time laid out fashion! > > 20ms, 20ms, 20 ms, ,,,,,,,,,,,,,, 20ms = 50 TPS! > > How does he plan to scale burst of request? > > How does he plan to delegate the HTTP POSTING and control > cross domains waste time? > > He basically does not see the queue accumulation! > -- > HLS The only way this site is going to ever get too long of a queue is if too many free jobs are submitted. Do you really think that this site is ever going to be making $10.00 per second? If not then I really don't have to worry about queue length. In any case I will keep track of the average and peak loads.
From: Peter Olcott on 11 Apr 2010 22:33
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:72v4s5lhuvgvdnnal8rf6h1dpmkqntm0p8(a)4ax.com... > So prove any of us wrong. MEASURE a real system and tell > us what numbers you get! > > There is no other truth than the actual system. You have > two interesting parameters to > measure > end-to-end transaction time from the client > end-to-end transaction time in the server > > I already pointed out your MQMS model can give MASSIVE > end-to-end delays in the server, What is the exact scenario that produces this massive delay? > whereas a SQMS model with priority-inversion prevention > can MINIMIZE end-to-end delays in > the server. On a single core processor? If it does I don't see how. You have to explain these details. On a quad core it is almost obvious how it could help. > > But then, performance clearly is not an important > consideration, or you would want a > design that minimizes end-to-end transaction time in the > server under high load > conditions. And you would not be so insistent that we > acknowlege your design must be No it is just you ignoring design constraints again. Single core not quad core. > right, when I was able to demonstrate, with third-grade > arithmetic, that it isn't very > good. > joe > |