Can extra processing threads help in this case?
in [MFC]
|
From: Joseph M. Newcomer on 26 Mar 2010 15:42 See below... On Fri, 26 Mar 2010 13:31:36 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Tom Serface" <tom(a)camaswood.com> wrote in message >news:OxTzNBRzKHA.264(a)TK2MSFTNGP05.phx.gbl... >> We just use IIS for our intranet web applications. We can >> install it on our servers as they are manufactured and >> it's really easy to set up. >> >> There are restrictions to doing web applications of >> course, but you can do a lot of coding server-side if you >> know the server will have access and permission to update >> areas on the intranet. >> >> Tom > >My trick is to make this web server installed a the client >site have as close to as possible impenetrable security >because I am adding trade secret to my intellectual property >protection. I think that I have this essentially figured >out. > >The one part that I do not have completely figured out is >exactly how I can make it close to impossible for anyone to >physically open the machine without detection. I have >figured out ways to make this mostly (but not completely) >moot. I have also figured out ways to make case access >security extremely difficult to circumvent. *** The Standard Model of physical security goes like this: It is buried twelve feet deep in a 3-foot-thick concrete vault in the middle of an active artillery range in the middle of a secure military base. For dead-certain security, there are no wires leading into it, and it is turned off, and there is no nearby power supply. Another model surrounds it by vicious pit bulls, but unless you have done background checks on the pit bulls, you cannot really be sure this is safe. One of them might be in the pay of your competitor. A pound of prime rib can buy a lot of loyalty in a pit bull. The simplest model is that you, personally, guard the machine, armed with some illegal automatic weapon. That's 24/7, so don't plan on sleeping, eating, or dealing with bodily functions. All other methods are not considered trustworthy in the absolute sense. [A friend once had a tour of the NSA. In one room, inside a Faraday cage, there was a battery power supply running a PDP-11 with a hard drive attached. And a Marine guard, armed with a .45 pistol. His orders: should anyone attempt to enter the room by force, he was to draw his weapon, and shoot the disk. Now THAT'S physical security!] Physical access is not your problem; this is the problem of your ISP, and their physical security system. This is what you are paying for. Not just a CPU, a bit of wire, and a UPS system! joe > >> >> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >> news:toydnSprNqitejHWnZ2dnUVZ_sidnZ2d(a)giganews.com... >>> >>> "Tom Serface" <tom(a)camaswood.com> wrote in message >>> news:uiYs3GQzKHA.5040(a)TK2MSFTNGP02.phx.gbl... >>>> Hi Peter, >>>> >>>> I don't think the proximity is the only gating factor. >>>> Bandwidth for connected servers, the path of the data, >>>> etc. all matter. If your users are directly connecting >>>> to your server it may make a difference. It must make >>>> some sort of difference because every professional >>>> download site I know of has multiple "mirror" sites so >>>> that you can select one closest to you. If nothing >>>> else, distributing it may make some people use other >>>> servers and spread the cycles needed to read and send >>>> the data off a little less arduous. >>>> >>>> Tom >>> >>> Yes, and it also just occured to me that in special cases >>> I may even be able to provide an intranet webserver. >>> > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 26 Mar 2010 15:51 You forget to mention TEMPEST ready computers, monitors, wires, etc. Joseph M. Newcomer wrote: > See below... > On Fri, 26 Mar 2010 13:31:36 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >> "Tom Serface" <tom(a)camaswood.com> wrote in message >> news:OxTzNBRzKHA.264(a)TK2MSFTNGP05.phx.gbl... >>> We just use IIS for our intranet web applications. We can >>> install it on our servers as they are manufactured and >>> it's really easy to set up. >>> >>> There are restrictions to doing web applications of >>> course, but you can do a lot of coding server-side if you >>> know the server will have access and permission to update >>> areas on the intranet. >>> >>> Tom >> My trick is to make this web server installed a the client >> site have as close to as possible impenetrable security >> because I am adding trade secret to my intellectual property >> protection. I think that I have this essentially figured >> out. >> >> The one part that I do not have completely figured out is >> exactly how I can make it close to impossible for anyone to >> physically open the machine without detection. I have >> figured out ways to make this mostly (but not completely) >> moot. I have also figured out ways to make case access >> security extremely difficult to circumvent. > *** > The Standard Model of physical security goes like this: > > It is buried twelve feet deep in a 3-foot-thick concrete vault in the middle of an active > artillery range in the middle of a secure military base. > > For dead-certain security, there are no wires leading into it, and it is turned off, and > there is no nearby power supply. > > Another model surrounds it by vicious pit bulls, but unless you have done background > checks on the pit bulls, you cannot really be sure this is safe. One of them might be in > the pay of your competitor. A pound of prime rib can buy a lot of loyalty in a pit bull. > > The simplest model is that you, personally, guard the machine, armed with some illegal > automatic weapon. That's 24/7, so don't plan on sleeping, eating, or dealing with bodily > functions. > > All other methods are not considered trustworthy in the absolute sense. > > [A friend once had a tour of the NSA. In one room, inside a Faraday cage, there was a > battery power supply running a PDP-11 with a hard drive attached. And a Marine guard, > armed with a .45 pistol. His orders: should anyone attempt to enter the room by force, he > was to draw his weapon, and shoot the disk. Now THAT'S physical security!] > > Physical access is not your problem; this is the problem of your ISP, and their physical > security system. This is what you are paying for. Not just a CPU, a bit of wire, and a > UPS system! > joe > >>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>> news:toydnSprNqitejHWnZ2dnUVZ_sidnZ2d(a)giganews.com... >>>> "Tom Serface" <tom(a)camaswood.com> wrote in message >>>> news:uiYs3GQzKHA.5040(a)TK2MSFTNGP02.phx.gbl... >>>>> Hi Peter, >>>>> >>>>> I don't think the proximity is the only gating factor. >>>>> Bandwidth for connected servers, the path of the data, >>>>> etc. all matter. If your users are directly connecting >>>>> to your server it may make a difference. It must make >>>>> some sort of difference because every professional >>>>> download site I know of has multiple "mirror" sites so >>>>> that you can select one closest to you. If nothing >>>>> else, distributing it may make some people use other >>>>> servers and spread the cycles needed to read and send >>>>> the data off a little less arduous. >>>>> >>>>> Tom >>>> Yes, and it also just occured to me that in special cases >>>> I may even be able to provide an intranet webserver. >>>> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm -- HLS
From: Joseph M. Newcomer on 26 Mar 2010 15:50 See below... On Thu, 25 Mar 2010 19:20:38 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:64onq5dabohqabp4htku20ajb8q96r06s1(a)4ax.com... >> See below... >> On Thu, 25 Mar 2010 10:12:56 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> >>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>message news:00rmq5hctllab7ursv8q64pq5eiv8s82ad(a)4ax.com... >>>> See below... >>>> On Thu, 25 Mar 2010 00:01:37 -0500, "Peter Olcott" >>>> <NoSpam(a)OCR4Screen.com> wrote: >>>> >>>>> >>>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>>message >>>>>news:rdqlq5dv2u8bh308se0td53rk7lqmv0bki(a)4ax.com... >>>>>> Make sure the addresses are completely independent of >>>>>> where the vector appears in memory. >>>>>> >>>>>> Given you have re-implemented std::vector (presumably >>>>>> as >>>>>> peter::vector) and you have done >>>>>> all the good engineering you claim, this shouldn't >>>>>> take >>>>>> very much time at all. Then you >>>>>> can use memory-mapped files, and share this massive >>>>>> footprint across multiple processes, >>>>>> so although you might have 1.5GB in each process, it >>>>>> is >>>>>> the SAME 1.5GB because every >>>>>> process SHARES that same data with every other >>>>>> process. >>>>>> >>>>>> Seriously, this is one of the exercises in my Systems >>>>>> Programming course; we do it >>>>>> Thursday afternoon. >>>>>> joe >>>>> >>>>>But all that this does is make page faults quicker >>>>>right? >>>>>Any page faults at can only degrade my performance. >>>> *** >>>> Denser than depleted uranium. Fewer page faults, >>>> quicker. >>>> For an essay, please explain >>>> in 500 words or less why I am right (it only requires >>>> THINKING about the problem) and why >>>> these page faults happen only ONCE even in a >>>> multiprocess >>>> usage! Compare to the ReadFile >>>> solution. Compare and contrast the two approaches. >>>> Talk >>>> about storage allocation >>>> bottlenecks. >>>> >>>> I'm sorry, but you keep missing the point. DId you >>>> think >>>> your approach has ZERO page >>>> faults? You even told us it doesn't! >>> >>>I was making a conservative estimate, actual measurement >>>indicated zero page faults after all data was loaded, even >>>after waiting 12 hours. >> *** >> And a memory-mapped file would not show the same >> performance? You know this HOW? >> **** >>> >>>> Why do you think a memory-mapped file is going to >>>> be different? Oh, I forgot, you don't WANT to >>>> understand >>>> how they work, or how paging >>>> works! >>> >>>Not if testing continues to show that paging is not >>>occurring. >> **** >> SCALABILITY! SCALABILITY! MAXIMIZE THROUGHPUT! MEET >> 500MS PERFORMANCE GOALS! >> SCALABILITY! >> > >If there are no page faults without a memory mapped file and >there are no page faults with a memory mapped file, then >exactly and precisely what is the specific incremental >benefit of a memory mapped file? (The performance and >memory usage would have to be the same in both cases). ***** Did you say there were no page faults? I thought you said there were 27,000 while the data is being loaded! And is it not screamingly obvious that if you have the same file mapped into 20 processes, that you did not take 27,000 page faults in EACH of them? Instead, you took a flurry of page faults when you mapped the file in and touched the pages, and thereafter there are no page faults in ANY process that is sharing that segment! ZERO! In contrast, in your single-thread multiple-process model, each process has to undergo 27,000 page faults as it starts up. Have I not repeatedly said "amortized over ALL processes"? **** > >I don't want a really quick way to load more data when >needed, because there is no possible way that this could be >nearly as fast as having the data already loaded. **** I have no idea why you thought I said anything like this. Instead, I gave you a ZERO-page-fault way to load the data into subsequent processes. Note also that the page faults might be what are called "soft" faults, that is, when the OS goes to look for the page, it discovers it is already in memory, and doesn't waste time bringing in another copy. So even if the page faults occur, they are very CHEAP page faults. **** > >> Your method does not scale; our suggestions give you >> scalability, maximize throughput, and >> probably makes it possible to meet your wonderful 500ms >> goal consistently. >> joe > >Yet you have consistently, time after time, again and again >never backed this up with reasoning. As soon as you back >this up with verifiably correct reasoning, thenn (then and >only then) will I agree. I absolutely and positively reject >dogma as a source of truth. **** Hmm.. "Verifiable correct reasoning"....how about ZERO PAGE FAULTS ARE BETTER THAN LOTS OF PAGE FAULTS? Doesn't that sound good? As to the rest of the reasoning, it is in the MSDN, which I have read, which I have told you that YOU should read, and I'm not going to retype it all from memory here. There is no "dogma" here. Just obvious conclusions anyone who bothered to understand the technology could arrive at, just from reading the documentation that is available! joe **** > >> >> **** >>> >>>> joe >>>> **** >>>> >>>> Joseph M. Newcomer [MVP] >>>> email: newcomer(a)flounder.com >>>> Web: http://www.flounder.com >>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 26 Mar 2010 16:14 Liviu wrote: > "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >> "Liviu" <lab2k1(a)gmail.c0m> wrote... >>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote... >>>> You're not going to get anything done because you don't have >>>> the capacity to do so. You haven't yet in what 2-3 years? >>> >>> "I filed a provisional patent last August" - Peter Olcott, 12/14/2001 >>> >>> (message #584 in thread of 881 at >>> http://groups.google.com/group/comp.lang.c++/msg/f8161ee71a584326?hl=en) >> This patent issued in 2005. The task that I am undertaking is very >> large. > > I am not even trying to argue that now. But you are talking _years_ in > the works, yet demonstrated deep confusion over elementary matters > and ignored most of the sound advice volunteered here. Then you say > "I do not have the time to learn inessential new things". Nothing > personal, of course, and don't know that you even realize it, but that > paints you somewhere between utterly arrogant and a complete kook. He doesn't realize it, thats the problem. He filed a frivolous less than $100 or so provisional patent in 2001. A one page application. It gives you one year to file the full patent. He was granted the patent in 2006. Yet STILL NO PRODUCT in 9 years. Thats a classic definition of a Patent Troll and he still behavior like one today. I doubt he will have it done in the next 10 when it expires but that shouldn't stop anyone from providing a web OCR service or using the technology today - hmmmmmmm, it doesn't :) Makes you wonder why he has no licensees, no VCs taken him up, no company using his product or services - he has absolute nothing. The patent was frivolous and all he did was waste his money. -- HLS
From: Hector Santos on 26 Mar 2010 16:29
BobF wrote: > Hector Santos wrote: >> Peter Olcott wrote: >> >>> The experts are telling me that my real-time process does not need to >>> be memory resident. >> >> Once again, you are lying to suit your needs. You really don't >> understand how the Intel chip and Preemptive and Protected Mode >> operating systems works which we explained over and over again, and >> even provided LINKS for your reading and verification. >> >> If I had to guess, the reason why you don't understand any of this is >> because you are clueless of the history of the INTEL chip starting >> with its Memory Segmentation Model to the introduction of Real Mode vs >> Protected Model hardware and operating systems, starting with DMPI. >> Start reading about the Intel Chip, Memory Segmentation, Protected >> Mode Operating Systems and then maybe, just maybe, but I extremely >> doubt it, you will get some inkling of whats going on. >> > > ... and then write everything in ASM since you will have defeated the > purpose of higher level languages!!!! B-) HA!, Yeah, Download MASM32 - at least it provides MANY examples - even GUI! -- HLS |