Zbr's days.
November
Sun Mon Tue Wed Thu Fri Sat
       
29  
2007
Months
Nov

About TODO Blog RSS Old blog Projects Gallery Notes

Thu, 29 Nov 2007

The 21'th netchannels release.

Netchanel is a peer-to-peer protocol agnostic communication channel between hardware and users. It uses unified cache to store channels, allows to allocate buffers for data from userspace mapped area or from other preallocated set of pages (like VFS cache). All protocol processing happens in process context.

Users of the system can be for example userspace - it allows to receive and send traffic from the wire without any kernel interference, to implement own protocols and offload its processing to the hardware.

This idea was originally proposed and implemented by Van Jacobson. This patchset (with userspace netowrk stack) is a logical continuation of the idea with move to the full peer-to-peer processing.

One of its users is userspace network stack.

Short changelog:

  • fixed queue length usage
  • fixed dst release path. Both problems reported by Salvatore Del Popolo (delpopolo_dit.unitn.it)
  • removed nat user
More details can be found on project homepage.

/devel/networking :: Link / Comments (0)


B(something)-tree vs. RB-tree.

This simple benchmarks test btree vs rbtree search and insert speeds, when nodes are allocated in memory.
Btree is (likely) a b+tree where each data node is located at the bottom layer (probably it is a bit different, algorithm does not strickly follow rules described in btree papers. 1 million entries were inserted or searched in the tree.
Graphs below show speed of the given operation depending on number of keys in the btree node (when number of keys is smaller than 20 linear search ofthe key is used, otherwise binary search).

B(something)-0tree vs. RB-tree. Search speed.

B(something)-0tree vs. RB-tree. Search speed.

B(something)-0tree vs. RB-tree. Insert speed.

B(something)-0tree vs. RB-tree. Insert speed.

As you see, btree search is about 2-2.5 times slower than rbtree. This can be clearly described by the fact, that rbtree contains data in each node, while btree only in the lowest nodes, so each btree search requires to travel over all layers (this is roughly equal to log2(number of keys in each node)) multiplied by number of keys in each node (in the worst case), while rbtree needs to perform the same amount of searches only in the worst case, while generally it requires about 2 times less traverses.

Btree insert speed can be even slightly faster than rbtree, since during insertion tree grows from low levels and each new allocation reserves space for several keys, thus greatly reducing number of needed splits or rotations.

I will run the same tests for the case, when all nodes are allocated from disk storage, which should show clear win of the btree approach.
Stay tuned.

/devel/fs :: Link / Comments (0)


Astonishingly screwed tapeworm.

New release of the distributed storage subsystem. This is maintenance release and includes bug fixes only.

Short changelog:

  • use node's size in sectors instead of bytes
  • fixed old/new ages for the first node. Error spotted by Matthew Hodgson (matthew_mxtelecom.com)
  • fixed debug printk declaration
  • new name
Overall list of features of the DST can be found on project's homepage.

/devel/dst :: Link / Comments (4)