Can extra processing threads help in this case?
in [MFC]
|
From: Peter Olcott on 8 Apr 2010 09:56 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:s7hqr5ts61vs6sdujs12183uuqktpd8k6v(a)4ax.com... > See below... > On Wed, 07 Apr 2010 19:38:16 -0400, Hector Santos > <sant9442(a)nospam.gmail.com> wrote: > >>Peter Olcott wrote: >> >>>> That means you can only handle 10 request per second. >>> >>> No it does not. 100 ms is the real-time limit, actual >>> processing time will average much less than this, about >>> 10 >>> ms. >> >> >>Now you are even more unrealistic. That means for a 100 >>TPS, >>you need now need 100 threads. >> >>But I want you to lookup the term Thread Quantum. > *** > A scheduler quantum is 2 timer ticks, or 30ms. Buf if a > thread completes in 10ms, it will > go to sleep waiting for the next request, and some other > thread will immediately become > runnable. So while the nominal scheduling quantum is > 30ms, you really could complete 3 > 10ms transactions in a single quantum, even if they are in > different threads. Note also > that Vista+ redefined how the scheduler deals with partial > quanta in the scheduler (see > Russinovich's article, but I don't have a citation to it; > it was in the list of new > features in Vista article) > joe That sure sounds reasonable to me. Implementing this otherwise would seem to be incorrect. > *** >> >>In short, what you are claiming is that your complete a >>request and >>processing in 1 CPU cycle of context switching. A quantum >>is around >>~15 ms on multi-core/processors. >> >>>> No matter how you configure it, 10 threads in 1 >>>> process, >>>> 10 processes on 1 machine or across machines, you need >>>> at >>>> least 10 handlers to handle the 100 TPS with 100 ms >>>> transaction times. >>> >>> 10 ms transaction time >> >> >>Unrealistic. Dreaming. > 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 8 Apr 2010 15:57 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:32qpr51j8nlveopnqnj84isof55m4ut00q(a)4ax.com... > See below... > >>Plus what happens if the machine crashes? You lost what >>hasn't been >>flush. The different is you lower any issues at the >>expense at some >>speed and open/close overhead which will be very minor for >>you. > **** > Part of the issue here is what is meant by "flush", and a > difference between the buffers > held in the application and the buffers held in the > kernel. > But this does not seem to be of much concern to our OP, > who "knows" that there must be a > way to force the caches to the platters (my evidence says > it ain't so, or at least it > wasn't so with vehment opposition to ever making it so), > and so this magical mechanism > will solve all the problems. > **** If my understanding is correct fsync() is supposed to handle both. http://linux.die.net/man/2/fsync It might be the case that I must use the low level open() command so that there are no application buffers. Also the experts seem to be saying that the drive's own onboard cache is not much of an issue if there is UPS. There are some ways to force some drives to empty their onboard cache. The only way that is supposed to always work is to turn write buffering off. This can really hurt hard-drive performance. >>It helps to have a single point I/O controller, but how >>are you >>planning to use this thread? How will you talk to it? >>IOW, now you >>really need to make sure you have synchronization. > **** > If one thread handles the file, then no "synchronization" > is required because all requests > serialze through this one thread. It is an approach > called the "agent pattern". It looks like clarification from the Linux/Unix experts indicate that this would be required for my transaction log. > This is another confusion; apparently an atomic append is > sufficient to guanratee > transactional integrity in his fantasy world. In the real > world, an atomic append is > guaranteed to atomically append data. Whether or not this > constitutes a transaction is > problematic, and probably incorrect. It can perfectly > well guarantee that the in-memory > disk-cache image is atomically appended to without EVER > saying that it guarantees the > commit of this data to the drive. In fact, pwrite > documentation is completely silent on > this point! > ***** >>So it every other IPC concept. For your need, named pipes >>is more >>complex and can be unreliable and very touchy if you don't >>do it >>right. I mean, your I/O needs to be 100% precise and that >>can't be >>done in less than 20-30 lines of code, and for what you >>need, 3-4 >>lines code is sufficient. > **** > Apparently, he thinks that a database can't a FIFO queue > because he once read that SQLLITE > doesn't have a record number, or something else silly like > that. He missed the idea thata > a FIFO queue is a FIFO queue and ANY stream-oriented > protocol (including TCP/IP to the > local machine!) could be a valid implementation; instead, > he fastened on one And its buffer would automatically grow to any required length and automatically shorten as items are removed? > implmenetation, "named pipe" (which in linux means > something completelydifferent from the > Windows concept) and intantly fallen in love with it, to > the ezclusion of the > consideration of any other method. He even asserted, > without any substantitating data, > that implementing a FIFO using SQLLITE would have > unacceptable overheads because it > couldn't compute a seek address directly! (DUH! Like that > matters! NO DATA == NONSENSE; > if there is any concern about performance, ONLY > MEASUREMENT WILL PRODUCE MEANINGFUL DATA, > but he is so enaboured of his "think" system, or Tarot > cards, or Ouija board, or whatever > he is using, that real data is not a consideration) > ***** >> >>Unless you get Named Pipe class that will do all the work, >>error >>checking, like error 5/32 sharing violation timings, etc, >>exceptions, >>proper full duplex communications, you can certainly run >>into a ugly >>mess. I don't recommend it for you. You don't need it. > **** I think that many of these issues may go away by using two half-duplex named pipes one in each direction. No one has yet pointed out any issues with Unix/Linux named pipes. I like named pipes because the implement the FIFO intuitively with minimal learning curve.
From: Hector Santos on 8 Apr 2010 16:30 Peter Olcott wrote: > I think that many of these issues may go away by using two > half-duplex named pipes one in each direction. No one has > yet pointed out any issues with Unix/Linux named pipes. I > like named pipes because the implement the FIFO intuitively > with minimal learning curve. I can only hope that one day you will actually begin your work, so you can see how great it will work. Google: named pipe problems http://www.google.com/search?q=named+pipe+problems&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official When our multi-million dollar server was first under design back in the mid 90s, name pipes was going to be used. We saw almost immediately how unreliable it was a for a high end, high throughput, high multi-thread WAN/LAN network server. Not saying you can make it work, but you will spend more time on getting that right than anythingelse and for what? A fifo? When there are so many other more reliable methods and simpler methods? But hey, it will probably work for you because I sincerely doubt you will have the work load you predict you will have. You are basing this on a 10ms throughput and you won't have that. You can't. Even if your OCR is isolated to pure 10 ms computation, which LINUS will give you, its surrounding world is YOUR enemy that you can't avoid, like your fifo receiver, like file I/O logging, your PIPE is a FILE on UNIX as well, which has hardware interrupts, like generating results, etc. Live and learn. Which leads to the questions, if you are going to design for Linux, then; Why are you trolling in a WINDOWS development forum? Why are you here asking/stating design methods that defies logic under Windows when YOU think this logic is sound under UNIX? If you are going to design for Windows, then you better learn how to follow WINDOWS technology and deal with its OS and CPU design guidelines. -- HLS
From: Peter Olcott on 8 Apr 2010 16:44 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:uhFwgp11KHA.140(a)TK2MSFTNGP05.phx.gbl... > Peter Olcott wrote: > > >> I think that many of these issues may go away by using >> two half-duplex named pipes one in each direction. No one >> has yet pointed out any issues with Unix/Linux named >> pipes. I like named pipes because the implement the FIFO >> intuitively with minimal learning curve. > > > I can only hope that one day you will actually begin your > work, so you can see how great it will work. > > Google: named pipe problems > > http://www.google.com/search?q=named+pipe+problems&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official > > When our multi-million dollar server was first under > design back in the mid 90s, name pipes was going to be > used. We saw almost immediately how unreliable it was a > for a high end, high throughput, high multi-thread WAN/LAN > network server. First of all are you talking about named pipes in Windows or Unix/Linux? > > Not saying you can make it work, but you will spend more > time on getting that right than anythingelse and for what? > A fifo? When there are so many other more reliable > methods and simpler methods? > What simpler more reliable methods are you referring to that can provide event based notification between processes? > But hey, it will probably work for you because I sincerely > doubt you will have the work load you predict you will > have. You are basing this on a 10ms throughput and you > won't have that. You can't. Even if your OCR is isolated > to pure 10 ms computation, which LINUS will give you, its > surrounding world is YOUR enemy that you can't avoid, like > your fifo receiver, like file I/O logging, your PIPE is a > FILE on UNIX as well, which has hardware interrupts, like > generating results, etc. > > Live and learn. Which leads to the questions, if you are > going to design for Linux, then; > > Why are you trolling in a WINDOWS development forum? > > Why are you here asking/stating design methods that > defies logic > under Windows when YOU think this logic is sound under > UNIX? > > If you are going to design for Windows, then you better > learn how to follow WINDOWS technology and deal with its > OS and CPU design guidelines. > > -- > HLS
From: Hector Santos on 8 Apr 2010 17:47
Answer my questions and I'll answer yours (which was done a few times already). If you are going to design for Linux, then; Why are you trolling in a WINDOWS development forum? Why are you here asking/stating design methods that defies logic under Windows when YOU think this logic is sound under UNIX? If you are going to design for Windows, then you better learn how to follow WINDOWS technology and deal with its OS and CPU design guidelines. -- HLS Peter Olcott wrote: > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:uhFwgp11KHA.140(a)TK2MSFTNGP05.phx.gbl... >> Peter Olcott wrote: >> >> >>> I think that many of these issues may go away by using >>> two half-duplex named pipes one in each direction. No one >>> has yet pointed out any issues with Unix/Linux named >>> pipes. I like named pipes because the implement the FIFO >>> intuitively with minimal learning curve. >> >> I can only hope that one day you will actually begin your >> work, so you can see how great it will work. >> >> Google: named pipe problems >> >> http://www.google.com/search?q=named+pipe+problems&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official >> >> When our multi-million dollar server was first under >> design back in the mid 90s, name pipes was going to be >> used. We saw almost immediately how unreliable it was a >> for a high end, high throughput, high multi-thread WAN/LAN >> network server. > > First of all are you talking about named pipes in Windows or > Unix/Linux? > >> Not saying you can make it work, but you will spend more >> time on getting that right than anythingelse and for what? >> A fifo? When there are so many other more reliable >> methods and simpler methods? >> > > What simpler more reliable methods are you referring to that > can provide event based notification between processes? > >> But hey, it will probably work for you because I sincerely >> doubt you will have the work load you predict you will >> have. You are basing this on a 10ms throughput and you >> won't have that. You can't. Even if your OCR is isolated >> to pure 10 ms computation, which LINUS will give you, its >> surrounding world is YOUR enemy that you can't avoid, like >> your fifo receiver, like file I/O logging, your PIPE is a >> FILE on UNIX as well, which has hardware interrupts, like >> generating results, etc. >> >> Live and learn. Which leads to the questions, if you are >> going to design for Linux, then; >> >> Why are you trolling in a WINDOWS development forum? >> >> Why are you here asking/stating design methods that >> defies logic >> under Windows when YOU think this logic is sound under >> UNIX? >> >> If you are going to design for Windows, then you better >> learn how to follow WINDOWS technology and deal with its >> OS and CPU design guidelines. >> >> -- >> HLS > > |