Board index » delphi » Re: Indy 10 SuperCore Results

Re: Indy 10 SuperCore Results


2003-10-18 08:41:59 PM
delphi234
Quote
Why, do you expect your users to abort transfers often? Although aborting
is important in general, it is not a common operation to perform. Besides,
the Abort() method is not the only way to terminate a transfer. Although
not as graceful, TIdFTP does have a separate KillDataChannel() method for
closing the data socket used for the transfer. In fact, Abort() calls
KillDataChannel() internally. The only different with calling Abort() and
KillDataChannel() is that Abort() sends an ""ABOR" command to the server
first (but does not wait for a reply), that is all.

It needs to be implemented correctly because:
a) ABORT is part of the FTP standard.
b) Some servers may rely on it to properly release resources.
 
 

Re: Indy 10 SuperCore Results

Have you looked at some of the other products out there?
Chilkatsoft has a free FTP componnent that might possibly work for you. Or,
you can go with another commercial product, say nSoftware's stuff.
www.chilkatsoft.com/
Charles
"AKZ" <XXXX@XXXXX.COM>writes
Quote
also i forgot to mention in my previous msg,

ftp.abort method is one of the main when working with the ftp protocol
i cant think if much usage of TIdFTP component in any commercial product
without using its abort method.
dont you think TIdFTP is uselles till they fix this bug?


 

Re: Indy 10 SuperCore Results

the problem is i developed about 80% of the project when i discovered this
problem
so if i turn to some other component that will mean 1 month extra work.
however, now i hope ftp comp in indy 10 will be ok as it should be realeased
soon as they talked on this forum, probably in a month.
till then i will try to cover situation when user needs to call abort. if
indy 10 ftp comp will cause same problems i will be forced to search for
replacement. i started with indy cause i thought these componets are best
and thats why borland choosed to chip indy with delphi.
 

Re: Indy 10 SuperCore Results

Here are a few thoughts
If it will take you a month to rework your code or wait a month, it seems
pretty even to me.
However, will INDY 10's FTP component be 100% compatible with your existing
code or will it require subtle changes in your code to make it work? How
long will it take to find those areas where changes are required.
How long has the IdFTP.Abort bug existed? How long are you willing to wait
for a fix? If there's a bug in INDY 10's FTP component, you will again have
to wait for somebody to fix it (or do it yourself). Sounds risky to me if
you are trying to bring a product to market in a short time frame.
If your budget allows for it, I would strongly recommend you look at
commercially supported and established products. If you want to stay in the
freeware class, I might suggest ICS. It seems to work pretty well (although
it is a non-blocking library) and comes with full source. nSoftware has a
good commercial, albiet expensive, alternative.
One trick I have found to work in the past when switching components that
aren't 100% compatible is to make an adapter class. This technique has
permitted me to swap out components (mostly crypto oriented) with almost
zero code changes. Of course, I have to create a new adapter for each new
toolkit. But, it isolates the changes to a single module and the work is
significantly less than natively retrofiting my code.
Charles
"AKZ" <XXXX@XXXXX.COM>writes
Quote
the problem is i developed about 80% of the project when i discovered this
problem
so if i turn to some other component that will mean 1 month extra work.

however, now i hope ftp comp in indy 10 will be ok as it should be
realeased
soon as they talked on this forum, probably in a month.
till then i will try to cover situation when user needs to call abort. if
indy 10 ftp comp will cause same problems i will be forced to search for
replacement. i started with indy cause i thought these componets are best
and thats why borland choosed to chip indy with delphi.


 

Re: Indy 10 SuperCore Results

Quote
i started with indy cause i thought these componets are best
and thats why borland choosed to chip indy with delphi.
My understanding is the Borland sought to replace the poorly functioning
NetMaster's code with a library that worked better, had an active, gung-ho
community, and didn't cost them anything to include. The fact that it is
Open Source is a happy coincidence and byproduct. They provide a forum
(this one) where people can communicate. that is one of their contributions
to the Open Source community. If you want priority support for INDY, you
still have to pay for it through companies that offer support plans.
And, while people may not agree with me, INDY is not the best library out
there...although people are trying hard to make it so. In time, they may
succeed. I have always spoken well about the ease of use of the client
libraries and not so well about the performance (especially of the server
suite). We have yet to see a version of INDY that the INDY team will allow
us to benchmark against other socket libraries and publicly announce the
results of those benchmarks. We keep hearing the mantra "It's BETA" or the
new them "It's PRELIMINARY".
The tendency has been to fix the majority of the bugs and make the software
90% of where it should be and then create a new version of INDY and, for
intents and purposes, abandon the earlier versions. The hope is that
somebody will go back and fix those bugs. How often does that really
happen? Most people want to stay on the cutting edge...so many issues
remain unresolved.
 

Re: Indy 10 SuperCore Results

"Charles Stack" <charles>wrote in news:3f915e8f$XXXX@XXXXX.COM:
Quote
If your budget allows for it, I would strongly recommend you look at
commercially supported and established products. If you want to stay in
Indy has commercial supoprt as well, including priority bug fixing.
www.atozed.com/indy/experts/
Is Indy useful to you? Send a postcard please!
www.hower.org/kudzu/indypost.html
ELKNews - Get your free copy at www.atozedsoftware.com
 

Re: Indy 10 SuperCore Results

"Charles Stack" <charles>wrote in news:3f9161e4$XXXX@XXXXX.COM:
Quote
the server suite). We have yet to see a version of INDY that the INDY
team will allow us to benchmark against other socket libraries and
Noone has ever stopped people from publishing benchmarks.
Quote
publicly announce the results of those benchmarks. We keep hearing the
mantra "It's BETA" or the new them "It's PRELIMINARY".
Quit taking things out of context. 10 is beta, and the tests I posted a few
days ago were preliminary. Thats very recent and not "now and then".
I really wonder if you see how your posts read to the general public.
Need extra help with an Indy problem?
www.atozed.com/indy/experts/support.html
ELKNews - Get your free copy at www.atozedsoftware.com
 

Re: Indy 10 SuperCore Results

Okay. So, I assume that by your previous post (as noted below), that INDY 9
is officially out of BETA and we can run benchmarks against it and you won't
make a fuss when we publish the results, good or bad?
Which version, in particular, do you consider not in BETA so there is no
confusion regarding the validity of the results.
When can we expect to be allowed to run PRELIMINARY benchmarks against INDY
10's TIdTCPSocket (or equivalent) and a TIdTCPServer (or equivalent)?
Quite frankly, Chad, I don't give a damn how you think my posts read in
public. I say what I feel is pertinent. I don't do the INDY mantra or bow
down to you nor to I pray to the Kudzu Idol. I do, however, think you are a
talented programmer. And, I am also critical of your demeanor and the way
you do things. Sorry if you don't like my opinions.
I think INDY has great promise. But, it needs to be stabilized and people
need to know they can count on it working as expected. Rather than moving
on to INDY 10, INDY 9 should have been stabilized and optimized as you said
it would. It needed a larger support team of dedicated people willing to
work on INDY 9 rather than INDY 10. People need to know that bugs will be
fixed in a timely manner so that if they are using INDY X in a commercial
product, they can rest easy. And, they need to know the team that is
working on it stands behind it and willing to stand up to critical analysis
and benchmarks even if they might not go their way and learn from the
experience. Hell, this same criteria should apply to all commercial vendors
as well. You have yet to demonstrate these criteria in my eyes.
I don't publish my work nor run open source projects because of an IP
agreement between me and my employer. It isn't that my work could not be or
is not suitable to be published. So, don't go even begin to go there.
"Chad Z. Hower aka Kudzu" <XXXX@XXXXX.COM>writes
Quote
"Charles Stack" <charles>wrote in news:3f9161e4$XXXX@XXXXX.COM:
>the server suite). We have yet to see a version of INDY that the INDY
>team will allow us to benchmark against other socket libraries and

Noone has ever stopped people from publishing benchmarks.

>publicly announce the results of those benchmarks. We keep hearing the
>mantra "It's BETA" or the new them "It's PRELIMINARY".

Quit taking things out of context. 10 is beta, and the tests I posted a
few
days ago were preliminary. Thats very recent and not "now and then".

I really wonder if you see how your posts read to the general public.


--
Chad Z. Hower (a.k.a. Kudzu) - www.hower.org/Kudzu/
"Programming is an art form that fights back"

Need extra help with an Indy problem?

www.atozed.com/indy/experts/support.html


ELKNews - Get your free copy at www.atozedsoftware.com

 

Re: Indy 10 SuperCore Results

"Charles Stack" <charles>wrote in news:XXXX@XXXXX.COM:
Quote
Okay. So, I assume that by your previous post (as noted below), that
INDY 9 is officially out of BETA and we can run benchmarks against it
and you won't make a fuss when we publish the results, good or bad?
Indy 9 isnt beta and hasnt been for a long time. The contention with "your
benchmarks" is that several of them posted were totally useless and taken
out of context not only for Indy but for others.
The other issue is that many of them are totally useless. I have seen you
mention "can connect 40,000 sockets" or something like that. Sure its good
marketing and "fluff" but its totally usless. Anyone who knows how Windows
allocates sockets knows that non paged ram will be totally full, and that
the machine will be totally useless for ANYTHING other than saying "look we
connected the sockets" while leaving out that they are helpless to do
anything. Its like saying "look this car has room for 50 people!" while not
saying that you packed 50 babies in it and they all died from suffocation.
No matter what you do - no Windows box will handle more than about 10,000
sockets well. You can push it higher but the higher it goes the much more
restricted it becomes. Which I am sure you know but for those that want to
read about it read "The C10K Problem" and then go on to read MSDN about
socket limits an non paged RAM.
At 10,000 or even a bit higher, maybe 20,000 even on XP (or maybe 2K) you
could implement very limited low traffic server maybe such as SMS or IM.
But the machine would not be able to do much else.
Then there are the issues of bandwidth. I remember several claims that are
in Google if anyone is interested posted either by you (or more likely your
friend) that were totally impossible. There were claims of bandwidth that
exceeded even the capacity of a Gigabit Ethernet card.
But lets go back to bandwidth. Very very few people are writing servers
that will fully load a gigabit ethernet. Such in most cases is totally
useless anyways.
I have a 1 gigabit connection to the Internet. Yes really. So I can
actually do a lot of testing many people cannot. But very few companies
have anywhere near this.
But lets return to 100 MB, which is what most servers have for their
ethernet. Even Indy 9 can handle a fully loaded 100 MB ethernet without
straining in most cases. Yes there are cases that its not appropriate, like
high volume IM servers etc.. But in 95%+ of the cases its just fine. So if
it can handle a fully loaded 100 MB ethernet in 95% of the cases, what does
it really matter? Indy 10 is designed to handle more of that remaining 5%.
Its like the vacuum cleaner ads that say "4 amp motor!!!!!". When really in
the field of vacuum cleaners its a totally useless figure when used by
itself and used to sell to people who do not know better
Then there was the issue of "All tests done by independent party", when
really it was the company of a former partner.
Quote
When can we expect to be allowed to run PRELIMINARY benchmarks against
INDY 10's TIdTCPSocket (or equivalent) and a TIdTCPServer (or
equivalent)?
Anyone is free to run tests any time they want. But Indy 10 is not done,
and has quite a few areas that are totally unfinished or even just
"hacked" together right now. An no amount of goading or baiting will change
our development schedule.
But if anyone PUBLISHES such results they would be fair to mark that it was
tested against UNFINISHED BETA code. Thats not always been the case.
Quote
Quite frankly, Chad, I don't give a damn how you think my posts read in
public. I say what I feel is pertinent. I don't do the INDY mantra or
No, but you should care how everyone else reads them.
Quote
bow down to you nor to I pray to the Kudzu Idol. I do, however, think
you are a talented programmer. And, I am also critical of your
demeanor and the way you do things. Sorry if you don't like my
opinions.
Its nothing about Indy. Your friend loved to attack Indy, but at least he
was out front albeit more outrageous. But you come out and "hide" like you
are being partial. Over the years I couldnt determine if it was intentional
and you knew what you were doing, or not. But lately I have become quite
convinced that its intentional.
Quote
I think INDY has great promise. But, it needs to be stabilized and
people need to know they can count on it working as expected. Rather
Indy 10 is unfinished, we've never said otherwise.
Quote
than moving on to INDY 10, INDY 9 should have been stabilized and
optimized as you said it would. It needed a larger support team of
Indy 9 is stable. Indy 9 has more deployments than "your library" has
prospects.
Quote
need to know that bugs will be fixed in a timely manner so that if they
are using INDY X in a commercial product, they can rest easy. And, they
Indy 9 users can rest easy. As with all software it has bugs - but Indy 9
in general is very stable and used in hundreds of thousands of deployments.
Bugs are still being fixed, but non critical ones are yes being tabled.
This is standard practice in any software work.
Quote
go their way and learn from the experience. Hell, this same criteria
should apply to all commercial vendors as well. You have yet to
demonstrate these criteria in my eyes.
Useful benchmarks yes. Out of context useless ones no. You also seem to
totally miss the benchmark that Indy really meausures up - real world
successful use.
Quote
I don't publish my work nor run open source projects because of an IP
agreement between me and my employer. It isn't that my work could not
be or is not suitable to be published. So, don't go even begin to go
there.
Of course not. Its much easier to come here and start flame wars while not
having to do anything.
This is obvious when you repeatedly took my preliminary tests out of
context, although everyone else understood them. I clearly stated that
these were not "industrial" results, merely a "proof of concept" against
existing Indy code. It was nothing more other than a relative test to show
that Indy 10 Super Core uses about half the CPU to handle the same load.
However many of the benchmarks are quickly becoming totally useless again -
I've moved on to testing over the LAN, and both Indy 9 and 10 easily flood
the LAN to full capacity. So the only real benchmark left is CPU usage of
the server, memory usage, and soon.
Want to keep up to date with Indy?
Join Indy News - it free!
www.atozed.com/indy/news/
ELKNews - Get your free copy at www.atozedsoftware.com
 

Re: Indy 10 SuperCore Results

Some additional items I remembered:
1) When the benchmarks were published, no details of the testing methods of
use were posted.
2) Why is it your baiting is limited to Indy? I am not asking to you turn
on ICS, but why is it targetted at one library?
3) Google has these ones for anyone who is interested but I remember
statements like "Out performs IIS by a factor of 4" or something like this.
I held my tongue, but this is ludicrous. I have no doubt some special test
was set up that was a stacked benchmark and only useful for such. Something
along the lines of locking a page in memory and passing that locked page
(and constructing an HTML document to fit exactly in that page) and then
spamming IOCP ports with this locked page. Something totally useless in
real world, but great for stacked benchmarks. Also something not
representative of how IIS works or equal to its function.
Then I remember the HTTP test against Indy. Using our demo then saying "We
even used THEIR demo". While your test was optimized exactly for a
benchmark caching the content in memory etc... The Indy HTTP demo was
exactly that - a demo focusing on how to USE Indy, not optimized in anyway
or intended for a benchmark. In fact many parts of it were over simplified
because it was a demo, and designed for learning. So this was literally
stacking against Indy while claiming "neutrality" by claiming "Even used
their demo", the whole time knowing what results it would produce.
So it comes down to a few items:
1) You are not impartial and have a particular target at a specific
library, while claming to be the opposite.
2) The benchmarks you refer to have been both misleading, but useless in
many cases.
3) Many of the proposed tests you have proposed are useless in real world
situations except for a very small niche. There are other benchmarks you
totally ignore such as ease of use, feature set, and successful
deployments.
Any set of devised benchmarks should include all of those factors.
We will be publishing the benchmarks when they are done. I did not publish
the methods of the preliminary ones even though you chose to bait me, as
they were just that PRELIMINARY and not official or even "final". We will
publish the full suite for users to test themselves with documentation.
Got Indy? Got the book?
www.atozed.com/indy/book/
ELKNews - Get your free copy at www.atozedsoftware.com
 

Re: Indy 10 SuperCore Results

I'll deal with this post first.
"Chad Z. Hower aka Kudzu" <XXXX@XXXXX.COM>writes
Quote
Some additional items I remembered:

1) When the benchmarks were published, no details of the testing methods
of
use were posted.
Wrong. If you recall, I had actually set up a benchmark forum on yahoo.
Anyone who was interested could join. The goal was to create an unbiased
set of benchmarks with source code available for those benchmarks.
You and the INDY team fought me, publicly and privately, tooth and nail on
this. At the time, we were trying to run tests against INDY 9 and DxSock 3
in particular. Remember?
When Ozz ran his benchmarks for WWS, he stated he used Socrates. Do you
remember?
I eventually shut down the benchmarking group because the INDY team did not
care to participate and there seemed to be so little concern for performance
benchmarks among the Delphi users in this public forum.
Quote

2) Why is it your baiting is limited to Indy? I am not asking to you turn
on ICS, but why is it targetted at one library?
In almost all of my posts, I have said that benchmarks would be run against
other libraries including ICS. The difference is that ICS is non-blocking
and that would skew the results. And, I don't think we're permitted to
benchmark Delphi's sockets. BTW, Francois Piette WAS invited to join the
benchmark group. He declined...probably to avoid the public raucus when the
results were published. Smart man.
So, the choices are INDY, DxSOCK, Synapse for blocking and ICS for
non-blocking. If you know of other decent libraries out there...then they
could easily be included.
Quote
3) Google has these ones for anyone who is interested but I remember
statements like "Out performs IIS by a factor of 4" or something like
this.
I held my tongue, but this is ludicrous. I have no doubt some special test
was set up that was a stacked benchmark and only useful for such.
Something
along the lines of locking a page in memory and passing that locked page
(and constructing an HTML document to fit exactly in that page) and then
spamming IOCP ports with this locked page. Something totally useless in
real world, but great for stacked benchmarks. Also something not
representative of how IIS works or equal to its function.
Well, his benchmarks still show it. And, WWS does not use IOCP. I do
believe he loaded pages from into memory or generated them dynamically.
It's been so long ago, I don't recall what he said he did. But, he ran
those tests using Socrates. But, if you held your tongue, you did so only
because you were afraid his results were right and you could not counter.
Quote

Then I remember the HTTP test against Indy. Using our demo then saying "We
even used THEIR demo". While your test was optimized exactly for a
benchmark caching the content in memory etc... The Indy HTTP demo was
exactly that - a demo focusing on how to USE Indy, not optimized in anyway
or intended for a benchmark. In fact many parts of it were over simplified
because it was a demo, and designed for learning. So this was literally
stacking against Indy while claiming "neutrality" by claiming "Even used
their demo", the whole time knowing what results it would produce.

So it comes down to a few items:
1) You are not impartial and have a particular target at a specific
library, while claming to be the opposite.
Yes and no. I am (primarily) a DxSock user. I am an ICS user. I am a
Synapse user. And, on rare occassions, evan an INDY user. I generally
don't slam INDY or you until you get involved and you start ridiculing me or
my opinions publicly. Now, do I?
Quote

2) The benchmarks you refer to have been both misleading, but useless in
many cases.
You refused to participate. So, naturally, when the results are published,
you will state they are misleading or useless. it is just your way, Chad.
It's one of the reasons you and I don't get along any more.
Quote
3) Many of the proposed tests you have proposed are useless in real world
situations except for a very small niche. There are other benchmarks you
totally ignore such as ease of use, feature set, and successful
deployments.
Uh. No. If you recall, I have never been against INDY's ease of use or
even it is feature set. But, how do you exactly quantify that? Look back at
Google and you will see that I don't knock INDY's feature set or ease of use.
If anything, I have said good things about it. I have stated publicly many
times that I used DxSock for server development and, often, I used INDY for
client development. Take a look for yourself if you don't believe me.
But, if a feature doesn't perform exactly like it supposed to (i.e. the
latest being TIdFTP.Abort), how do you score that one? INDY is both a
client and server library. DxSock has been designed from the ground up to
be a server library. I can only compare the socket layer or the server
implementations given this. Right?
I can measure things such as memory ,network load,resource utilization,
latency, and throughput. The other items are subjective, are they not?
And, while I agree they would weigh in on a full product evaluation, they
are subjective. But, I am not doing, nor have a proposed, a full product
evaluation. I want to benchmark the underlying technology.
If you want to go into number of deployed sites...then one has to realize
that:
a) INDY is free
b) DxSock is commercial.
c) INDY was shipped with Delphi, DxSock was not.
d) INDY meets many peoples needs and, as such, they don't feel the need to
purchase another library.
In countries where the per capita income is significantly less that here in
the good ol' US of A, forking over $299 US (or more for the old DxSock
pricing) is usually not an option. Is it? Delphi is very popular overseas.
Borland has adjusted their pricing to those economies. The little guys don't
have the option to adjust their pricing quite as much for other currencies .
Who do you think we can hire offshore programmer's at a fraction of the cost
for an equivalently trained US worker? Why do you think so many companies
in the US have done just that?
Well, that is all another argument that isn't appropriate here. But, it
explains the wider dissemination of INDY, doesn't it.
Quote
Any set of devised benchmarks should include all of those factors.

We will be publishing the benchmarks when they are done. I did not publish
the methods of the preliminary ones even though you chose to bait me, as
they were just that PRELIMINARY and not official or even "final". We will
publish the full suite for users to test themselves with documentation.
If you recall, I only asked that you run these tests on real world hardware
and publish those results in conjuction with your local host results.
That's what lead us here.
If you want to call that "baiting", then yes, I guess I baited you.
 

Re: Indy 10 SuperCore Results

Im done replying to you Charles. Ive said what I wanted for nearly two years
to say. I held my tongue because I thought you were not being "intentional".
But that obviously was wishful thinking.
Your own statements and actions speak to this group by themselves - they dont
need any replies or clarifications from me.
Want more Indy stuff? Try the Atozed Indy Portal at
www.atozedsoftware.com/
* More Free Demos
* Free Articles
* Extra Support
ELKNews - Get your free copy at www.atozedsoftware.com
 

Re: Indy 10 SuperCore Results

"Charles Stack" <charles>wrote in news:3f9298a9$XXXX@XXXXX.COM:
Quote
You and the INDY team fought me, publicly and privately, tooth and nail
on this. At the time, we were trying to run tests against INDY 9 and
This is yet another "interesting" and "unique" interpretation of the events.
A lot like the rest of your message.
Need extra help with an Indy problem?
www.atozed.com/indy/experts/support.html
ELKNews - Get your free copy at www.atozedsoftware.com
 

Re: Indy 10 SuperCore Results

Okay, now, I will get to this one.
"Chad Z. Hower aka Kudzu" <XXXX@XXXXX.COM>writes
Quote
Indy 9 isnt beta and hasnt been for a long time. The contention with "your
benchmarks" is that several of them posted were totally useless and taken
out of context not only for Indy but for others.
Great. I will let Ozz know that he can run his benchmarkes of DxSock Oblivion
to INDY 9 and you won't complain provided we don't optimize our code and
pretty much do things stock.
Quote
The other issue is that many of them are totally useless. I have seen you
mention "can connect 40,000 sockets" or something like that. Sure its good
marketing and "fluff" but its totally usless. Anyone who knows how Windows
allocates sockets knows that non paged ram will be totally full, and that
the machine will be totally useless for ANYTHING other than saying "look
we
connected the sockets" while leaving out that they are helpless to do
anything. Its like saying "look this car has room for 50 people!" while
not
saying that you packed 50 babies in it and they all died from suffocation.
I'll let you address that to Ozz. He has customers who are doing just this.
But, no dead babies.
Quote
No matter what you do - no Windows box will handle more than about 10,000
sockets well. You can push it higher but the higher it goes the much more
restricted it becomes. Which I am sure you know but for those that want to
read about it read "The C10K Problem" and then go on to read MSDN about
socket limits an non paged RAM.
MSDN publishes things that are the accepted Microsoft way. There are ways
up performance and memory utilization. For example, you can alter how
memory is allocated. Why do you think there are different memory managers
available. The one supplied with Borland products works...but is optimized
for multi-thread or multi-processor designs.
.
Quote
Then there are the issues of bandwidth. I remember several claims that are
in Google if anyone is interested posted either by you (or more likely
your
friend) that were totally impossible. There were claims of bandwidth that
exceeded even the capacity of a Gigabit Ethernet card.
Ha! That was when he was benchmarking against the loopback interface.
He caught his error and was quite embarrassed by it. He then published his
numbers using real hardware. Quite different numbers.
Quote
But lets go back to bandwidth. Very very few people are writing servers
that will fully load a gigabit ethernet. Such in most cases is totally
useless anyways.
True. But, if you can saturate the line and still respond well over time,
then you should easily be able to handle lower, more down to earth loads
more effieciently.
Quote
I have a 1 gigabit connection to the Internet. Yes really. So I can
actually do a lot of testing many people cannot. But very few companies
have anywhere near this.
That's cool.
Quote
But lets return to 100 MB, which is what most servers have for their
ethernet. Even Indy 9 can handle a fully loaded 100 MB ethernet without
straining in most cases. Yes there are cases that its not appropriate,
like
high volume IM servers etc.. But in 95%+ of the cases its just fine. So if
it can handle a fully loaded 100 MB ethernet in 95% of the cases, what
does
it really matter? Indy 10 is designed to handle more of that remaining 5%.
I look forward to seeing this.
Quote
Then there was the issue of "All tests done by independent party", when
really it was the company of a former partner.
What, are you implying that because I used to be on the INDY Core/ Mercury
teams and then left and now use DxSock that I am impartial?
I may be biased on certain issues. But, I can not argue with real, meaningful
performance numbers that provide honest comparison. Can I?
In my line of work, I have to use what works. For me, that is DxSock.
Quote
Anyone is free to run tests any time they want. But Indy 10 is not done,
and has quite a few areas that are totally unfinished or even just
"hacked" together right now. An no amount of goading or baiting will
change
our development schedule.
I just don't want to try benchmarking on code that, is as you say, "hacked".
Even your disclaimers warn it might not even compile. Certainly, no one
would take benchmarks against such code seriously anyway. I wouldn't.
Quote
But if anyone PUBLISHES such results they would be fair to mark that it
was
tested against UNFINISHED BETA code. Thats not always been the case.

>Quite frankly, Chad, I don't give a damn how you think my posts read in
>public. I say what I feel is pertinent. I don't do the INDY mantra or

No, but you should care how everyone else reads them.
Why? You try to make assertions that I am generating smoke and mirrors. I
say you do. Eventually, when people see the numbers, they will realize that
I am not the one misleading them. They just need to demand to see those
numbers so they can make the call themselves.
Quote
Its nothing about Indy. Your friend loved to attack Indy, but at least he
was out front albeit more outrageous. But you come out and "hide" like you
are being partial. Over the years I couldnt determine if it was
intentional
and you knew what you were doing, or not. But lately I have become quite
convinced that its intentional.
I am impartial about my claims with regards to DxSock vs INDY. I am not
impartial when I deal with you. I have my issues with my "friend" as well.
But, I still stand by my technical assertions until somebody proves me
wrong.
Quote
Indy 10 is unfinished, we've never said otherwise.
INDY 9 is unfinished in my book. There are still significant bugs. The
upgrade process for those who have the Borland supplied version is
cumbersome. Why not start there? A simple install that removes all traces
of the Borland supplied INDY and replaces it with the most current one
correctly would be a bonus.
Quote
Indy 9 is stable. Indy 9 has more deployments than "your library" has
prospects.
I answered this in my other response. BTW, it is not "my library". It is
BrainPatchwork DX's library. I just use it.
Quote
Indy 9 users can rest easy. As with all software it has bugs - but Indy 9
in general is very stable and used in hundreds of thousands of
deployments.
Bugs are still being fixed, but non critical ones are yes being tabled.
This is standard practice in any software work.
Who is doing that work? Is there a timeline to fix the outstanding bugs on
the books? Or, is there a list of bugs that have been marked as not going
to be fixed as INDY 10 is underway? Such a list might help people like that
poor fellow expecting the TIdFTP.Abort bug to be fixed in a timely manner.
Quote
Useful benchmarks yes. Out of context useless ones no. You also seem to
totally miss the benchmark that Indy really meausures up - real world
successful use.
I answered this in my other post as well. it is like saying Betamaxx vs VHS.
We all know Betamaxx was the clearly superior technology. But, VHS won out
because of marketing power, lower cost, and smaller cartridges.
Quote

>I don't publish my work nor run open source projects because of an IP
>agreement between me and my employer. It isn't that my work could not
>be or is not suitable to be published. So, don't go even begin to go
>there.

Of course not. Its much easier to come here and start flame wars while not
having to do anything.
Hey. it is more fun. I like pissing you off. Thought you'd figure that one
out. :-)
Seriously, this wasn't supposed to be or about a flame war. You could have
nipped it in the bud some time ago by providing the numbers I said would be
more meaningful. Right? Why didn't you?
I have offered suggestions on how to make your results more meaningful
without violating my IP agreement with my employer.
You've got about a week before BORCON. Why not generate some benchmarks on
real world hardware and announce them here and at the conference. I wish I
could be there to ask you these things in public. But, I have job
responsibilies with regards to a new product roll out begining November and
running through February (at least). Yes, I am bummed. I am going to miss a
great party.
Quote

This is obvious when you repeatedly took my preliminary tests out of
context, although everyone else understood them. I clearly stated that
these were not "industrial" results, merely a "proof of concept" against
existing Indy code. It was nothing more other than a relative test to show
that Indy 10 Super Core uses about half the CPU to handle the same load.
And, I said that it is an essentially meaninglesss test. Do it on real
hardware and publish those relative numbers. Why is this apparently so
hard to do?
Or, the bigger question is "Why do you refuse to do so?"
 

Re: Indy 10 SuperCore Results

Quote
MSDN publishes things that are the accepted Microsoft way. There are
ways up performance and memory utilization. For example, you can alter
how memory is allocated. Why do you think there are different memory
managers available. The one supplied with Borland products works...but
is optimized for multi-thread or multi-processor designs.
It has nothing to do with allocation. Eitehr you are just dont know what the
limit are, or are speaking off the top of your head.
The MS way IS the windows way - and there are severe and unalterable limits
regarding non paged RAM.
Want to keep up to date with Indy?
Join Indy News - it free!
www.atozed.com/indy/news/
ELKNews - Get your free copy at www.atozedsoftware.com