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
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
:
--- Martin P. Hellwig [EMAIL PROTECTED]
wrote:
Danial Thom wrote:
--- Martin P. Hellwig [EMAIL PROTECTED]
wrote:
cut all
Okay so when your the expert on practical
implementation, what do you
make of the surfnet internet2 test results
(they did actually test
current
Danial Thom wrote:
cut
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
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:
cut
Are you related to Edgar Allan Poe by some
chance?
I'm not sure I know which topic you're
I am terminating this thread on monday at noon. People have
till then to say their peace.
-Matt
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
--- 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 know anything
cut
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
--- Martin P. Hellwig [EMAIL PROTECTED]
wrote:
cut
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 specs for my info
--- Martin P. Hellwig [EMAIL PROTECTED]
wrote:
cut all
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
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 field
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 far
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
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 about to
[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
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
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
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 heavily
--- 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.
: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
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
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
Danial Thom wrote:
cut
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
cut
What company? Your name doesn't ring a bell to me.
--
mph
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 he was
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-directional,
and if
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 [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? Typically
packet
: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 issues
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
: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
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
wall a
:...
: 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
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 matter,
:
--- 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 some
point
--- 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 packets,
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
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 you
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 we could have one
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 there
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 ~120
: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
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
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
--- 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 desparately
: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
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
of
--- 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
Routing packets doesn't
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
50 matches
Mail list logo
