Can extra processing threads help in this case?
in [MFC]
|
From: Peter Olcott on 12 Apr 2010 16:53 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:aqk6s5h3hjvp5drio1iqfqimj2b269r3ad(a)4ax.com... > See below... > On Mon, 12 Apr 2010 10:05:29 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >>The alternative that you show quoted above is called time >>slicing and has been available for many decades. > **** > And therefore timeslicing takes ZERO overhead, right? And > you are still thinking that > mucking with thread priorities is going to result in a > flawless design (and if you start > ranting about how "thread" and "processes" are different, > you will only confirm that you > are completely and utterly clueless) It looks like using nice to provide both the webserver and exactly one of four OCR processes a priority of exactly -1 is the best solution. So far no one has provide sound reasoning to the contrary. Likewise with four queues and four OCR processes on a PENTIUM 4. The priority queue may work very well on a quad-core, I see no way to implement it to meet my design goals on a PENTIUM 4. >>Block IP long before that. > **** > WHat IP? You clearly have some bizarre notion that the IP > is unforgeable. If I wanted to > do a D-O-S on your site, I'd change the IP with every > transmission. You have some awfully > naive views about the goodness of the world. Or are we > talking about Peter's Fantasy > Internet, where everyone is well-behaved, there are not > D-O-S attacks, and nobody EVER > emails a virus? How else do you block a DoS attack?
From: Hector Santos on 12 Apr 2010 17:21 Peter Olcott wrote: > The ONLY purpose of the free jobs is to get paying jobs. The > only way that a free job would never get done is it my > website is earning $10 per second 24/7/365. $864,000 per > day. Long before that ever happens I will set up a cluster > of servers just for the free jobs. Geez, practically $1 Million a day, nearly 1/3 billion a year and you you still reading books nor written a "Hello World!" program? I got a great name for your vapor product - Peter Meter! Tell ya what, write me a check for $432K and I will have it done for you, in, hmmmm lets say, 3 days. Ok, ok, multiply that by 3. Look at this way, your break even point would be 4 hours once done! -- HLS
From: Peter Olcott on 12 Apr 2010 17:39 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:jfo6s55kuakr6gadh3uf62ech1q5povpmu(a)4ax.com... > See below... > On Sun, 11 Apr 2010 23:29:51 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >>Four processes four queues each process reading only from >>its own queue. One process having much more process >>priority >>than the rest. Depending upon the frequency and size of >>the >>time slices this could work well on the required single >>core >>processor. > **** > As I pointed out, this still guarantees worst-case > performance, even on a single-core CPU! Yup you've pointed that out numerous times. What you have not yet pointed out is why you think this is so. >>I knew this before you said it the first time. The >>practical >>If it doesn't require a separate index to do this, then >>the >>record number maps to a byte offset. Since record numbers >>can be sequenced out-of-order, in at least this instance >>it >>must have something telling it where to go, probably an >>index. Hopefully it does not always make an index just in >>case someone decides to insert records out-of-sequence. > ***** > Sadly, this keeps presuming details of implementation that > have not been substantiated by > any actual measurements. Yes it is much faster to do it this way. I don't build a system and then test it to see if I built it correctly. I go through many interpolations upon an optimal design before I begin building. I only resort to testing if the answer can not be otherwise obtained. This answer might be testable with minimal effort. In any case I want to know in advance what my options are, and the boundaries of these options. It does look like the disk seek time cost of the transactions might prove to be the binding constraint on my TPS. This is because each transaction takes at least one disk seek, and at 9 ms per seek this is only 111 TPS.
From: Peter Olcott on 12 Apr 2010 19:10 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:43p6s59eci43p0rhj5ms1hseo67a60eaek(a)4ax.com... > See below... > On Mon, 12 Apr 2010 01:19:15 -0400, Hector Santos > <sant9442(a)nospam.gmail.com> wrote: > >>But you have not done that. > **** > I guess I don't see the false assumption anywhere; SQMS > will run circles around MQMS any > day of the week for optimizing throughput. Ok there is the dogma, now where is the supporting reasoning?
From: Peter Olcott on 12 Apr 2010 19:43
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:ppq6s5dvd9d7a50gdnuo6ari00e0pn43fo(a)4ax.com... > See below... > On Sun, 11 Apr 2010 19:05:19 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: >>My goal is to provide absolute priority of the high >>priority >>jobs over all the other jobs, SQMS can't do that. I can't >>see how it isn't a more complex design lacking any >>incremental benefits. Four Queues each with their own >>process only involves each process seeing if it has a job >>in >>its own queue. My purpose of IPC in this case to tell the >>process that it does have a new job in its queue. > **** > Sorry, you have missed the point. OF COURSE SQMS can do > this, even on a single-core > machine from the Museum of Obsolete Computers. I even > have explained how this modern > concept, "time slicing", makes it work. Please > demonstrate how it cannot work! The scheduler pulls off the priority sorted jobs in priority order. Since there are no high priority Jobs the scheduler begins a 3.5 minute low priority job. Immediately following this a high priority job arrives. After the 3.5 minute job completes, the scheduler begins the high priority job that has now exceeded its real-time threshold by a factor of 35-fold. >>Mostly what both you and Hector have been doing is forming >>an erroneous view of what I am saying based on false >>assumptions of what I am meaning and then point out how >>bad >>this misconception of what I am saying is without pointing >>out even why the misconception itself is bad. When you do >>this I have no way to correct the misconception. > And, a complete reluctance to do anything to prove we are > right or wrong. The only I can neither prove nor disprove dogma, (there just isn't enough to work with) I can only work with reasoning. > experiment you ever ran (and it took several days of > badgering by us before you ran it) > was on the paging behavior. A discrete event simulation > will show that SQMS is going to > beat MQMS. We designed these algorithms on single-core > mainframes in the 1960s (in those > days, we called it "batch processing"), and nothing has > changed that makes MQMS work > better. If they work better then there is a reason why they work better if there is not a reason why they work better then they don't work better. Please provide the reasoning. As soon as I see sound reasoning that refutes my view, I change my view. |