On Mon, Dec 12, 2005 at 11:07:08AM +0100, Raphael Marmier wrote:
: Danial Thom wrote:
: >
: >What do you think "my word" is? My only point was
: >that I use the usage level at which a machine
: >starts dropping packets to determine its point of
: >capacity. I don't see how I can be wrong about
: >a
Danial Thom wrote:
What do you think "my word" is? My only point was
that I use the usage level at which a machine
starts dropping packets to determine its point of
capacity. I don't see how I can be wrong about
anything, since its hard to argue against that
point. And what do you think Matt's p
I am terminating this thread on monday at noon. People have
till then to say their peace.
-Matt
--- Erik Wikström <[EMAIL PROTECTED]>
wrote:
> On 2005-12-11 15:47, Danial Thom wrote:
> > you are completely wrong on every point. A
> > computer is only deterministic if its running
> one
> > task. And if he doesn't understand the math
> of
> > the bus, then all of his conclusions will be
> > f
Why won't you answer any questions or provide
details of your ideas? I keep asking, but you
never actually say anything.
--- "Martin P. Hellwig" <[EMAIL PROTECTED]>
wrote:
> Danial Thom wrote:
>
> > Are you related to Edgar Allan Poe by some
> > chance?
> >
> > I'm not sure I know which "topic"
Danial Thom wrote:
Are you related to Edgar Allan Poe by some
chance?
I'm not sure I know which "topic" you're
referring to, since all you do is make vague
references to things that don't seem related to
anything. First you cited switch specs without an
example or what part of the spec made you
--- "Martin P. Hellwig" <[EMAIL PROTECTED]>
wrote:
> Danial Thom wrote:
> > --- "Martin P. Hellwig" <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> >>
> >> Okay so when your the expert on practical
> >> implementation, what do you
> >> make of the surfnet internet2 test results
> >> (they did actu
--- "Martin P. Hellwig" <[EMAIL PROTECTED]>
wrote:
>
> Okay so when your the expert on practical
> implementation, what do you
> make of the surfnet internet2 test results
> (they did actually test
> current "normal" hardware too) that prove your
> "practical" hypothesis
> wrong? Or do you j
Okay so when your the expert on practical implementation, what do you
make of the surfnet internet2 test results (they did actually test
current "normal" hardware too) that prove your "practical" hypothesis
wrong? Or do you just deny the results and continue on trolling?
--
mph
--- "Martin P. Hellwig" <[EMAIL PROTECTED]>
wrote:
>
> > What do you think the
> > switch is going to do with the traffic? Its
> going
> > to dump it.
>
> The only argument you gave is false, read the
> full specs of any modern
> switch (ie all 1Gb switches)
>
> --
> mph
If I relied on "sp
What do you think the
switch is going to do with the traffic? Its going
to dump it.
The only argument you gave is false, read the full specs of any modern
switch (ie all 1Gb switches)
--
mph
--- Erik Wikström <[EMAIL PROTECTED]>
wrote:
> On 2005-12-02 19:16, Danial Thom wrote:
> > All of the empirical evidence points to Matt
> > being wrong. If you still can't accept that
> then
> > DFLY is more of a religion than a project,
> which
> > is damn shame.
> >
> > DT
>
> Since I don't
Perhaps I have a stake in one of the "beta
quality OSes" (FreeBSD 5.x+, Dragonfly, etc)
actually becoming useful? Its very frustrating to
see a strong solid OS with a strong management
team fragment into a bunch of mini-teams, none of
which have a wide-enough range of expertise to be
ultimately suc
> I wonder why it is that important 'who' Danial Thom is, or even
> whoMatthew Dillon is, in this kind of discussion.
[...]
> it shouldn't be important, and there is a simple solution to this problem...
[...]
It's important only in this particular discussion, especially when
one party has thus fa
Vinicius Santos wrote:
> I wonder why it is that important 'who' Danial Thom is, or even whoMatthew
> Dillon is, in this kind of discussion. I thought that theory,reasoning and
> results were what mattered and that the rest was justdecorative fallacy, wich
> might be annoying when it's in the fi
[EMAIL PROTECTED] wrote:
> Hiten Pandya wrote:
[snip]
>> Kind regards,
>>
>
> May i second you Hiten. The DragonFly lists are particularly interesting
> and you always learn things here. Personnally i don't know anything on the
> subject of this thread and i have enjoyed observing and trying to
On 12/3/05, Dennis Melentyev <[EMAIL PROTECTED]> wrote:> Guys'n'girls,> Just
Google for "Danial Thom". All I found are messages on *BSD> forums/lists with
the same proofless and abusing words. M.b. he know> something about the
subject, but definitely unable to talk about that.> PS. I'm just abou
Guys'n'girls,
Just Google for "Danial Thom". All I found are messages on *BSD
forums/lists with the same proofless and abusing words. M.b. he know
something about the subject, but definitely unable to talk about that.
PS. I'm just about to mark him twit.
2005/12/3, [EMAIL PROTECTED] <[EMAIL PROTEC
Hiten Pandya wrote:
> You obviously did not research on who Matthew Dillon is, otherwise you
> would know that he has plenty of real world experience. The guy wrote
> a packet rate controller inspired by basic laws of physics, give him
> credit instead of being rude.
>
> Time will tell whether h
Danial Thom wrote:
I, on the other hand, have made millions of $$
designing and selling network equipment based on
unix-like OSes, so I'm not only qualified to
What company? Your name doesn't ring a bell to me.
--
mph
Dude, if you have made and are making millions of benjamins, I don't
a person in his right mind would be spending his time arguing Gig-E
performance speeds on a mailing list for a beta-quality OS. :-)
If I was a person that made millions, I would definitely be planning
on buying an AMG convertibl
On 2005-12-02 19:16, Danial Thom wrote:
All of the empirical evidence points to Matt
being wrong. If you still can't accept that then
DFLY is more of a religion than a project, which
is damn shame.
DT
Since I don't know anything about networking at GigE-speed I find this
whole diskussion very
:All of the empirical evidence points to Matt
:being wrong. If you still can't accept that then
:DFLY is more of a religion than a project, which
:is damn shame.
:
:DT
Well, again, all I can say is that if 'all of the empirical evidence'
points to me being wrong, I welcome actually *hearin
--- Hiten Pandya <[EMAIL PROTECTED]> wrote:
> You obviously did not research on who Matthew
> Dillon is, otherwise you
> would know that he has plenty of real world
> experience. The guy wrote
> a packet rate controller inspired by basic laws
> of physics, give him
> credit instead of being rude
Danial Thom wrote:
you also
obviously have no practical experience with
heavily utilized network devices, because you
seem to have no grasp on the real issues.
you sound like a teenager telling his mum she has no experience in life
and she can't "get it"...
Matt, I really appreciate your wa
--- Matthew Dillon <[EMAIL PROTECTED]>
wrote:
> Well, if you think they're so provably
> wrong you are welcome to
> put forth an actual technical argument to
> disprove them, rather then
> throw out derogatory comments which contain
> no data value whatsoever.
> I've done my bes
At 6:48 PM -0800 12/1/05, Danial Thom wrote:
--- Matthew Dillon <[EMAIL PROTECTED]>
wrote:
> : [various observations based on years of
> : real-world experience, as anyone could
> : find out via a competent google search]
..., and you also obviously have no practical
experience with heav
You obviously did not research on who Matthew Dillon is, otherwise you
would know that he has plenty of real world experience. The guy wrote
a packet rate controller inspired by basic laws of physics, give him
credit instead of being rude.
Time will tell whether he was wrong about his arguments
Matthew Dillon wrote:
Well, if you think they're so provably wrong you are welcome to
put forth an actual technical argument to disprove them, rather then
throw out derogatory comments which contain no data value whatsoever.
I've done my best to explain the technical issues to y
> You obviously have forgotten the original premise
> of this (which is how do we get past the "wall"
> of UP networking performance), and you also
> obviously have no practical experience with
> heavily utilized network devices, because you
> seem to have no grasp on the real issues.
Why don't
Well, if you think they're so provably wrong you are welcome to
put forth an actual technical argument to disprove them, rather then
throw out derogatory comments which contain no data value whatsoever.
I've done my best to explain the technical issues to you, but frankly
you h
--- Matthew Dillon <[EMAIL PROTECTED]>
wrote:
> :...
> :wall a lot sooner with MP than with UP,
> because
> :you have to get back to the ring, no matter
> what
> :the intervals are, before they wrap. As you
> :increase the intervals (and thus decrease the
> :ints/second) you'll lose even more pa
--- Marko Zec <[EMAIL PROTECTED]> wrote:
> On Thursday 01 December 2005 22:19, Danial Thom
> wrote:
> > I see you haven't done much empirical
> testing;
> > the assumption that "all is well because
> intel
> > has it all figured out" is not a sound one.
> > Interrupt moderation is given but at s
On Thursday 01 December 2005 23:13, Matthew Dillon wrote:
> :...
> :
> :> of latency occuring every once in a while would not have any
> :> adverse effect.
> :
> :A few milliseconds of latency / jitter can sometimes completely kill
> : TCP throughput at gigabit speeds. A few microseconds won't mat
:...
:> of latency occuring every once in a while would not have any adverse
:> effect.
:
:A few milliseconds of latency / jitter can sometimes completely kill TCP
:throughput at gigabit speeds. A few microseconds won't matter, though.
:
:Cheers,
:
:Marko
Not any more, not with scaled TCP w
On Thursday 01 December 2005 22:19, Danial Thom wrote:
> I see you haven't done much empirical testing;
> the assumption that "all is well because intel
> has it all figured out" is not a sound one.
> Interrupt moderation is given but at some point
> you hit a wall, and my point is that you hit a
>
:But, and this is where you are misinterpreting the features, the problem
:is that there is ANY latency, it is simply that there is too MUCH latency
Er, I meant 'is NOT that there is ANY latency, ...'.
-Matt
:...
:wall a lot sooner with MP than with UP, because
:you have to get back to the ring, no matter what
:the intervals are, before they wrap. As you
:increase the intervals (and thus decrease the
:ints/second) you'll lose even more packets,
:because there is less space in the ring when the
:interru
On Thursday 01 December 2005 15:27, Danial Thom wrote:
> The issue is that RX is absolute, as you cannot
> "decide" to delay or selectively drop since you
> don't know whats coming. Better to have some
> latency than dropped packets.
No, if the system can't cope with the inbound traffic, it's much
On Thursday 01 December 2005 18:15, Matthew Dillon wrote:
> I don't know what the issue you bring up with the Linux kernels
> is, but at GigE speeds the ethernet hardware is actually
> flow-controlled. There should not be any packet loss even if the cpu
> cannot keep up with a full-bandwidth pa
--- Matthew Dillon <[EMAIL PROTECTED]>
wrote:
> :The issue is that RX is absolute, as you
> cannot
> :"decide" to delay or selectively drop since
> you
> :don't know whats coming. Better to have some
> :latency than dropped packets. But if you don't
> :dedicate to RX, then you have an unknown
>
:The issue is that RX is absolute, as you cannot
:"decide" to delay or selectively drop since you
:don't know whats coming. Better to have some
:latency than dropped packets. But if you don't
:dedicate to RX, then you have an unknown amount
:of cpu resources doing "other stuff". The
:capacity issue
--- Marko Zec <[EMAIL PROTECTED]> wrote:
> On Wednesday 30 November 2005 16:18, Danial
> Thom wrote:
> > --- Hiten Pandya <[EMAIL PROTECTED]> wrote:
> > > Marko Zec wrote:
> > > > Should we be really that pessimistic
> about
> > > > potential MP performance,
> > > > even with two NICs only? Typ
Alfredo Beaumont Sainz wrote:
And what about using CPUs to both RX and TX? That is, bound a packet to a
CPU to both RX and TX?
Cheers
I am not sure about binding packets to CPUs, but binding by protocol
families would be quite nice I think. Starting by binding specific
IRQs to certain set of
Marko Zec wrote:
> On Wednesday 30 November 2005 16:18, Danial Thom wrote:
>> --- Hiten Pandya <[EMAIL PROTECTED]> wrote:
>> > Marko Zec wrote:
>> > > Should we be really that pessimistic about
>> > > potential MP performance,
>> > > even with two NICs only? Typically packet
>> > > flows are bi-d
On Wednesday 30 November 2005 03:08, Hiten Pandya wrote:
> Marko Zec wrote:
> > Should we be really that pessimistic about potential MP
> > performance, even with two NICs only? Typically packet flows are
> > bi-directional, and if we could have one CPU/core taking care of
> > one direction, then
On Wednesday 30 November 2005 16:18, Danial Thom wrote:
> --- Hiten Pandya <[EMAIL PROTECTED]> wrote:
> > Marko Zec wrote:
> > > Should we be really that pessimistic about
> > > potential MP performance,
> > > even with two NICs only? Typically packet
> > > flows are bi-directional,
> > > and if w
--- Hiten Pandya <[EMAIL PROTECTED]> wrote:
> Marko Zec wrote:
> > Should we be really that pessimistic about
> potential MP performance,
> > even with two NICs only? Typically packet
> flows are bi-directional,
> > and if we could have one CPU/core taking care
> of one direction, then
> > t
--- Matthew Dillon <[EMAIL PROTECTED]>
wrote:
>
> :Should we be really that pessimistic about
> potential MP performance,
> :even with two NICs only? Typically packet
> flows are bi-directional,
> :and if we could have one CPU/core taking care
> of one direction, then
> :there should be at
Marko Zec wrote:
Should we be really that pessimistic about potential MP performance,
even with two NICs only? Typically packet flows are bi-directional,
and if we could have one CPU/core taking care of one direction, then
there should be at least some room for parallelism, especially once the
:Should we be really that pessimistic about potential MP performance,
:even with two NICs only? Typically packet flows are bi-directional,
:and if we could have one CPU/core taking care of one direction, then
:there should be at least some room for parallelism, especially once the
:paralleliz
On Monday 28 November 2005 22:13, Matthew Dillon wrote:
> If we are talking about maxing out a machine in the packet
> routing role, then there are two major issue sthat have to be
> considered:
>
> * Bus bandwidth. e.g. PCI, PCIX, PCIE, etc etc etc. A standard
> PCI bus is limited to ~12
If we are talking about maxing out a machine in the packet routing
role, then there are two major issue sthat have to be considered:
* Bus bandwidth. e.g. PCI, PCIX, PCIE, etc etc etc. A standard PCI
bus is limited to ~120 MBytes/sec, not enough for even a single GiGE
lin
--- Steve Shorter <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 28, 2005 at 10:15:55AM -0800,
> Matthew Dillon wrote:
> > :What kind of "benefits" would be realized
> for
> > :systems being used primary as a
> router/bridge,
> > :given that its almost 100% kernel usage?
> > :
> > :DT
> >
> > Rou
On Mon, Nov 28, 2005 at 10:15:55AM -0800, Matthew Dillon wrote:
> :What kind of "benefits" would be realized for
> :systems being used primary as a router/bridge,
> :given that its almost 100% kernel usage?
> :
> :DT
>
> Routing packets doesn't take much cpu unless you are running a gigabit
>
--- Matthew Dillon <[EMAIL PROTECTED]>
wrote:
> :What kind of "benefits" would be realized for
> :systems being used primary as a router/bridge,
> :given that its almost 100% kernel usage?
> :
> :DT
>
> Routing packets doesn't take much cpu
> unless you are running a gigabit
> of actual
:What kind of "benefits" would be realized for
:systems being used primary as a router/bridge,
:given that its almost 100% kernel usage?
:
:DT
Routing packets doesn't take much cpu unless you are running a gigabit
of actual bandwidth (or more). If you aren't doing anything else with
--- Matthew Dillon <[EMAIL PROTECTED]>
wrote:
>
> :It seems most of the banter for the past few
> :months is userland related. What is the state
> of
> :the kernel in terms of DP/MP kernel
> performance?
> :Has any work been done or is DFLY still in the
> :cleaning up stages? I'm still desparat
:It seems most of the banter for the past few
:months is userland related. What is the state of
:the kernel in terms of DP/MP kernel performance?
:Has any work been done or is DFLY still in the
:cleaning up stages? I'm still desparately seeking
:a good reason to move to Dual-core processors
:
:DT
It seems most of the banter for the past few
months is userland related. What is the state of
the kernel in terms of DP/MP kernel performance?
Has any work been done or is DFLY still in the
cleaning up stages? I'm still desparately seeking
a good reason to move to Dual-core processors
DT
60 matches
Mail list logo
