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