tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tsp-devel] Blackboards number limitation


From: Eric Noulard
Subject: Re: [Tsp-devel] Blackboards number limitation
Date: Fri, 9 Oct 2009 20:50:37 +0200

2009/10/9 Bettina TANOH <address@hidden>:
>
>
> Eric Noulard a écrit :
>>
>> 2009/10/9 Bettina TANOH <address@hidden>:
>>
>> Which version of TSP do you use? On which kind of systems?
>>
> TSP 0.8.3 on Linux Fedora Core 9

OK.

>> What kind of error do you get?
>
> bb_create, bb_publish and bb_suscribe fail.

once bb_create has failed any other bb_xxxx will fail too.

>> You'll find 2 shells scripts,
>> - One which creates 20 BB "apparently" without trouble
>> - the second one destroys the BB
[...]
>
> I run the script "creates_bb.sh" on the machine where I upgraded system
> values and it works. On another machine with Fedora Core 9 OS, it fails.

Strange.
/proc/sys/kernel/
   shmni --> Maximum number of shared memory segments for the whole system
   shmmax -->  Largest shared memory segment size allowed
   shmall --> Total amount of shared memory that can be used

same kind of numbers for msg.
It would be interesting to know which one of this parameter you are
hitting. Note however that it depends on what other program is running
on the same host. For example squid (proxy cache) may eat a bunch of
shm segment depending on its configuration.

If you think you have an overall shm size pb, you should check
if you are not oversizing your BB. Checking this is simple,
launch your applications which creates your BBs then use

bb_tools dump <bbname>

at the beginning of the dump you'll see something like:
============= <[begin] BlackBoard [bb20] [begin] > ===============
  @start blackboard    = 0x7fc709cc0000
  stored data          = 0 / 20 [max desc]
  free data size       = 10000 / 10000
  @data_desc           = 0x7fc709cc0150
  @data                = 0x7fc709cc0fb0
================ < [begin] Data [begin] > ==================
...

so you can check the number of descriptor used and
the free data size.

> I finally got the problem: the names of the blackboards I use are too long.
> With shorter names I can create more than 16 blackboards, but still with
> system upgrade.

This may be another pb.
The Blackboard name is used to build
"most-of-the-time-unique" 32 bits  IPC identifiers.

This can be check with bb_tools too, supposed
$ bb_tools check_id bb20
bb_tools::SHM Key [name=</bb20>] is 0x1c7cbf07
bb_tools::SEM Key [name=</bb20_sem>] is 0x02ce8c61
bb_tools::MSG Key [name=</bb20_msg>] is 0x1753bac0

The algorithm used is an SHA-1 hash truncated to 32bits
ORed with user id in order to avoid multi-user clash.
Collision are then possible i.e.
**DIFFERENT** blackboard name may generates the same keys.

Could you gives us the list of names you use when failing?

If a name clash is the issue, please file a bug report
in order to make it easier to trace this fact for other.

we could try to use better
possibly non-cryptographic hash like MurmurHash2
http://murmurhash.googlepages.com/

> Thank you for your help



-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]