From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,9162fb4f61af163a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-10 09:24:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!fr.usenet-edu.net!usenet-edu.net!enst.fr!not-for-mail From: Peter Newsgroups: comp.lang.ada Subject: Re: Reduce scheduling interval on Linux... Date: Sun, 10 Nov 2002 18:23:15 +0100 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: avanie.enst.fr 1036949042 96315 137.194.161.2 (10 Nov 2002 17:24:02 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Sun, 10 Nov 2002 17:24:02 +0000 (UTC) Return-Path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: , List-Id: comp.lang.ada mail<->news gateway List-Post: List-Help: List-Subscribe: , Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:30687 Date: 2002-11-10T18:23:15+01:00 Peter writes: >> On Red Hat linux a delay 0.0; would mean that process (thread) will be >> out of processing for 10 (ms) by default. This is a kernel >> configuration, and a good value in many cases. For my application I >> would like to reduce this time to maybe 1 (ms), or try to optimise it >> to the perfect value for the application. Yes, I know I am trying to >> make a RTOS of something that is not, but this is really the only >> thing missing, and the advantages of having a full system at least for >> development makes me rather accept 10 (ms) that to have to cross >> compile all the time. >> >> Has anyone been changing this and could point me in the right >> direction. Tried to do this once on Red Hat 7.0....but only got >> confused by the parameter names and the comments around them in the >> kernel.... Are you aware of any other full systems, beeing it Linux, >> BSD or whatever were this value is lower or easily could be changed ? > > Simon Wright answers: I don't have the source installed at the moment, but on the 2.0 kernels you could change the tick time by altering include/asm/param.h to set HZ to 1000. I think you also have to change kernel/sched.c in sys_nanosleep() -- there's a busy wait for sleeps (as root) of 2 mS or less. Then (just) rebuild and go! We had machines that stayed up for (a few) weeks with this setting. NB1: if you have a loop with a delay, the maximum repetion rate you will get is half the jiffy frequency -- HZ=1000 gives 500 loops/sec. NB2: the real reason stock Linux isn't a RTOS isn't the 10 mS clock -- VxWorks has a 60 Hz clock out of the box -- rather, it's the unpredictability of kernel scheduling. Peter comments: Thank you for your reply. I will have a look at this later this week. My comment about RTOS was a bit clumsy. I have been using pSOS and VRTX for many embedded systems, so I am aware of the differences. I just wanted to put in a comment to avoid the 'easy way out' comments like; run anoth OS. If I at any time in the future will make this software into a product I will most likely look in that direction, but at this point predictability is not an issue, as long as response stays within a few ms (will add gitter to the IP traffic). With my solution today I add a gitter up +0 -- +10 ms, plus a delay of a few up to several hundred ms (depending on configured queue depth, and traffic class). Reducing the gitter down to ~1 ms will make me fully in charge of deciding the behaviour of the system (in some cases I might still choose to have higher gitter because of better total performace of the system). Thank you again for your reply. If I am successfull I will let you know. Regards Peter Atterfj�ll