|
On Sun, 14 May 2000, Joseph Mack wrote:
> On Sun, 14 May 2000, jamal wrote:
>
> > > In neither case is LVS limiting.
> >
> > Hmmm... Thats definetely an overstatement and misleading.
>
> what's the correct statement and what part is misleading?
>
The misleading statement is:
"In neither case is LVS limiting"
LVS hasnt reached the greatness level of sliced bread yet ;->
Lets try to have a rational thinking involved.
> > Overhead of the LVS code is definetly a contributor.
>
> how much and what are the units of definitely?
>
I have never done any measurements and to be honest never used LVS
although i have been on the list for quiet some time and looked at the
code about a year ago.
Using scientific reasoning, if you add more code you end needing more
cycles. I conclude from that LVS adds more overhead.
How much is the question ...
> Has anyone done
> > profiling on the LVS code?
>
> I have not been able to detect the added latency on network throughput
> using LVS VS-DR on a 100Mbps network when I could easily detect 0.3msec.
>
How do you detect the 0.3 ms latency? And under what sort of workloads
(traffic exercising the LVS code)?
> What are your results?
>
> > To store the tables for thousands of connections means using up relatively
> > more RAM.
>
> > So yes, LVS code has everything to do with it.
>
> you just used an example where memory is limiting to conclude that LVS
> is limiting
>
If we talk about limiting system resources then LVS is contributing to
their consumption in both memory and CPU. Making a blanket statement that
it doesnt is kind of ridiculous.
Since you have done some analysis, can you provide the following details:
- hardware resources used (CPU, m/board, RAM)
- throughput: in packets per second
- latenct/jitter under different workloads
- memory consumption with varying table sizes/workloads
I believe this is what the original posted was asking for.
cheers,
jamal
|
