Jamie Lokier <[EMAIL PROTECTED]> writes:
> Richard B. Johnson wrote:
> > However, PCI to memory copying runs at about 300 megabytes per
> > second on modern PCs and memory to memory copying runs at over 1,000
> > megabytes per second. In the future, these speeds will increase.
>
> That would be
> considered to be in the "window of scarcity" (today we have 100MBit
> Ethernets and 133++MB/s PCI). Tomorrow our operating system concepts
> have to cope with 1, 10, ?? Gigabit Ethernets, Infiniband ,
> ... who knows.
We had to write our own RPC mechanism because with the standard-stacks
we had
At first, thanks for the (unexpected large) discussion and hints!
Second: sorry for the multimedia-centric viewpoint, but i think
it's an important task for future operating systems development
(or better: for a real world OS like linux) to have sophisticated
support for a _large diversity_ in
Alan Cox wrote:
> > so there's still single copy for write() of a mmap()ed page?
>
> An mmap page will go direct to disk.
Looking at the 2.4.4 code, mmap() of file followed by write() to socket
will copy the data once.
I could be mistaken (only glanced at the code quickly) but I base that
on th
On Mon, 7 May 2001, Richard B. Johnson wrote:
> Basically, "no copy" is an academic exercise. It makes the first
> packet get sent more quickly, after which everything slows to
> the natural bandwidth of the system.
>
> If you used a server for multicast-only. In other words, you
> just spewed
> so there's still single copy for write() of a mmap()ed page?
An mmap page will go direct to disk. But mmap() isnt a good model for
streaming I/O.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Richard B. Johnson wrote:
> However, PCI to memory copying runs at about 300 megabytes per
> second on modern PCs and memory to memory copying runs at over 1,000
> megabytes per second. In the future, these speeds will increase.
That would be "big expensive modern PCs" then. Our clusters of 700M
On Mon, 7 May 2001, Richard B. Johnson wrote:
> When we get to media that can sink data as fast as we can generate
> them (it), then we have to worry about memory copy speed. However,
> these new devices are actually an IP subsystem. They generate and
> receive entire datagrams. To fully utilize
On Mon, 7 May 2001, dean gaudet wrote:
> On Mon, 7 May 2001, Richard B. Johnson wrote:
>
> > when the hardware I/O is used. This shows that the network code, alone,
> > cannot be improved very much to provide an improvement in throughput.
>
> doesn't your analysis assume that we've got nothing
> Then there's the interrupt problem, which someone will have to solve
> before they start shipping 10gigE NICs that use 1500-byte frames, 85
> interrupts/s without mitigation. Wh
In this situations polling helps rather than interrupt driven IO. When there
is heavy IO(read more interr
On Mon, May 07, 2001 at 12:12:57PM -0400, Richard B. Johnson wrote:
> you can perform network speed tests using "lo", removing the network
> board from the speed test. You will note that the network speed, due
> to software, is over 10 times faster, 30 times on some machines) than
> when the hardw
On Mon, 7 May 2001, Richard B. Johnson wrote:
> when the hardware I/O is used. This shows that the network code, alone,
> cannot be improved very much to provide an improvement in throughput.
doesn't your analysis assume that we've got nothing else interesting to do
while doing the network i/o?
On Mon, 7 May 2001, Alan Cox wrote:
> > documented so far) detailed description of the newly
> > implemented zero-copy mechanisms in the network-stack.
> > We are interested in how to use it (changed network-API?)
> > and also in the internal architecture.
>
> It is built around sendfile. Trying
On Mon, 7 May 2001, Francois Romieu wrote:
> It shows that cached code performs well with ~0us latency device/memory.
>
> Networking is about latency and pps too. They both dramatically reduce
> the (axe-)evaluated bandwith.
I think his point is more along the lines of return on investment. You
Richard B. Johnson <[EMAIL PROTECTED]> ecrit :
[...]
> when the hardware I/O is used. This shows that the network code, alone,
> cannot be improved very much to provide an improvement in throughput.
It shows that cached code performs well with ~0us latency device/memory.
Networking is about late
On Mon, 7 May 2001, Alan Cox wrote:
> > documented so far) detailed description of the newly
> > implemented zero-copy mechanisms in the network-stack.
> > We are interested in how to use it (changed network-API?)
> > and also in the internal architecture.
>
> It is built around sendfile. Tr
> documented so far) detailed description of the newly
> implemented zero-copy mechanisms in the network-stack.
> We are interested in how to use it (changed network-API?)
> and also in the internal architecture.
It is built around sendfile. Trying to do zero copy on pages with user space
map
17 matches
Mail list logo
