Can extra processing threads help in this case?
in [MFC]
|
From: Jerry Coffin on 13 Apr 2010 00:24 In article <G96dnWTQUsVBfF7WnZ2dnUVZ_sydnZ2d(a)giganews.com>, NoSpam(a)OCR4Screen.com says... [ ... ] > None. A Single queue might work well with multiple threads > of a single process because IPC does not need to occur. The > MQ is because multiple processes require IPC. So if I understand your point correctly, your plan is to run four separate web servers, each with an OCR engine linked in, simply so you can avoid the single shared queue, so that right? [ ... ] > A single queue is much more difficult. Write at whatever > location is appropriate at the moment and read from the head > of whichever portion of the queue applies to this priority. > What do you do a linear search for the head? If you don't do > a linear search and keep track of the different heads > separately then this is essentially four queues, simply > strung together. How can that be better than four queues? A priority queue is normally implemented as a binary heap. It involves no linear searches and no separate heads. It has a number of advantages, such as sharing memory between the queues, so instead of a separate hard limit for each priority level, you get one limit on total tasks in the queue. It's also easy to scale. It's easy to have it keep your multiple processing engines busy. I know you've said the processor side is fixed in concrete -- let me point out that you're just plain wrong. ISPs come and go. Pricing changes faster still. You're looking at a great deal simply because it's an ancient machine -- but when it dies (and an already hot running Pentium IV running OCR will die, and soon) that pricing will be gone. You say you've already spent 10 years on this -- but now you're basing decisions that should last another 10 years on a price quote that may not last through the end of the month. The supply of Pentium IV's used by ISPs is small and shrinking fast. Making long term decisions based on this factor is just plain foolish. You've also mentioned the possibility of using a cluster to run the application -- but that won't work with the design you're talking about. If running on a cluster is even a remote possibility, you need to allow for the web server and OCR engine not only be separate processes, but run on completely separate machines. -- Later, Jerry.
From: Peter Olcott on 13 Apr 2010 00:39 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:kqi7s5d0fprv9hj06qs523814qdadvovq9(a)4ax.com... > See below... > On Mon, 12 Apr 2010 14:51:04 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >>Whoops you already lost something there. There are TWO >>count >>em TWO options. Only one of the options involves yielding, >>the other one involves time slicing. > **** > SO why do you even need an option of yielding? Gratuitous > complexity that serves no > useful purpose. THat's what the OS is for, so why do you > need to duplicate its > functionality? > **** It depends upon exactly how the Linux scheduler works whether or not it would provide any benefit. I really want to provide absolute priority of the high priority jobs over the lower priority jobs. If Linux can already do this then the yielding option makes no sense. >>THIS DESIGN REQUIREMENT IS IMMUTABLE >>The design goal is to somehow provide the means for the >>high >>priority jobs to has absolute priority over the lower >>priority jobs these lower priority jobs all have equal >>priority relative to one another. The proposed approach >>must meet the above stated design goal as closely as >>possible on a PENTIUM 4 computer. > **** > MY PROSE IS IMMUTABLE said Hemingway, one day. Please > reconcile your Hemingway allusion > with a belief that your design is perfect. The notion > that low priority threads "sleep" > is at best an implementation consideration, NOT a design > requirement, unless by EXACTLY WHERE DID I SAY SLEEP IN THE ABOVE DESIGN REQUIREMENT? Even when pointed out to you countless times that you read things that I have not said you continue making this same mistake. Can I ask you a personal question? Are you in your eighties? If these mistakes that you are making are not your fault I will be much kinder and gentler with you. I had assumed that they are merely a form of harassment. If you are doing the best that you can and these mistakes are unintentional, I sincerely and humbly apologize for uttering the slightest nuance of any unkind word.
From: Peter Olcott on 13 Apr 2010 00:44 "Jerry Coffin" <jerryvcoffin(a)yahoo.com> wrote in message news:MPG.262d9fa7ec108197989873(a)news.sunsite.dk... > In article > <G96dnWTQUsVBfF7WnZ2dnUVZ_sydnZ2d(a)giganews.com>, > NoSpam(a)OCR4Screen.com says... > > [ ... ] > >> None. A Single queue might work well with multiple >> threads >> of a single process because IPC does not need to occur. >> The >> MQ is because multiple processes require IPC. > > So if I understand your point correctly, your plan is to > run four > separate web servers, each with an OCR engine linked in, > simply so > you can avoid the single shared queue, so that right? Not at all, but, when you state your assumptions then I can correct them. I will have one single web server process that connects to four separate OCR processes using some sort of FIFO queue, one for each OCR process. >> A single queue is much more difficult. Write at whatever >> location is appropriate at the moment and read from the >> head >> of whichever portion of the queue applies to this >> priority. >> What do you do a linear search for the head? If you don't >> do >> a linear search and keep track of the different heads >> separately then this is essentially four queues, simply >> strung together. How can that be better than four queues? > > A priority queue is normally implemented as a binary heap. > It > involves no linear searches and no separate heads. > > It has a number of advantages, such as sharing memory > between the > queues, so instead of a separate hard limit for each > priority level, > you get one limit on total tasks in the queue. It's also > easy to > scale. It's easy to have it keep your multiple processing > engines > busy. No advantage that I can see that is worth the cost.
From: Peter Olcott on 13 Apr 2010 00:46 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:i1l7s5ppjg7n50kgbidakbjqit8mpp8fpq(a)4ax.com... > See below.... > On Mon, 12 Apr 2010 18:10:04 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"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? >> > **** > You gave us the citation to the article that proves it. > And anyone who has ever studied > elementary queueing theory knows this. I suggest an > introductory book on queueing theory. > But then, I once studied this, and I don't need the > details again, I have already examined > the problem, nearly forty years ago, and know what the > answer is. I don't need to > re-derive the equations; I did that back in 1969 or 1970, > and the only thing I needed to > remember was that SQMS is a superior architecture. OK got any good links? > > The book on queueing theory that I have has been out of > print since the late 1970s, so > there's no point in giving the citation. > > You are such an expert, why aren't you proving that MQMS > is superior? > ***** >> > 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 13 Apr 2010 00:52
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:c1m7s5tsik5kv03g41kk37arm74a5jj5pk(a)4ax.com... > See below... > On Mon, 12 Apr 2010 16:16:45 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > > The rule on receive: it is a stream orientation; it > receives as much as it currently has, > and this is independent of the sequence of send > operations. And since recv takes an > explicit length of the buffer it is going to fill, it > cannot "receive much more than it > can handle". It receives EXACTLY AS MUCH as it can > handle. > > But since you've never written any network code, you can > be forgiven for being totally > ignorant of such an elementary fact, and of course, you > would NEVER base a design decision > on information you had not validated. Superb designers > NEVER do that. Nor would you make > an implementation decision based on false assumptions part > of your requirements document > or design document. Superb designers NEVER do that. > > Look up "Nagle's Algoirthm". > > A recv cannot "receive much more than it can handle", and > if you knew ANYTHING about > TCP/IP, you would know that the receiver NEVER tells the > sender that it can send more > information than the receiver has buffer space to handle > (it is erroneous to tell the > sender you have more buffer space than you have). > > Instead of reading trash, try reading real books about how > TCP/IP works, e.g., page 202 of > Douglas Comer's "Programming with TCP/IP, Volume 1, Third > edition". But I guess that > reality is not going to impinge on your decision process. > That would actually require > judgment. And fundamental skills in comprehension of > information. > > The ACK packet contains a specification of the buffer > size, cleverly encoded. But I guess > my nasty tendency to have developed and taught courses on > this subject disqualifies me > from offering any expert opinion, certainly less expert > than "somewhere probably in the > web server specs".as a citation. > > Note that this might refer to how the Web server is > implemented, which is an application > issue, not a network-protocol issue. But hey, what's a > little fact distortion? you can't > make good implementation decisions or write good > requirements unless you have a bit of > gossip to design by! > joe I am doing the best that I can there is a lot of information overload so it is far too easy to get things wrong. > **** >> >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |