Thought I would post this here too, as some may be interested.
Today we ran the first real test of the new channeled ledger aka Transaction Forest, and despite most of the code being very untested, incomplete and in need of optimizing, the result was pretty good!
Before I get to exactly how fast, let me first set a few points you should keep in mind:
The test was ran in a small network of around 10 nodes
Due to the small network size, only around 20 channels were in use at any one moment
Live network will support potentially unlimited channels
Most nodes were also running all other services as well as transaction verification (hatching)
After setting up and performing some ramp up we set about applying load to the network, this is simply done by cross spamming each other with transactions, with each node producing 2-3 transactions per second to the network for processing.
With all nodes participating, there should be between 20-30 total transactions per second being presented to the network, however it is difficult to determine exactly the transaction quantity each node is presenting at any one time, and if all are indeed operating at the expected pace. Therefore it can (and probably does) vary throughout the test by perhaps +/- 5 tx/s at any one moment.
Our peak processing load during the test was 110 tx/s, with many peaks hovering around the 50tx/s mark, see screen shot below:
![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.emunie.com%2Fimages%2Fscreenies%2F110txs.jpg&t=665&c=TpsnPCuItIs_zQ)
As you can see from the graph, there are definite regular peaks of transaction load, with a baseline transaction throughput around the 15tx/s mark.
What you can see here is a saturation of available resources, most specifically, bandwidth! Most of the nodes in the test network are behind ADSL connections, and while having good downstream bandwidth, many of which have only 5-10Mb/s upload. As I'm sure many of you know with ADSL, the more of the upload bandwidth you use, the download availability and ping rates suffer dramatically.
All of the nodes in the test were hatching, and connected to a few other nodes, which results in a significant amount of upstream being used for broadcasting verified and countersigned transactions, along with additional upstream bandwidth being used for data delivery for other services, most nodes were hitting upload bandwidth limits.
The graph reflects this almost perfectly, you can see there is a burst of transaction verification activity from all nodes, which quickly saturates most nodes upload bandwidth, preventing them from presenting transactions quite as fast as they would like. The lesser loading after the peaks, are those slower frequency transactions making it out to the network, along with the 2 nodes that were not upload limited as they were sitting on 100Mb/100Mb lines. Shortly after, everyone catches up, upload saturation drops, and we have another burst of transactions around the network. Rinse and repeat.
If we average the graph, we arrive at an average transaction throughput of ~30-35 tx/s, which is as we would expect with 10 nodes performing as explained.
This effect is exaggerated in our test, as all nodes are doing verification, all nodes have a route to all other nodes, and there is low channel utilization. Therefore, all nodes need all new data for all channels immediately, as all nodes are verifying transactions for all channels. In a production environment, where verification is global, and spread over many many more nodes, these nodes will only need a very small portion of all channel data to service the transactions they are processing, thus upload saturation of nodes within any interconnected group will be much reduced.
With that in mind, the global transaction processing capability of the eMunie network will be very high indeed, as 10 nodes can process 30-35 tx/s average, and the scalar as the network grows should prove to be near linear, 1000 nodes could in theory process in excess of 20,000 tx/s globally.
That said, the peaks are real processing happening in the network as the graph is generated by countersigning time and not when the node received the transaction (take 2 graphs, from 2 nodes and they are identical).
So, as to the question, how fast is eMunie, there are 2 valid answers....in a 10 node test, 30-35tx/s if you take the average, 110tx/s if you take the peak. Which you choose is up to you, but I think you'll agree, either of those numbers, on commodity/consumer hardware, is mighty impressive
![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)