Hi, first, after a while owserver could be called pretty stable now using DS9490 in many (few hundreds) larger installations! And sorry for the long mail ;)
Now I want to get to some "luxury-problems" and improve performance/response-time of my client still; i.e. rewrite it in C with multithreading etc. but struggle finding "the perfect method" to balance speed, load and responsetime interfacing owfs. Given my realistic (test-)setup which I'll refer to in this thread: - owfs 2.8p15(*1), 5x DS9490, 45 slaves: (35x DS18B20, 6x DS2438, 4x DS2413) and a bunch of DS1990A iButtons, which are most of the time disconnected. - LX800@500Mhz (586) with some basic but steady load - the current client (single-threaded) runs in parallel No issues with the DS18B20 they take their time for convert_t, or DS2438 but I want to poll the DS2413 (IO) and iButtons connect/disconnect as fast as anyhow possible - uncached(??) The iButtons can/are connected to a sep. DS9490 with no other slaves on - but I cannot know which one it will be.. So assuming owfs uses sep. threads for each busmaster I thought it makes sense to use multiple threads on the client(s) either but have still some odd results and want to understand the internals of owfs better to optimize: (each test was carried out at least 100x, repeatedly) a) "owget /uncached" -> median: 2.43s, min: 1.51s, max: 4.82s (why is it so slow? worst case another client could do a parallel convert_t on a DS18B20 but this takes at most 1sec) b) "owget /" (cached) -> median: 0.11s, min: 0.05s, max: 0.88s Good news, thats pretty fast enough (but I have to do uncached owdir to get iButtons asap? OTOH I want the cache for other things so not disable it) c) "owget /uncached/3A.B4D207000000/sensed.ALL" (DS2413) -> median: 0.13s, min: 0.02s, max: 1.23s Well, fine either. d) "owget /uncached/01.CE7578120000/present" (with iButton present on 1w!) -> median: 0.01s, min: 0.00s, max: 0.11s Perfectly fine! e) "owget /uncached/01.CE7578120000/present" (with this iButton NOT present on 1w!) -> median: 0.88s, min: 0.27s, max: 2.10s Thats fine either in terms of my setup but it confuses me! Shouldn't it be exactly the same SEARCH_ROM on all busses as a) ? Other slaves haven't (dis)appeared during this test.. In tabular form: median min max a) 2.43s, 1.51s, 4.82s b) 0.11s, 0.05s, 0.88s c) 0.13s, 0.02s, 1.23s d) 0.01s, 0.00s, 0.11s e) 0.88s, 0.27s, 2.10s My goal is to optimize responsetime/latency, owserver load (currently 25-30% CPU, while decoding&playing a 320kbit MP3 takes 10% there) So I thought of at least 4 sep. threads: - continous uncached owdir - looking for iButtons (in cache) - getting DS2413/2406 IO's (uncached) - reading the - not time critical -remainder, cached And then I thought, if it wouldn't be great for owserver to have some kind of long-polling API where the client only gets notified if something interesting (again: iButtons, IO's) has changed instead of polling every 100ms.. Though I have no idea if/how this could be implemented.. During the next days I wanted to add some timestamp-output to debugging to find out where we loose these 1-3secs but maybe there is an easier way/thought.. Any ideas, comments, suggestions are welcome. *1): from the CVS commits I found nothing that should affect my setup but I could surely update.. Michael ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
