From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail239c25.carrierzone.com (mail146c25.carrierzone.com [64.29.147.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 101973B2A4; Fri, 27 Mar 2020 17:34:25 -0400 (EDT) X-POP-User: hmurray@megapathdsl.net Feedback-ID: hmurray@megapat Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail239c25.carrierzone.com (8.14.9/8.13.1) with ESMTP id 02RLYNFx027765; Fri, 27 Mar 2020 21:34:24 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id B90CA40605C; Fri, 27 Mar 2020 14:34:22 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: "David P. Reed" cc: Hal Murray , "bloat" , "Make-Wifi-fast" , "Cake List" , "cerowrt-devel" , "Ken Rice" , "Anthony Minessale II" From: Hal Murray Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Mar 2020 14:34:22 -0700 Message-Id: <20200327213422.B90CA40605C@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.3 cv=KeCsTjQD c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=kj9zAlcOel0A:10 a=SS2py6AdgQ4A:10 a=MOtRQ-d8iHuntgbCgrUA:9 a=CjuIK1q_8ugA:10 X-CTCH-RefID: str=0001.0A09020E.5E7E7161.0020, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-Origin-Country: US Subject: Re: [Cerowrt-devel] [Bloat] [Cake] mo bettah open source multi-party videoconferncing in an age of bloated uplinks X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 21:34:26 -0000 > I hate putting things in the kernel! It's insecure. But what this says is > that for very historical and stupid reasons (related to the ideas of early > timesharing systems like Unix and Multics) folks try to make real-time > algorithms look like ordinary "processes" whose notion of controlling > temporal behavior is abstracted away. Could you please say more. Why doesn't it work to put the time critical stuff in a separate light weight thread and give it higher priority than the stuff that needs lots of CPU? Is the problem in the scheduler? Is background junk overloading the system? (Are people rebuilding the kernel while video converencing?) Is it too hard to split out the logic that would go in the light weight thread? (get tangled on locks or such) -- These are my opinions. I hate spam.