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

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 [off-list ref] 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