lkml.org 
[lkml]   [1998]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: network nicety
    On Wed, 7 Oct 1998, Bob Lanning wrote:

    > This is in IPv6. Traffic prioritization. There are boxes that sit in the
    > middle of you stream and mess with TCP streams to prioritize traffic.
    > Packeteer is one.
    >
    > It is very hard to implement something like this. The data channel for ftp
    > has no real identification in it. The best way of doing this is in the
    > application.
    >

    The server sits on a well-known port right/?

    > ---- As written by David Feuer:
    > >
    > > If this has been rejected or implemented before, please let me know,
    > > but....
    > >
    > > I am often frustrated that when I am running a network-intensive
    > > long-term process (generally a big FTP download), I get a big slowdown
    > > of burst-oriented interactive use (email, web browser, etc.). This is a
    > > particular problem since I am using a PPP connection. I have a couple
    > > ideas for solving this problem, and similar ones.
    > >
    > > First, I think that programs should have a netnice value (nnice?), along
    > > with a nice value. When transmitting packets, lower niceness processes
    > > (or threads.....) get higher priority. So if I were running a
    > > significant-use ftp server, I could set the netnice for my ftp server to
    > > 13, allowing other processes on my machine to have better
    > > responsiveness. Similarly, when using an ftp client to upload something
    > > big, I could set the netnice to 17 and keep on browsing. The best thing
    > > is that the performance of those big network transfers would not really
    > > go down much. They would just interfere less.
    > >
    > > This is only half a solution. It pretty much only solves sender-side
    > > problems. For home systems such as mine the big issue is receiver-end.
    > > When I am doing a big FTP download, web browsing often slows to a
    > > crawl. I was thinking that there might be some way to combine
    > > kernel-level changes with a modification of the pppd client+server to
    > > support some prioritization of the PPP link. I don't really know how
    > > this would work. It would be nice if I could set the nicety of a
    > > receiving program (ftp client, etc.), and have that tell the PPP server
    > > on the other end that it should make packets destined to ports owned by
    > > this process a low priority. One possibility would be to buffer them
    > > until there was network time (or their brief turn came around), and
    > > dropping their packets when the buffer is full.
    > >
    > > I think that some of these ideas (probably with huge modifications)
    > > could help improve Linux network performance.
    > > --
    > >
    > > Remove "NOSPAM" to reply.
    > > ______________________________
    > > / David Feuer \
    > > | dfeuer@NOSPAMbinx.mbhs.edu |
    > > | feuer@NOSPAMhis.com |
    > > | daf@morseNOSPAM.usno.navy.mil|
    > > \ david@NOSPAMfeuer.his.com /
    > > -----------------------------
    > >
    > > -
    > > 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/
    > >
    >
    >
    > --
    > Robert Hajime Lanning Navigation Technologies
    > Unix Systems Administrator 740 E. Arques Ave.
    > (408) 617-5059 Sunnyvale, CA 94086
    > lanning@fhda.edu USA
    > lanning@kewltech.com lanning@navtech.com
    >
    > -
    > 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/
    >


    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:0.025 / U:0.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site