RE: [coLinux-devel] Kernel-to-Kernel networking support?

[peter g. <plu...@bi...>]

there is a little known api function in windows that increases the system
tickrate
its called timebeginperiod
i wonder what effect this would have on colinux

> -----Original Message-----
> From: col...@li...
> [mailto:col...@li...]On Behalf Of Dan Aloni
> Sent: 11 October 2004 21:20
> To: col...@li...
> Subject: Re: [coLinux-devel] Kernel-to-Kernel networking support?
>
>
> On Mon, Oct 11, 2004 at 09:29:55PM +0200, Christian Kauhaus wrote:
> > Hello!
> >
> > After doing some initial research on our coLinux-openMosix integration
> > project (which is basically working, but slooow), we quickly found out
> > that the main source of performance problems lies in the networking
> > code. All network data is going round between kernel space and user
> > space, while being copied several times. This leads to a rather high
> > latency (we got a minimum of about 400 ?s on our hardware) and a maximum
> > throughput that is basically CPU-bound (not reaching wire speed in our
> > case).
>
> The cause of the latency is scheduling, not copying.
>
> When the conet driver sends a packet, it switches to the Windows side
> and the packet is copied to the Windows driver. So far so good. However,
> for some reason, Windows decides to prioritize other processes rather
> than giving control back to the daemon right away. If there's queue
> of packets waiting to be sent from Linux, it just waits there until
> Windows decides to return back to Linux.
>
> The problem stems from the fact that the packet goes up to userspace,
> then sent to the network daemon process using a pipe (which means it
> goes down to the kernel again and up), and then written to the TAP
> driver. This mean that for almost every packet (or groups of few packets)
> we go all the way throught and back, which incurs considerable overhead
> per packet.
>
> This redundant I/O activities cause enough CPU usage for confusing
> the scheduler. It is also possible that Windows has some "logic"
> inside for prioritizing I/O activities, who knows.
>
> AFAIK there are no interfaces in Linux to hint whether a big outbound
> queue exists. Forcing Linux's continuity of execution when packets are
> being sent will increase the throughput while reducing the overhead,
> but will also increase the round trip time to 1/HZ, so it's not a
> good solution.
>
> > To resolve the network performance bottlenecks, I think we need to
> > "short-circuit" the data flow and handle network issues directly in the
> > kernel, much alike block device access yet.
>
> I agree, this might solve the scheduling problem. However, I'm not an
> expert in Windows kernel programming so connecting the TAP driver with
> the coLinux driver is not something I've managed to figure out how to
> do so far, nor I dedicated enough time for it.
>
> --
> Dan Aloni
> da...@co...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to
> find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel