What is the fastest sustainable web service response time?
in [MFC]
|
From: r norman on 23 Feb 2010 22:39 On Tue, 23 Feb 2010 20:22:23 -0600, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >news:ebU9CPMtKHA.3408(a)TK2MSFTNGP06.phx.gbl... >> Peter Olcott wrote: >> >>> Is it possible for a very fast web service to >>> consistently provide an average 500 millisecond response >>> time? >>> >>> Is the internet itself too slow making this goal >>> completely infeasible using current technology? >> >> >> What response time you mean, total or initial contact? > >Total response time must at least average < 500 ms for the >specific application that I have in mind. It looks like with >only two packets of input and one packet of output this >might be feasible for US customers with servers also in the >US. > >> >> When you talk of an application like a web service >> (presumably TCP based), I don't think you can guarantee >> any consistency for response time. However, it is >> reasonable to use an service-defined initial contact >> response time before considering it as a timeout. >> >> This might be defined by whether your client is a sync or >> async, In general, 25-35 seconds is the default timeout >> for a socket. When async, you have better control of the >> initial contact. >> >> You also didn't mention if there is size involvement in >> the timing. >> >> In principle, it isn't that the internet is slow, but >> there are many factors that can make it unreliable. But >> there is throttling that can be done too by the network >> provider. >> >> Reading your other input, at best, all you can do is set a >> limit perhaps on the initial contact time, if that >> concerns you. There is no way you would be able to get a >> persistent and consistent response time you are looking >> for. 500ms should be reasonable for the data size you are >> talking about. But how it is used is to define a timeout >> only. You can't control that a RTT (Round Trip Time) will >> be 500ms. Too many factors between end points. >> You are forgetting that I connect through a dial-up modem at 1200 baud! A round trip time of 500 ms is not reasonable for all users.
From: Hector Santos on 23 Feb 2010 22:42 Peter Olcott wrote: > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:OUGJ$UMtKHA.5976(a)TK2MSFTNGP05.phx.gbl... >> Peter Olcott wrote: >> >>> I have made major enhancements to my technology and am >>> considering trade secret rather than patent protection, >>> thus I am trying to test the feasibility of selling my >>> technology as a web service that performs with the >>> response time in the ball park of locally installed >>> software. >> >> Come on. I'm sure you haven't invented anything novel that >> hasn't been in place for 30+ years. Do you honestly think >> you are the first with fast internet transaction needs. >> Come on Peter. >> > > My technology is the only technology in the world that can > consistently recognize character glyphs at 96 DPI screen > resolutions with 100% accuracy. I already have a patent on > this. Well, the devil is in the details. Whats your patent #? Does it cover Europe and Asia? OCR technology have existed for decades and the accuracy depends on many factors. My first company (OptiSoft) in the 80s focused on "electron file cabinets" called OptiFile and OCR was a big part of it. It was part of the ODSARS market (Optical Document Storage and Retrieval System). In my 2nd and current company, I termed "SFI" Speech Friendly Interfacing back in the product area where the #1 market was for the visual impaired. Our application was for the Offline Mail Market (Silver Xpress) with advanced SFI methods. There were some well known vendors in the actual character to speech hardware market, such as GW Micro (http://www.gwmicro.com) and their original "Vocal Eyes" hardware. Now its called Windows-Eyes. But overall, there are hundreds of the big boys in this market many with patents and I'm fairly sure that when dealing with simple character glyphs represents the simplest of solutions. Text based OCR is simple. I doubt you can get 100% accuracy when there a mesh or human scripting. At best, you have a "method" in application using preexisting methods where 100% accuracy might be possible but only because the data is deterministic in nature and fairly easy to predict. Again, the devil is in the details. In any case, personally, after the relaxation of patentability in 1996 and in in 2000, created many frivolous patents of simple, obvious ideas and re-issuing of old ideas claimed to be new. I think you should recognize the oddness of you talking about patents and "IP" protection here in open public technical forum areas while at the same time you are posting really novel questions anyone with Internet Programming 101 knowledge should know. A quick search shows you done this in the past with other related stuff. IMHO, it is really not professional for you to be doing this. The next time, you might not find might input for your questions or at the very least, not feed you any ideas that might make you THINK it is something you can take and incorporate into some frivolous patent. -- HLS
From: David Scambler on 23 Feb 2010 22:43 "Peter Olcott" added to spam list
From: Geoff on 23 Feb 2010 23:05 Searching US Patents Text Collection... Results of Search in US Patents Text Collection db for: "peter olcott": 0 patents. No patents have matched your query
From: Geoff on 23 Feb 2010 23:11
Correction: United States Patent 7,046,848 Olcott May 16, 2006 Method and system for recognizing machine generated character glyphs and icons in graphic images |