From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1C52C3CB42 for ; Thu, 22 Feb 2018 11:38:24 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1519317503; bh=JhXTIJKycLdGOzqV1VVIlkJ2sDeviocmmFhOGHFjP8k=; h=From:To:Subject:In-Reply-To:References:Date:From; b=mRuQuHGy+/LDRLtcdaugWnq9eYVwfk0iMUsa55mAvBuPc7hKPqRd7vBZhlL4pjSpk 89N7u/M4MABR31wuCmGd2dqFSenbGqsIczvmbl71W82OL4mF70yEVbzNQgw/HnUsGp vZaGQPAxGbwUY+2nsHoU0Bm8XTpKsOaDP5gumV/5KUivTSfp1W5enLDPgi3DVKclwV kqdUnWvwsPJc86jFVHdVmjAsGSja6QKajea0yhjECCnjWPsMUmbJ0kG5CKC3GOw5NR dpQwmfICEMaPTsE25SlgrTvab0qHMIpC2UFtePoLxTQZBoEWCupydm7f0pJuwG+/T+ gx0TEbFK6IiUQ== To: Siavash Eghlimi , bloat-devel@lists.bufferbloat.net Subject: Re: Help me get started (II) In-Reply-To: References: Date: Thu, 22 Feb 2018 17:38:22 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bmgh9dz5.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 16:38:24 -0000 Siavash Eghlimi writes: > --Was there something there you thought was interesting that you want to > explore further? > Well, this whole thing is interesting. I didn't know that I'm NOT using > about 47% of my bandwidth :) (talk about helping people...) > turned out, ALL of my devices have SOME kind of a problem in this area. > but, what was MOST interesting to me was "How much I don't know"; I'm not > only talking about knowledge, but about these problems that exists and MANY > people, even PROs (not that I am one), don't know about. > Science-wise, most interesting part is the implementation of algorithms and > protocols that caused these problems in the first place. why did they cause > it? integrating some of the solutions together (like SQM). things of that > nature is interesting to me. generally, Implementation is more interesting > to me than the solution, itself. (How to do, rather than WHAT to do.) Ah, sounds like the true hacker spirit; excellent ;) So in this vein, and since you're running DSL, one project might be to get your hands on a DSL device with a hackable driver and see if you can get the driver on its own to perform on par with ethernet. I.e., fix it so it doesn't need the software shaper on top that we currently use in sqm-scripts, but would work well with low latency just by installing fq_codel as the root qdisc on the interface. This would involve figuring out how to integrate BQL into a DSL driver, probably; I think the lantiq driver would be the one to look at (since it's open source), but I have no idea how much work it would be to get something working. It would certainly be useful, though (you'd have basically shown that the uplink side of DSL can be fixed). And it's certainly something you can pretty much just start hacking on. The downside is that there's a risk of being really frustrated when working this close to hardware that is probably not terribly well documented, and it may be that the driver requires quite a bit of surgery. But from a thesis perspective, describing this and coming up with a design to do something about it might be quite viable, even if you don't get all the way. > --And what did you read already? :) > 1. Classic bufferbloat article. > 2. ALMOST advanced network concepts like "Window Scaling" , "Framing", > etc. etc. > 3. One fourth of "TCP/IP Architecture in Linux .... " > 4. Wireshark (Basics) > > So, my question: > first, any suggestion, generally, so far? Well, first off, understand the problem you are trying to solve, describe your proposed solution and why it is a good idea, then go implement it. Mostly in that order (though there's also a feedback cycle here). > second, I tried to study FreeBSD since Linux was TOO BIG. anyway, I found a > good book and as I was studying, I could swear I saw something in " > bufferbloat.net" about FreeBSD. So, I checked it out; turns out it's a > project to implement some algorithms like CoDel into FreeBSD. Immediately, > I emailed the professor in charge, and he simply said: "I don't have time" > :) > This project seemed tailor-made for me. lots of coding. something CLEAR to > do. loads of stuff for the Thesis. lots of science and knowledge. but > .... Heh, yeah, Linux is big and the code changes at a tremendous pace. Can be daunting at first. You don't have to understand all of it to do something useful, though (I don't think there's *anyone* who understands the whole Linux kernel as it is today). I don't really know a lot about FreeBSD in this respect; and am not terribly up to date on the state of bufferbloat mitigation is in BSD either. If you wanted to look into it for your thesis, what you could do is setup an experiment to compare them (Linux and BSD, that is) and if one is better than the other figure out why and fix it :) > Second place goes to "Flent", though I don't know how much work is there to > be done. Can it bear a thesis for me ? Hmm, if you wanted to work on Flent you could pick a new feature to implement. If you want to keep a network research component to the thesis, it would be a new kind of measurement that you could add. But it could also be general feature additions, which would make your thesis more software engineery, I think. Hmm, in the former category you could try to implement a measurement that would detect the presence of fairness queueing in the network. In the latter category you could try to get incremental test runs from the GUI (and interactive plots while the test is running) to work. That's all I can think of off the top of my head, but there are probably other tests that might be useful to have; perhaps someone else can chime in... > Third place goes to "SQM". Hmm, one thing that comes to mind here would be to do a comprehensive comparison of the Cake qdisc to the HTB+fq-codel-based setup that sqm-scripts uses when Cake is not available. We eventually want to upstream Cake in Linux, and having comprehensive benchmarks to point to would be useful in this regard. May also be some tweaking to be done on the qdisc in relation to this. > I really wanna start sooner than later and get my hands dirty. I know, this > is not enough research to know exactly what you want, but my time is > limited and I better begin. > (By the way, I can put 7 months on it.) Enthusiasm is a good starting point, certainly! :) -Toke