From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 30 Jan 2008 10:03:57 +0100 From: Juan Antonio Garcia Redondo Message-ID: <20080130090357.GA4289@domain.hid> References: <2ff1a98a0801230204s15e4eefaifdd2c946c44549df@domain.hid> <2ff1a98a0801230515i77f8c22bk866c4cd592a3a9b8@domain.hid> <20080124094150.GA7503@domain.hid> <2ff1a98a0801240202g83ca10esd2f7fc928946e3c1@domain.hid> <20080125100404.GA8833@domain.hid> <2ff1a98a0801250900if03294epded12290544d5480@domain.hid> <20080128085123.GA7297@domain.hid> <2ff1a98a0801280519m62768928x5e5fa40123abe9cd@domain.hid> <20080129080922.GA6314@domain.hid> <2ff1a98a0801290919h5de50ad0h3176968ebbc9af61@domain.hid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ff1a98a0801290919h5de50ad0h3176968ebbc9af61@domain.hid> Subject: Re: [Xenomai-help] AT91SAM9260 latency List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: jagarcia@domain.hid, xenomai@xenomai.org On 29/01/08 18:19, Gilles Chanteperdrix wrote: > On Jan 29, 2008 9:09 AM, Juan Antonio Garcia Redondo > wrote: > > > > On 28/01/08 14:19, Gilles Chanteperdrix wrote: > > > > > > > > > > > > > > > > > No mystery: hitting a key on a telnet session causes an interrupt > > > > > > > masking section of 110us, you see it as the maximum if you never > > > > > > > observed longer masking sections, but it is not the maximum if you > > > > > > > observed longer masking sections. > > > > > > > > > > > > OK, but why the masking section on linux side affects to xenomai side ? > > > > > > Another thing I don't understand is why when the system has load (above > > > > > > I'm talking about calibrator but the same occurs with dd if=/dev/zero > > > > > > of=/dev/null), the effect seems to dissapear. > > > > > > > > > > It is probably not a masking section on linux side but rather a > > > > > masking section on I-pipe side. Anyway, the effect does not disappear: > > > > > it means that the cache effects cause larger latencies than the > > > > > ethernet interrupt, but maybe I did not understand what you explained. > > > > > The results you obtain with no load are simply irrelevant. > > > > > > > > I'll try to explain it better: > > > > > > > > o Without load I run ./latency -t0 -p500. > > > > RTD| 33.182| 53.479| 67.976| 0| 31.250| 77.319 > > > > RTD| 43.170| 53.479| 67.654| 0| 31.250| 77.319 > > > > RTD| 41.881| 53.479| 67.332| 0| 31.250| 77.319 > > > > RTT| 00:02:07 (periodic user-mode task, 500 us period, priority 99) > > > > > > > > o Each time I press a key (over a telnet session) I can see the lat_max field increase on 40 to 50 us aprox. > > > > RTD| 33.505| 53.479| 71.842| 0| 26.739| 77.319 > > > > RTD| 40.592| 62.177| 123.067| 0| 26.739| 123.067 > > > > ------- > > > > \_________: Key pressed > > > > RTD| 50.579| 53.479| 73.775| 0| 26.739| 123.067 > > > > > > This is where you are wrong: > > > - first, let me repeat it: test made without load are irrelevant; > > I can't agree with you. When we stress a system with load is, as far as > > I know, because usually, the large latencies don't appear on a quiet > > system. Here we have a case where a large latency (the lat_worst number > > I've gotten after more than 7 hours with the system fully loaded is even > > less than this) appears on a quiet system and directly related to an > > external event. > > > > > - second, an event has no relative effect on max latency, its effect > > > is absolute: pressing a key over a telnet session causes, for unknown > > > reason, a masking section of around 130us, which happens to also be > > > the worst case latency that we measured properly with a loaded system. > > I pointed out the lat_max field because, if you keep the latency test > > running and hit a key on a telnet session, you can easily see how the > > lat_max increase each time you hit the key, while the lat_worst increase > > depends on the former history. > > > > > > > > Now, if you want to know why you get such a masking section, you are > > > free to investigate. > > > > I'll try to do it. > > Does the network driver use the AT91 PDC ? If yes, and if it is > possible to disable it, could you try disabling it ? Yes, the network driver uses DMA and is not easy to disable it. Anyway I have, in my custom board, an additional ethernet chip (smc91x). I've done the former tests with the smc91x (LAN91C111), which can't use DMA, and the behaviour is similar. Regards, Juan Antonio