close Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.
Modify

Opened 10 years ago

#243 new defect

Collective replication over GM requires "server-less" connections

Reported by: hauma Owned by: hauma
Priority: normal Milestone: JPlater
Component: uka.gm Version: 1.09c
Severity: normal Keywords:
Cc:

Description

In particular collective updates (see: ticket:157) are much slower when using KaRMI/GM instead of KaRMI/Ethernet. The reason seems to be that collective operations involve lots of (server-) threads for accumulating the required connections. Currently, a collective operation is mapped to multiple connections that normally serve as transport for remote method invocations. Each such connection is associated on one end with a server thread that is either responsible for executing the remote method invocation, or for forwarding the call to a waiting segment of a transparent distributed thread (see ticket:140).

The problem could be mitigated by introducing a second connection abstraction in KaRMI that is not automatically associated with a server thread. Such server-less connection can only be used, if two threads on both ends agree on a collective operation.

Attachments (1)

ugGM.patch (7.4 KB) - added by hauma 10 years ago.
Patch for uka.gm.GM that tries to finally suspend threads that are waiting for a message for some time. A suspended thread may only be reactivated, if another thread sends a signal about a received message. This patch improves the latency of ping() calls by 2us, but makes things worse for collective operations.

Download all attachments as: .zip

Change History (1)

Changed 10 years ago by hauma

Patch for uka.gm.GM that tries to finally suspend threads that are waiting for a message for some time. A suspended thread may only be reactivated, if another thread sends a signal about a received message. This patch improves the latency of ping() calls by 2us, but makes things worse for collective operations.

Add Comment

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain hauma.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from hauma to the specified user. Next status will be 'new'.
The owner will be changed from hauma to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.