Return-Path: Message-ID: <8de6c3e20708240759ya2e1619yfdcf55413a5d3d07@mail.gmail.com> Date: Fri, 24 Aug 2007 07:59:36 -0700 From: "Jeffrey Cuenco" To: "BlueZ users" In-Reply-To: <1187957780.15402.152.camel@violet> MIME-Version: 1.0 References: <8de6c3e20708220924g3a8db7a5paa153e99b5d829ea@mail.gmail.com> <1187957780.15402.152.camel@violet> Subject: Re: [Bluez-users] hci_read_remote_name() simultaneously on multiple dongles question Reply-To: BlueZ users List-Id: BlueZ users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0932052125==" Sender: bluez-users-bounces@lists.sourceforge.net Errors-To: bluez-users-bounces@lists.sourceforge.net --===============0932052125== Content-Type: multipart/alternative; boundary="----=_Part_82280_23312594.1187967576385" ------=_Part_82280_23312594.1187967576385 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Marcel, I understand that you just pointed out that it was a design mistake to be able to access HCI functions directly (even I avoided it for a time assuming they were 'locked-out' due to my experience with other API's, however, the only function that I use is hci_read_remote_name_with_clock_offset. so that I can use the clock offsets, and they seemed to lead to a performance increase in the reply-time of name replies. Thanks for the point-out though. If the other method works fine then I see no need to post a patch as what I'm doing is a little bit more custom than the average usage as we're using them as part of a research project. Regarding the dbus-based API: Are you referring to the hci_remote_name() function instead? Also, another problem that I seem to be encountering has nothing to do with the name resolution, but rather that after a time the hcid will start to accumulate CPU time. Looking at just the TIME and COMMAND fields of a 'ps aux' call, 0:41 /usr/bin/dbus-daemon --system 2:26 /usr/sbin/hcid I noticed that whenever my program had super-high CPU time in the double-digits (e.g. 47:21), that the hcid usually had high CPU time as well, and it seems the dbus-daemon's CPU time accumulates as well. I was wondering what could cause this to happen? Sometimes the CPU time accumulates so fast that after barely 4 hours of use (we're using it as a 4-dongle scanner with 1 inquiring and 3 name-querying dongles as part of a research project at UCSD) the dongles stop doing anything altogether and freeze, and the only way I can get them to respond quickly again is to kill my program, and sometimes, to restart hcid as well. In this case, dbus-daemon also sometimes accumulates in CPU usage. The only thing that my program does HCI-wise is continuously inquire on 1 dongle (reset list flag set), continuously name-query on each other dongle from a queue filled by the results of the 1st (it resets the dongle if a hci_read_remote_name_with_clock_offset() call fails). Again thanks in advance, but any suggestions and/or recommendations regarding this issue would be much-appreciated On 8/24/07, Marcel Holtmann wrote: > > > feel free to post a patch, but honestly this is broken for quite some > time now. The kernel and the new D-Bus based API have no problems with > it and that should be the main way to retrieve remote names. So I am not > really keen to fix this since direct HCI access for userspace apps was a > design mistake. > > -- -Jeff ------=_Part_82280_23312594.1187967576385 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Marcel,

I understand that you just pointed out that it was a design mistake to be able to access HCI
functions directly (even I avoided it for a time assuming they were 'locked-out' due to my experience
with other API's, however, the only function that I use is hci_read_remote_name_with_clock_offset.
so that I can use the clock offsets, and they seemed to lead to a performance increase in the
reply-time of name replies.  Thanks for the point-out though.  If the other method works fine then I see
no need to post a patch as what I'm doing is a little bit more custom than the average usage as
we're using them as part of a research project.

Regarding the dbus-based API:

Are you referring to the hci_remote_name() function instead?  Also, another problem that I seem
to be encountering has nothing to do with the name resolution, but rather that after a time the hcid
will start to accumulate CPU time.  Looking at just the TIME and COMMAND fields of a 'ps aux' call,

0:41 /usr/bin/dbus-daemon --system
2:26 /usr/sbin/hcid

I noticed that whenever my program had super-high CPU time in the double-digits (e.g. 47:21), that
the hcid usually had high CPU time as well, and it seems the dbus-daemon's CPU time accumulates
as well.

I was wondering what could cause this to happen?  Sometimes the CPU time accumulates so fast that after
barely 4 hours of use (we're using it as a 4-dongle scanner with 1 inquiring and 3 name-querying dongles as
part of a research project at UCSD) the dongles stop doing anything altogether and freeze, and the only way I
can get them to respond quickly again is to kill my program, and sometimes, to restart hcid as well. In this case,
dbus-daemon also sometimes accumulates in CPU usage.  The only thing that my program does HCI-wise
is continuously inquire on 1 dongle (reset list flag set), continuously name-query on each other dongle from a queue
filled by the results of the 1st (it resets the dongle if a hci_read_remote_name_with_clock_offset() call fails).

Again thanks in advance, but any suggestions and/or recommendations regarding this issue would be
much-appreciated


On 8/24/07, Marcel Holtmann <marcel@holtmann.org> wrote:

feel free to post a patch, but honestly this is broken for quite some
time now. The kernel and the new D-Bus based API have no problems with
it and that should be the main way to retrieve remote names. So I am not
really keen to fix this since direct HCI access for userspace apps was a
design mistake.



--
-Jeff ------=_Part_82280_23312594.1187967576385-- --===============0932052125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- 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/ --===============0932052125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users --===============0932052125==--