From: Mikel on
On 26 mar, 15:32, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote:
> "Pete Delgado" <Peter.Delg...(a)NoSpam.com> wrote in message
>
> news:eSOGleKzKHA.264(a)TK2MSFTNGP05.phx.gbl...
>
>
>
>
>
>
>
> > "Liviu" <lab...(a)gmail.c0m> wrote in message
> >news:eUt13uGzKHA.5332(a)TK2MSFTNGP02.phx.gbl...
> >> "Pete Delgado" <Peter.Delg...(a)NoSpam.com> wrote...
>
> >>> I believe that your interpretation of "fault tolerance"
> >>> is that a
> >>> catastrophic event could happen to your system and you
> >>> application
> >>> would not lose *any* data. Is this the definition that
> >>> you are using?
>
> >> Absent any catastrophic events, a system might still be
> >> called
> >> "fault tolerant" if it managed at least one successful
> >> run under
> >> controlled conditions on developer's machine, despite all
> >> faults
> >> with its design and implementation ;-)
>
> > Given his level of understanding, I sincerely doubt that
> > his system can possibly overcome all of the faults that
> > you mention! ;-)
>
> > -Pete
>
> Since many of these require redundant hardware and my
> initial budget can not afford redundant hardware these other
> faults will not be initially accounted for. My understanding
> would be much better if people would explain their
> underlying reasoning.- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

This is a newsgroup, not a place to transcribe books and books on MFC,
Windows programming, OS, databases, TCP/IP protocol, etc.
It's not a place where people have to explain all their background,
and all their "been there, done that"s, either, though it's certainly
entertaining to read some of those stories.
If you ask the experts, trust the experts
From: Mikel on
On 26 mar, 15:38, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote:
> "Pete Delgado" <Peter.Delg...(a)NoSpam.com> wrote in message
>
> news:O6IcgkKzKHA.2644(a)TK2MSFTNGP04.phx.gbl...
>
>
>
>
>
> > "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote in message
> >news:9ZSdnc_zBLvdfzbWnZ2dnUVZ_qadnZ2d(a)giganews.com...
> >> But I have said many times now that I will not scale by
> >> processes I will scale by threads, and these threads all
> >> share that same data so the benefit that you keep pushing
> >> about memory mapped files continues to be moot. I may
> >> actually scale by servers instead of processes or
> >> threads, because five single core servers cost half as
> >> much as one quad core server.
>
> > The laughable part of all this is that you are completely
> > serious! So, given your obvious naivete about development
> > you now suggest that you can implement your system using
> > multiple servers all the while meeting or exceeding your
> > design and performance goals?
>
> > All I can say is good luck...
>
> > -Pete
>
> It is not naiveté. I know that the greater the physical
> proximity of a server to a customer the fewer the hops that
> the customer's request will make to this server. Is this not
> correct? If I geographically disperse the servers such that
> at least one server is in much closer physical proximity to
> a specific set of customers, then these customers will most
> likely enjoy faster response time, right?- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

I really don't remember much of what I learnt about TCP/IP in college,
but I certainly remember the parts about "you can't know how many hops
it will take a packet to reach point B from point A" and "each packet
can take a different route".
From: Mikel on
On 26 mar, 15:47, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote:
> "Hector Santos" <sant9...(a)nospam.gmail.com> wrote in message
>
> news:OYBobWLzKHA.5040(a)TK2MSFTNGP02.phx.gbl...
>
>
>
>
>
> > Peter Olcott wrote:
>
> >> You and Joe did give me some excellent help, and I really
> >> appreciate that. The idea to base my web application on
> >> HTTP was the best. I do not appreciate the rudeness, and
> >> denigration.
>
> > We don't appreciate you telling us to prove something that
> > is pretty much common knowledge about Windows programming,
> > and furthermore, we don't appreciate when you still don't
> > believe us and we advise you explore all yourself even to
> > he extent of providing simulation code and you still
> > hassle us about it without even exploring it. When you
> > finally did partially some testing,  you have kiddie BUGS
> > and still come back to us to help you figure it out.
>
> > Then you tried to front us with some fictitious Specialty
> > Group that has all the answers, and LIED about they were
> > agreeing with you. When asked to tell us what group was
> > this, silence.
>
> The group is comp.programming.threads
> along with two linux groups and one unix group.
>
> Outlook express is losing some of the postings. I had to
> reply to a reply to Pete's message yesterday because Pete's
> original message never made it to outlook express.
>
>
>
> > And even if you still didn't believe us, it isn't like the
> > world is void of this information.  This is all out there
> > in googleland and you were given countless links, all
> > ignored. But its all there, yet you still refuse to
> > believe anything.
>
> I know for a fact that belief and disbelief are both errors
> of reasoning known as fallacies. Only comprehension of
> reasoning is a reliable means of discerning truth from
> falsehood. I apologize for not showing enough deference for
> the excellent free advice that you are providing. The advice
> that I could verify with reasoning was verifiably superb.
>
>
>
>
>
> > And thing finally, in the end you finally said you did
> > know about something about all this, but forgot because
> > you never studied the 2nd half of some book for a canceled
> > exam on operating systems.  Talk about Virtual Memory!
>
> > Rude? Your behavior is nothing short of being rude.
>
> > --
> > HLS- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

You could also verify by testing, then try to learn and understand why
is it like that.
Besides, aren't "learn" and "comprehend" synonims (or near synonims)?
You've stated several times that you don't wish to (or don't have time
to) learn new things, so if you are given the pointers but don't even
try to learn from them, you either have to believe or stay ignorant,
but you can't say you didn't get the reasoning. You just ignored it.
From: Peter Olcott on

"Mikel" <mikel.luri(a)gmail.com> wrote in message
news:36cb8b85-0cf8-421c-94ce-dd1fd77c3f36(a)e7g2000yqf.googlegroups.com...
> On 26 mar, 15:32, "Peter Olcott" <NoS...(a)OCR4Screen.com>
> wrote:
>> "Pete Delgado" <Peter.Delg...(a)NoSpam.com> wrote in
>> message
>>
>> news:eSOGleKzKHA.264(a)TK2MSFTNGP05.phx.gbl...
>>
>>
>>
>>
>>
>>
>>
>> > "Liviu" <lab...(a)gmail.c0m> wrote in message
>> >news:eUt13uGzKHA.5332(a)TK2MSFTNGP02.phx.gbl...
>> >> "Pete Delgado" <Peter.Delg...(a)NoSpam.com> wrote...
>>
>> >>> I believe that your interpretation of "fault
>> >>> tolerance"
>> >>> is that a
>> >>> catastrophic event could happen to your system and
>> >>> you
>> >>> application
>> >>> would not lose *any* data. Is this the definition
>> >>> that
>> >>> you are using?
>>
>> >> Absent any catastrophic events, a system might still
>> >> be
>> >> called
>> >> "fault tolerant" if it managed at least one successful
>> >> run under
>> >> controlled conditions on developer's machine, despite
>> >> all
>> >> faults
>> >> with its design and implementation ;-)
>>
>> > Given his level of understanding, I sincerely doubt
>> > that
>> > his system can possibly overcome all of the faults that
>> > you mention! ;-)
>>
>> > -Pete
>>
>> Since many of these require redundant hardware and my
>> initial budget can not afford redundant hardware these
>> other
>> faults will not be initially accounted for. My
>> understanding
>> would be much better if people would explain their
>> underlying reasoning.- Ocultar texto de la cita -
>>
>> - Mostrar texto de la cita -
>
> This is a newsgroup, not a place to transcribe books and
> books on MFC,
> Windows programming, OS, databases, TCP/IP protocol, etc.
> It's not a place where people have to explain all their
> background,
> and all their "been there, done that"s, either, though
> it's certainly
> entertaining to read some of those stories.
> If you ask the experts, trust the experts

The experts are telling me that my real-time process does
not need to be memory resident.


From: Peter Olcott on
Yes, but, also the closer you are the higher the tendency
for fewer hops.

"Mikel" <mikel.luri(a)gmail.com> wrote in message
news:9ea9418c-056a-4d38-9235-c49e4a1bbf13(a)q21g2000yqm.googlegroups.com...
On 26 mar, 15:38, "Peter Olcott" <NoS...(a)OCR4Screen.com>
wrote:
> "Pete Delgado" <Peter.Delg...(a)NoSpam.com> wrote in message
> It is not naivet�. I know that the greater the physical
> proximity of a server to a customer the fewer the hops
> that
> the customer's request will make to this server. Is this
> not
> correct? If I geographically disperse the servers such
> that
> at least one server is in much closer physical proximity
> to
> a specific set of customers, then these customers will
> most
> likely enjoy faster response time, right?- Ocultar texto
> de la cita -
>
> - Mostrar texto de la cita -

I really don't remember much of what I learnt about TCP/IP
in college,
but I certainly remember the parts about "you can't know how
many hops
it will take a packet to reach point B from point A" and
"each packet
can take a different route".