OK, so this is a single user device, right? If the kernel isn't
arbitrating access to the device then you either have to have a bunch
of friendly (and smart) users or it's single user. Once again, hardly
a fair comparison. You can make just about anything have really great
performance if you drop off all support for time sharing, etc.
: It's just raw ethernet but it does carry a multiplexed data stream with
: different streams waking up different threads.
:
: It is relevant -- don't compare with in-kernel TCP/IP, compare with
: in-kernel AF_PACKET.
Great, go ahead. What are the AF_PACKET numbers doing the same thing?
: Someone else has managed TCP/IP at 83MByte/sec which is not quite
: saturating the link and uses all the CPU. Never mind eh? :)
Yeah, yeah. SGI has managed to get TCP/IP to run at 640MByte/second using
tiny amounts of CPU so so what? These are still apples to oranges.
: > Again, if you are comparing apples to apples, you have a fantastic
: > point and I want to learn more and I'll happily eat my words in public.
: > But if you are comparing TCP/IP performance with raw packet performance,
: > that's like comparing a Geo with a Ferrari. Not exactly meaningful.
:
: No I'm comparing user-space raw ethernet + demultiplexing with kernel
: raw ethernet + demultiplexing.
Err, the only numbers you have quoted are for TCP/IP and your raw packets.
You haven't quoted the kernel raw ethernet + demultiplexing numbers
anywhere that I've seen. Or did I miss that?
Anyway, if your hardware can get these numbers without kernel support,
I'm pretty sure you can also get these numbers with kernel support.
In fact, I'm positive, it's been done at SGI, I've seen it, hell, I've
worked on it. And the difference is that the kernel supported version
can give you real demultiplexing, real security, all for multiple users.
It's real hard, if not impossible, to do that without some help from
the kernel. hence my claim that we are still a long way from an apples
to apples comparison.
That doesn't invalidate your data, it just says that what CERN is
trying to do is not the same as what a general purpose time sharing OS
is trying to do. It may be perfectly OK with you (and others) to say
that you are willing to give up a bunch of stuff to get what you want,
but then this isn't exactly the perfect place to be discussing that.
This is the linux-kernel list and we are still pretty committed to
providing Unix semantics...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/