Re: [Bluez-users] hci_read_remote_name() simultaneously on multiple dongles question

["Jeffrey Cuenco" <jcuenco@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2511 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2986 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users