Hi Robert, where is your netiquettes? Dropping CCs... ;)
Robert Schwebel wrote: > On Fri, Aug 10, 2007 at 06:25:03PM +0200, Jan Kiszka wrote: >> For this, I would suggest to start with analysing the TX and RX code >> paths in normal Linux or -rt. User-triggered latency tracing or LTTng >> might help. Then the next step would be a lock-dependency analysis. I >> would be curious to hear about your findings. > > Yup. > >> BTW, do you already use some of the emergency pool reservation patches >> for this? I read interesting ideas recently on netdev, though no code >> for those is written yet. > > Not yet, although I've followed the discussion with interest. We just > made our first steps in that direction, so we don't have any rock-solid > data yet. > > Today we tested with 'ping -f' load to rise interrupt load, and with > /dev/zero -> netcat -> /dev/null traffic on the non-RT interfaces > between the two RT boxes. The histograms don't look too different; with > 1 hour of measure time it's still something like 320 us worst case round > trip time. (I know that this is not representative, but anyway) This /can/ be representative, but you first have to know what your are measuring, ie. if you stressed the right paths/locks and if they aligned in the "right" order during the test. Looking at the Linux stack just as a black box doesn't take you far. > >> In any case, memory pressure should be part of your load scenarios. > > Next steps will be to apply default loads, like hackbench and cache > calibrator. I'm not sure if low-memory situations are a real scenario, > because on usual control systems you have a well defined set of > applications which don't do much dynamic memory management. mm activities of Linux are not that simple to model. You either loose reliability of your system or you have to restrict its features/applications really _drastically_ (but then you also don't have to bother running hackbench or calibrator either). > Nevertheless, it should be tested. > > Robert Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
