How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Hector Santos on 20 Mar 2010 11:58 Peter Olcott wrote: > All the posts that I am seeing and all the posts that I am > making are showing up on Google Groups > > http://groups.google.com/group/microsoft.public.vc.mfc/browse_thread/thread/f6146804be18f451/153bc7d9580b3741?hl=en&q=group%3Amicrosoft.public.vc.mfc&lnk=nl& Yes, and many of the post I make at news.microsoft.com, don't make it to google and visa-versa. I'll same the same for Joe's mail. -- HLS
From: Peter Olcott on 20 Mar 2010 12:10 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ON7ffXEyKHA.2012(a)TK2MSFTNGP04.phx.gbl... > Peter Olcott wrote: > >> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >> message news:%23gh1e5DyKHA.5292(a)TK2MSFTNGP06.phx.gbl... >>> Peter Olcott wrote: >>> >>>> Oh now I see where you are getting the 3.7 minutes >>>> from. The actual maximum time per user request is 1/10 >>>> second for a whole page of data. Requests larger than a >>>> page of data will be placed into a lower priority >>>> queue. The system recognizes 72,000 characters per >>>> second. My OCR does not need to change much, it just >>>> needs to get its requests from a FIFO queue. The >>>> webserver will have multiple threads to append to this >>>> queue. >>>> >>>>> You need to focus first on making sure you can scale >>>>> the OCR application. Making it thread ready and safe >>>>> is a first step. >>>> It does not need to be thread ready, it only needs to >>>> be able to read from a FIFO queue. >>> Ok, I'll try this again (I already posted the points >>> here but the mail was freaking lost), try it again in >>> simple terms: >>> >>> THINK TRANSACTION TIME! >>> >>> How what are your boundary conditions for a HTTP request >>> transaction time, both minimum and maximum? >>> >>> Based on what you said below: >>> >>> minimum: 100 ms per PAGE OF META DATA >>> maximum: DELAYED PROCESSING >>> >>> Look, you are touching base with all sorts of common >>> practice engineering design principles in this area. How >>> about this so you can cut down on mail-tagging thread? >>> >>> What is your functional specification, NOT TECHNICAL, >>> functional >>> specification of the OCR application? >>> >>> In short, you either have: >>> >>> - fast *semi-interactive* client/server framework >>> - delayed store and forward client/server framework >>> >>> This changes (or rather defines) all sorts of things. >>> This all goes back to my original input: >>> >>> You need to work out the OCR state machine protocol. >>> >>> From there, you can put together the solution you need. >>> I had a basic idea of what you needed from the >>> beginning, that is why I guided you to the CSPServer >>> class at codeproject.com >>> >>> But even then, you still need to make it all thread >>> ready and safe, regarding its interactive or store and >>> forward, or fifo, lifo, or what have you. >>> >>> In other words, but you can even begin to talk having a >>> party, you need to get the house ready for many guest. >>> >>> -- >>> HLS >> >> I did not fully understand much of the above. >> >> My OCR process has the following requirements: >> (1) Must be a single thread on a machine dedicated to OCR >> processing. > > > Why? I think you made a decision based on a poor > implementation of your software. See #5 I already explained this completely about five times now, if your newsreader is skipping some of my posts, then please go to Google Groups to see them. My process is memory bandwidth intensive, thus memory access speed is the bottleneck. Because of this multiple CPU can not help. Also I empirically validated this by running two instance of my process on a quad-code machine, each one took twice as long. > >> (2) Its data must remain resident in RAM > > > Same as #1 20,000 hours of development and design time along with rigorous empirical validation contradicts this. > >> (5) OCR processing time is less than 100 milliseconds. > > > This doesn't make sense. If a OCR process time is 100 ms, > which is pretty darn fast and SHORTEN then most http > applications then why can't you have multi-threads? <not yelling, emphasizing> MEMORY BANDWIDTH SPEED IS THE BOTTLENECK </not yelling, emphasizing> > > Again, I think that you have put unreasonable design > constraints mostly likely based on a poor understanding of > WINTEL and an implementation of your application on a > WINTEL boxed high powered with a QUAD, 8GB and an advanced > NT based OS. > > > -- > HLS
From: Peter Olcott on 20 Mar 2010 12:14 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:enDphYEyKHA.2012(a)TK2MSFTNGP04.phx.gbl... > Peter Olcott wrote: > >> All the posts that I am seeing and all the posts that I >> am making are showing up on Google Groups >> >> >> http://groups.google.com/group/microsoft.public.vc.mfc/browse_thread/thread/f6146804be18f451/153bc7d9580b3741?hl=en&q=group%3Amicrosoft.public.vc.mfc&lnk=nl& > > > Yes, and many of the post I make at news.microsoft.com, > don't make it to google and visa-versa. I'll same the > same for Joe's mail. > > > -- > HLS Maybe its time to switch newsreaders, I am using Outlook Express 6.0.
From: Hector Santos on 20 Mar 2010 12:17 Peter Olcott wrote: > I already explained this completely about five times now, if > your newsreader is skipping some of my posts, then please go > to Google Groups to see them. I am reading your post. > My process is memory bandwidth intensive, thus memory access > speed is the bottleneck. Thats because you implemented it wrong. > Also I empirically validated this by running two > instance of my process on a quad-code machine, each one took > twice as long. THIS PROVES YOUR IMPLEMENTATION IS INCORRECT. > 20,000 hours of development and design time along with > rigorous empirical validation contradicts this. Which explains you don't have anything yet, because you don't know what you are doing. > <not yelling, emphasizing> > MEMORY BANDWIDTH SPEED IS THE BOTTLENECK > </not yelling, emphasizing> <BIG> YOU DON'T KNOW WHAT YOU ARE DOING! </BIG> You don't have a freaking CRAY application need! Plus if you said your process time is 100ms is less, then YOU DON'T KNOW what you are talking about if you say you can't handle more than one thread. It means YOU PROGRAMMED YOUR SOFTWARE WRONG! -- HLS
From: Hector Santos on 20 Mar 2010 13:28
Hector Santos wrote: >> <not yelling, emphasizing> >> MEMORY BANDWIDTH SPEED IS THE BOTTLENECK >> </not yelling, emphasizing> > > <BIG> > YOU DON'T KNOW WHAT YOU ARE DOING! > </BIG> > > You don't have a freaking CRAY application need! Plus if you said your > process time is 100ms is less, then YOU DON'T KNOW what you are talking > about if you say you can't handle more than one thread. > > It means YOU PROGRAMMED YOUR SOFTWARE WRONG! Look, you can't take a single thread process that demands 4GB of meta processing and believe that this is optimized for a WINTEL QUAD machine to run as single thread process instances, and then use as a BASELINE for any other WEB-SERVICE design. Its foolish. You have to redesign your OCR software to make it thread-ready and use sharable data so that its only LOADED once and USED many times. If you have thousands of font glyph files, then you can use a memory mapped class array shared data. I will guarantee you that will allow you to run multiple threads. But if you insist it can only be a FIFO single thread processor, well, you are really wasting people time here because everything else you want to do contradicts your limitations. You want to put a web server INTO your OCR, when in reality, you need to put your OCR into your WEB SERVER. -- HLS |