Lakshmipadmaja (Tue, 02 May 2017 05:00:39 GMT):
Has joined the channel.

arnuschky (Thu, 04 May 2017 15:29:45 GMT):
Has joined the channel.

arnuschky (Thu, 04 May 2017 15:37:29 GMT):
Has left the channel.

JonathanLevi (Sun, 07 May 2017 14:50:14 GMT):
Has joined the channel.

baohua (Sun, 07 May 2017 14:53:34 GMT):
Has joined the channel.

baohua (Sun, 07 May 2017 14:53:56 GMT):
hi i'm here :)

cbf (Sun, 07 May 2017 19:48:55 GMT):
Has joined the channel.

haridhakshini (Sun, 07 May 2017 20:02:04 GMT):
Has joined the channel.

nnao (Sun, 07 May 2017 20:58:08 GMT):
Has joined the channel.

himansri (Sun, 07 May 2017 21:27:21 GMT):
Has joined the channel.

YE.Yaocheng (Mon, 08 May 2017 02:21:07 GMT):
Has joined the channel.

Donald Liu (Mon, 08 May 2017 09:18:17 GMT):
Has joined the channel.

nkl199 (Mon, 08 May 2017 10:10:17 GMT):
Has joined the channel.

hmchen (Mon, 08 May 2017 12:20:28 GMT):
Has joined the channel.

JonathanLevi (Mon, 08 May 2017 14:13:52 GMT):
Ha ha. Likewise!

winsoft (Mon, 08 May 2017 14:53:34 GMT):
Has joined the channel.

ikocsis (Mon, 08 May 2017 16:42:29 GMT):
Has joined the channel.

judypriest (Mon, 08 May 2017 18:23:46 GMT):
Has joined the channel.

baohua (Thu, 11 May 2017 12:27:41 GMT):
good day!

dhuseby (Thu, 11 May 2017 14:14:35 GMT):
Has joined the channel.

nkl199 (Thu, 11 May 2017 14:39:30 GMT):
Hi all! Nick here - I'm working on Composer .... nice to be here :)

tiennv (Fri, 12 May 2017 17:18:59 GMT):
Has joined the channel.

KentLandholm (Sat, 13 May 2017 15:01:08 GMT):
Has joined the channel.

KentLandholm (Sat, 13 May 2017 15:03:34 GMT):
Greetings.

KentLandholm (Sat, 13 May 2017 15:05:02 GMT):
This was posted in #general. https://arxiv.org/pdf/1703.04057.pdf

KentLandholm (Wed, 17 May 2017 02:36:54 GMT):
any activity here?

nkl199 (Wed, 17 May 2017 05:28:56 GMT):
There appears to be a few "drop-in" messages, I think people may be waiting for an increase in activity before monitoring the channel more

baohua (Wed, 17 May 2017 05:50:30 GMT):
need to ref here: https://github.com/openstack/rally

turmewr3ck (Thu, 18 May 2017 07:48:19 GMT):
Has joined the channel.

Haojun (Fri, 19 May 2017 08:54:33 GMT):
Has joined the channel.

jkilpatr (Fri, 19 May 2017 14:19:04 GMT):
Has joined the channel.

samarcho (Fri, 19 May 2017 14:44:41 GMT):
Has joined the channel.

mwagner (Fri, 19 May 2017 17:47:19 GMT):
Its Fried Day!

thakkarparth007 (Sun, 21 May 2017 06:03:44 GMT):
Has joined the channel.

piotr.turu.turek (Sun, 21 May 2017 08:52:36 GMT):
Has joined the channel.

mwagner (Mon, 22 May 2017 14:17:54 GMT):
check your inbox....meeting on Wed

KentLandholm (Tue, 23 May 2017 17:15:17 GMT):
I must not have subscribed to a list or something.

mwagner (Tue, 23 May 2017 18:16:55 GMT):
hyperledger-perf-and-scale-wg@lists.hyperledger.org Mail went out the other day.

ikocsis (Tue, 23 May 2017 23:08:22 GMT):
Hi all, it is really good that this work is beginning... As a food for thought that is hopefully interesting to people here, here's an overview of research we did on fabric 0.6 (funded by a 2016 IBM Faculty Award, granted to Prof. Pataricza, my research group leader): https://drive.google.com/file/d/0B_R1w6XGVPqXYXAzYjJfTVFuLWs/view?usp=drivesdk We found interesting things - obviously the whole exercise should be repeated for fabric 1.0; but a (negative) result was that the whole activity is somewhat academic without broadly-accepted, Blockchain-specific performance concepts/metrics and representative workloads (aka a proper benchmark definition). And this seems to be pretty much in line with Mark's invitation to the telco, so I'm eager to hear about your view on performance and scalability today.

baohua (Wed, 24 May 2017 02:41:05 GMT):
interesting work @ikocsis , and i would like to suggest add the latency as perf indicator, as many real scenarios care about it. e.g., latency before the tx is broadcasted, latency before final commitment, etc..

baohua (Wed, 24 May 2017 02:41:05 GMT):
interesting work @ikocsis , and i would like to suggest add more latency analysis as the perf indicator, as many real scenarios care about it. e.g., latency before the tx is broadcasted, latency before final commitment, etc..

baohua (Wed, 24 May 2017 02:42:29 GMT):
And also, the gRPC part is NOT "surprisingly" slow :)

ikocsis (Wed, 24 May 2017 06:47:35 GMT):
Hmm... could you elaborate? We were (and still are) rather inexperienced in gRPC. That said, my expectation was that RPC should not have such an overhead, especially in scenarios where communication is essentially in-memory. We did play with the idea of properly tracing at least a few gRPC calls, but in the end did not have the time.

ikocsis (Wed, 24 May 2017 09:35:43 GMT):
Sorry, I failed to reply to the first part (I'm at a conference) @baohua , in my view the metrics you mentioned are super-important for performance analysis (and we definitely didn't have/had a full coverage) - but are essentially application-internal. Meaning that the clients (in the Hyperledger fabric sense) don't see them directly and most probably don't care about. What they see directly (for fabric 0.6 and with oversimplification) are a) the qualities of the synchronous operation of submitting a Tx request, b) the qualities of the asynchronous operation of fulfilling that request (or not). So my feeling is that the "service level performance and scalability metrics", if you like, should be treated separately from the "internal metrics". All the more so that the first group is what is potentially comparable across tools, configurations and tool versions.

baohua (Wed, 24 May 2017 13:01:03 GMT):
@ikocsis Thanks for ur reply, ikocis, yes, I understand your initial goals. I agree that we may separate those metrics into different folds, like from the end users's perspective, from the developers perspective. I guess you may know the flaming graph in the system perf area. While in the distributed system, what we may more care about is the network performance, rather than the node processing. Hence I would suggest we can also try to classify the metrics into like networking part (latency, throughput, etc.), node processing part (txs, time, etc.), and also the whole system part, to give people some full but quick picture on how well fabric would work :)

jsmitchell (Wed, 24 May 2017 13:32:33 GMT):
Has joined the channel.

jsmitchell (Wed, 24 May 2017 13:48:23 GMT):
https://arxiv.org/pdf/1703.04057.pdf

tkuhrt (Wed, 24 May 2017 13:55:29 GMT):
From Alexander Yakovlev https://docs.google.com/document/d/1oRD1HtI6R3Ew4ZiD_JS75u4sd5SLPcvgtqrhV5pM_gM/edit

tkuhrt (Wed, 24 May 2017 13:57:31 GMT):
Recording from today's meeting can be heard here: https://www.uberconference.com/getmp3/AMIfv94KyyOv6HIPwz5jCKijpQ3lh2vb6st_12iUkaaUshXWj1laNmJPKylczVo9iWiY3O-WnOsNi9WwqyBtrz1HLE7vgEFUz-_4xJSpQFCMvuVIbNOdNIIy7PhgH7csws5xXJW_t_fz27NUPAkNkWLINdZhrO2mUw.mp3

tkuhrt (Wed, 24 May 2017 13:57:52 GMT):
Chat transcript can be downloaded here: https://www.uberconference.com/chatdownload/5281950936465408

mwagner (Wed, 24 May 2017 14:43:54 GMT):
Thanks Tracy!

mwagner (Wed, 24 May 2017 14:44:05 GMT):
and thanks to all who joined

baohua (Thu, 25 May 2017 01:38:46 GMT):
sorry could not make it, seems we now have a good start!

davidoevans (Fri, 26 May 2017 01:12:52 GMT):
Has joined the channel.

tolak (Fri, 26 May 2017 02:02:57 GMT):
Has joined the channel.

Willson (Fri, 26 May 2017 02:11:57 GMT):
Has joined the channel.

hurf (Fri, 26 May 2017 02:43:59 GMT):
Has joined the channel.

harsha (Fri, 26 May 2017 03:23:58 GMT):
Has joined the channel.

xixuejia (Fri, 26 May 2017 03:25:37 GMT):
Has joined the channel.

bmkor (Fri, 26 May 2017 03:45:45 GMT):
Has joined the channel.

duwenhui (Fri, 26 May 2017 06:10:22 GMT):
Has joined the channel.

anik (Fri, 26 May 2017 06:23:36 GMT):
Has joined the channel.

silliman (Fri, 26 May 2017 13:24:09 GMT):
Has joined the channel.

MicBowman (Fri, 26 May 2017 20:30:57 GMT):
Has joined the channel.

mwagner (Thu, 01 Jun 2017 00:16:56 GMT):
hey, @tkuhrt sent an email with a link to the doodle page to help select a meeting time https://beta.doodle.com/poll/hcthgi9v45mmmsmu#calendar

baohua (Thu, 01 Jun 2017 02:11:44 GMT):
got thanks!

harsha (Thu, 01 Jun 2017 08:54:22 GMT):
Has left the channel.

jriachi (Fri, 02 Jun 2017 18:46:57 GMT):
Has joined the channel.

h4xr (Sat, 03 Jun 2017 06:56:04 GMT):
Has joined the channel.

harsha (Sat, 03 Jun 2017 14:56:39 GMT):
Has joined the channel.

tkuhrt (Mon, 05 Jun 2017 15:19:12 GMT):
Just a reminder...please complete the Doodle poll so that we can choose a time that meets the needs of most: https://beta.doodle.com/poll/hcthgi9v45mmmsmu#calendar

thakkarparth007 (Mon, 05 Jun 2017 15:24:14 GMT):
From when are the meetings expected to start?

danacr (Tue, 06 Jun 2017 13:06:30 GMT):
Has joined the channel.

paapighoda (Wed, 07 Jun 2017 06:09:09 GMT):
Has joined the channel.

KentLandholm (Wed, 07 Jun 2017 12:04:14 GMT):
Based on the calendar it looks like there is a meeting today. https://calendar.google.com/calendar/embed?src=linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0@group.calendar.google.com&pli=1

AlexYakovlev (Wed, 07 Jun 2017 12:33:25 GMT):
Has joined the channel.

AlexYakovlev (Wed, 07 Jun 2017 12:58:10 GMT):
@tkuhrt - will we have meeting today 1 hour later?

jtclark (Wed, 07 Jun 2017 13:07:24 GMT):
Has joined the channel.

tkuhrt (Wed, 07 Jun 2017 13:07:36 GMT):
@mwagner are you meeting today?

mwagner (Wed, 07 Jun 2017 14:12:58 GMT):
sorry, I thought that we were waiting for the results of the doodle poll

tkuhrt (Wed, 07 Jun 2017 23:12:10 GMT):
As of now, we have 13 responses (of the 49 people who have joined this channel). Of those, 9 people have agreed that TUE 9:00 AM – 10:00 AM Eastern works for them. Last call for people who want to participate in this poll: https://beta.doodle.com/poll/hcthgi9v45mmmsmu#calendar. @mwagner : should we close the poll at the end of the week, and set up bi-weekly calls starting next week?

mwagner (Thu, 08 Jun 2017 13:51:28 GMT):
@tkuhrt those were my thoughts as well. Can you send a final reminder ? Also if there is a "general" hyperledger email list can you cc that email list as well?

mwagner (Thu, 08 Jun 2017 13:51:30 GMT):
thanks

mwagner (Thu, 08 Jun 2017 13:52:07 GMT):
_needs to get rocketchat up at home :/_

PhDev (Fri, 09 Jun 2017 14:30:15 GMT):
Has joined the channel.

tkuhrt (Fri, 09 Jun 2017 16:01:03 GMT):
Just a reminder. We will be closing the poll today. If you have not yet completed the poll, today is your last chance. https://beta.doodle.com/poll/hcthgi9v45mmmsmu#calendar

ankashu (Fri, 09 Jun 2017 19:13:36 GMT):
Has joined the channel.

jrezwan (Sun, 11 Jun 2017 16:13:43 GMT):
Has joined the channel.

nhrishi (Mon, 12 Jun 2017 08:30:21 GMT):
Has joined the channel.

mwagner (Mon, 12 Jun 2017 17:45:12 GMT):
our next meeting will be Tues 20-June at 9AM EDT . full details on the mailing list

mwagner (Mon, 12 Jun 2017 17:45:39 GMT):
big thanks to @tkuhrt for setting up the doodlepoll and the meeting!

ianj_mitchell@uk.ibm.com (Tue, 13 Jun 2017 11:32:21 GMT):
Has joined the channel.

moriohara (Wed, 14 Jun 2017 05:11:08 GMT):
Has joined the channel.

mahesh_rao (Wed, 14 Jun 2017 13:20:53 GMT):
Has joined the channel.

mwagner (Wed, 14 Jun 2017 13:57:43 GMT):
CoinDesk just published an article on the Hyperledger Perf and Scale Working Group based on an interview I gave. http://www.coindesk.com/hyperledger-takes-on-blockchain-scaling-with-new-working-group/

mwagner (Wed, 14 Jun 2017 19:53:18 GMT):
cool, two people signed up after the CoinDesk article :)

mwagner (Wed, 14 Jun 2017 19:53:50 GMT):
in full disclosure I can say that is why until we ask them

mwagner (Wed, 14 Jun 2017 19:57:00 GMT):
s/can/can't/

naolduga (Wed, 14 Jun 2017 20:37:11 GMT):
Has joined the channel.

wsh_bob (Thu, 15 Jun 2017 01:09:04 GMT):
Has joined the channel.

pandabcai (Thu, 15 Jun 2017 01:57:11 GMT):
Has joined the channel.

pandabcai (Thu, 15 Jun 2017 01:57:58 GMT):
Hi everyone from Midea

danielleekc (Thu, 15 Jun 2017 04:24:04 GMT):
Has joined the channel.

LoveshHarchandani (Thu, 15 Jun 2017 12:33:12 GMT):
Has joined the channel.

baohua (Thu, 15 Jun 2017 13:56:05 GMT):
nice work, mark! @mwagner

mwagner (Thu, 15 Jun 2017 13:56:27 GMT):
@baohua thanks, just doing what I can

baohua (Thu, 15 Jun 2017 13:57:01 GMT):
and to @pandabcai welcome~

baohua (Thu, 15 Jun 2017 13:59:38 GMT):
now we got email-list, rocket channel, we need TSC to help vote the group charter and then add it to the wikipage.

mwagner (Thu, 15 Jun 2017 14:00:51 GMT):
I need to update the charter to have a broader scope as discussed in Washington

mwagner (Thu, 15 Jun 2017 14:01:36 GMT):
I unfortunately will not be in Beijing so I can't attend the F2F, can you appoint someone to take notes ?

mwagner (Thu, 15 Jun 2017 14:03:57 GMT):
Also, looking to move the call to the 27th since folks will be in Beijing and the meeting after that falls on July 4th which is a big US Holiday

baohua (Thu, 15 Jun 2017 14:24:05 GMT):
aha, understand.

baohua (Thu, 15 Jun 2017 14:24:54 GMT):
i will try to see if we can collect some comments for the pswg, and will post to the mail-list.

baohua (Thu, 15 Jun 2017 14:25:09 GMT):
timezone is definitely big problem for collaborations :)

baohua (Thu, 15 Jun 2017 14:25:31 GMT):
even we have so powerful internet...

mwagner (Thu, 15 Jun 2017 14:26:20 GMT):
yes, btw I can join a call to be involved in the Beijing discussions if that is feasible to get setup

baohua (Thu, 15 Jun 2017 14:27:55 GMT):
aha, this is good idea, i will see if we can have some hackfest call during the event, but i guess it's difficult to setup a call. a online chat might be possible. maybe we can use the #twg-china channel for the hackfest online discussions.

baohua (Thu, 15 Jun 2017 14:28:40 GMT):
by the way, is there any advice/question from ur side to be discussed?

sallyde (Fri, 16 Jun 2017 14:01:50 GMT):
Has joined the channel.

baohua (Mon, 19 Jun 2017 05:54:54 GMT):
@jiangyaoguo yaoguo, would u like to help summarize and post the discussions on the performance to the mail-list?

jiangyaoguo (Mon, 19 Jun 2017 05:54:55 GMT):
Has joined the channel.

baohua (Mon, 19 Jun 2017 05:54:56 GMT):
thanks

jiangyaoguo (Mon, 19 Jun 2017 06:38:43 GMT):
we havn't start the PSWG session yet. anyone want to join?

cliveb (Mon, 19 Jun 2017 20:10:07 GMT):
Has joined the channel.

daijianw (Tue, 20 Jun 2017 02:17:06 GMT):
Has joined the channel.

ikocsis (Tue, 20 Jun 2017 10:46:38 GMT):
Hi, @baohua - was a summary produced? Is it available? Thanks

ikocsis (Tue, 20 Jun 2017 10:47:49 GMT):
And I guess the next (i.e. second) call is on the 27-th, then?

baohua (Tue, 20 Jun 2017 11:26:49 GMT):
really quite lots of questions, mostly focus on the tps evaluation results on fabric and how to make a scale deployment for production scenarios.

ikocsis (Tue, 20 Jun 2017 11:59:19 GMT):
" mostly focus on the tps evaluation results on fabric and how to make a scale deployment for production scenarios" --> I would really appreciate some more detail, if possible, that's interesting for us, too (and I assume not all people looking to participate in the PSWG had the chance to attend in Beijing)

ikocsis (Tue, 20 Jun 2017 11:59:58 GMT):
and sorry for the question about the next meeting, I seem to have stopped receiving mails from the list weeks ago, really strange

tkuhrt (Tue, 20 Jun 2017 18:16:55 GMT):
@ikocsis : The next meeting for PSWG is on January 27th (9-10am EDT) at https://www.uberconference.com/hyperledger-community

mwagner (Tue, 20 Jun 2017 19:12:10 GMT):
@ikocsis not sure why you aren't getting emails, while the list is low volume at the moment, there have been multiple emails in the last week

mwagner (Tue, 20 Jun 2017 19:12:22 GMT):
perhaps you should sign up again ?

ikocsis (Tue, 20 Jun 2017 19:56:33 GMT):
@mwagner, thanks, already did that, received yesterday's digest - so it seems to work now, hopefully remains so.

ikocsis (Tue, 20 Jun 2017 20:12:17 GMT):
@tkuhrt: thanks! @mwagner: next Tuesday I hold a course, I asked a colleague of mine, László Gönczy to sit in for me this time. He's also involved in our Blockchain performance activities, teaches such stuff and is a Hyperledger Summer Internship mentor (https://wiki.hyperledger.org/internship/project_ideas, project 2).

baohua (Wed, 21 Jun 2017 06:27:18 GMT):
@ikocsis i understand, and i've also help announce the establishment at the hackfest, and encourage people to join the next meeting. I will try to present and share what i was asked and the thoughts.

paapighoda (Wed, 21 Jun 2017 08:07:31 GMT):
Has left the channel.

illya13 (Wed, 21 Jun 2017 11:55:25 GMT):
Has joined the channel.

chenxuan (Fri, 23 Jun 2017 04:43:25 GMT):
Has joined the channel.

tennenjl (Sun, 25 Jun 2017 14:19:23 GMT):
Has joined the channel.

tennenjl (Sun, 25 Jun 2017 14:22:13 GMT):
Hi, can anyone point me to some performance benchmark numbers for Hyperledger Fabric? I also am looking for any information regarding testing that is done where a large number of peers may be disconnected for an hour or more and then brought back on line.

zuowang (Mon, 26 Jun 2017 07:31:13 GMT):
Has joined the channel.

Ashish (Mon, 26 Jun 2017 09:24:52 GMT):
Has joined the channel.

mwagner (Mon, 26 Jun 2017 14:06:51 GMT):
@tennenjl there is this paper but it is based on Fabric 0.6 https://arxiv.org/pdf/1703.04057.pdf

tennenjl (Mon, 26 Jun 2017 14:07:43 GMT):
@mwagner Thanks, even if this is 0.6 it's better than anything I have now. :-)

mwagner (Mon, 26 Jun 2017 14:09:24 GMT):
As a reminder to all we are holding the PSWG meeting Tues, 9AM EDT (US Eastern time), I will get an agenda out shortly

peter.kalambet (Mon, 26 Jun 2017 14:17:22 GMT):
Has joined the channel.

chenxuan (Tue, 27 Jun 2017 07:46:57 GMT):
Transactions: 50000 hits Availability: 100.00 % Elapsed time: 1204.94 secs Data transferred: 5.96 MB Response time: 11.14 secs Transaction rate: 41.50 trans/sec Throughput: 0.00 MB/sec Concurrency: 462.36 Successful transactions: 50000 Failed transactions: 0 Longest transaction: 52.20 Shortest transaction: 0.05

raasiel (Tue, 27 Jun 2017 12:11:39 GMT):
Has joined the channel.

mwagner (Tue, 27 Jun 2017 12:15:31 GMT):
00tBa!!

mwagner (Tue, 27 Jun 2017 12:15:44 GMT):
hmm, that didn't go well

mwagner (Tue, 27 Jun 2017 12:16:16 GMT):
@chenxuan what did you use for that test ?

thakkarparth007 (Tue, 27 Jun 2017 12:55:09 GMT):
When is the meeting starting?

thakkarparth007 (Tue, 27 Jun 2017 12:55:18 GMT):
In about 5min, right?

thakkarparth007 (Tue, 27 Jun 2017 12:55:31 GMT):
How do we join?

baohua (Tue, 27 Jun 2017 13:13:12 GMT):
@thakkarparth007 https://www.uberconference.com/hyperledger-community

thakkarparth007 (Tue, 27 Jun 2017 13:14:25 GMT):
Thanks, I joined a while back.

mwagner (Tue, 27 Jun 2017 13:57:11 GMT):
thanks everyone!

LoveshHarchandani (Tue, 27 Jun 2017 14:10:54 GMT):
@chenxuan What kind of orderer were you using?

chenxuan (Tue, 27 Jun 2017 14:11:04 GMT):
kafka

LoveshHarchandani (Tue, 27 Jun 2017 14:11:09 GMT):
Thanks

LoveshHarchandani (Tue, 27 Jun 2017 14:13:45 GMT):
@chenxuan What were the number of peers (endorsers and orderers) for these transactions

chenxuan (Tue, 27 Jun 2017 14:14:18 GMT):
2 peer 1 orderer base on the kafka

chenxuan (Tue, 27 Jun 2017 14:14:27 GMT):
the kafka is fake cluster

tkuhrt (Tue, 27 Jun 2017 18:16:39 GMT):
Meeting recordings can be found here: https://drive.google.com/open?id=0B_NJV6eJXAA1RHNnY2drSWpZcFU

tkuhrt (Tue, 27 Jun 2017 18:16:52 GMT):

mwagner (Tue, 27 Jun 2017 19:04:29 GMT):
@tkuhrt Thanks!

tennenjl (Thu, 29 Jun 2017 00:47:34 GMT):
Hi Team, have we done any testing where a large number of peers are in disconnected mode for an extended period of time.

rezamt (Thu, 29 Jun 2017 04:27:20 GMT):
Has joined the channel.

dklesev (Mon, 03 Jul 2017 19:39:53 GMT):
Has joined the channel.

dklesev (Tue, 04 Jul 2017 02:32:55 GMT):
just found this: http://www.diva-portal.org/smash/get/diva2:1111497/FULLTEXT01.pdf

KentLandholm (Sat, 08 Jul 2017 10:56:08 GMT):
blockchain benchmark info - red belly -----http://www.zdnet.com/article/university-of-sydney-builds-new-red-belly-blockchain-technology/

chenxuan (Sun, 09 Jul 2017 03:27:45 GMT):
Lifting the server siege... Transactions: 1110 hits Availability: 100.00 % Elapsed time: 21.44 secs Data transferred: 0.06 MB Response time: 3.32 secs Transaction rate: 51.77 trans/sec Throughput: 0.00 MB/sec Concurrency: 171.97 Successful transactions: 1110 Failed transactions: 0 Longest transaction: 4.07 Shortest transaction: 0.68

chenxuan (Sun, 09 Jul 2017 03:27:48 GMT):
the tps

chenxuan (Sun, 09 Jul 2017 03:27:51 GMT):
is very low

chenxuan (Mon, 10 Jul 2017 08:35:53 GMT):
hi everyone

chenxuan (Mon, 10 Jul 2017 08:36:05 GMT):
i use the PTE to test the tps

chenxuan (Mon, 10 Jul 2017 08:36:12 GMT):
it show the error

chenxuan (Mon, 10 Jul 2017 08:36:22 GMT):
info: [PTE main]: stderr: (node:31449) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TypeError: Cannot read property 'url' of undefined info: [PTE main]: stderr: error: [Orderer.js]: sendDeliver - rejecting - status:NOT_FOUN

chenxuan (Mon, 10 Jul 2017 08:36:37 GMT):
someone occur the question

chenxuan (Mon, 10 Jul 2017 08:50:48 GMT):

Message Attachments

pvrbharg (Mon, 10 Jul 2017 14:16:11 GMT):
Has joined the channel.

PraveenPandu (Mon, 10 Jul 2017 16:13:46 GMT):
Has joined the channel.

tennenjl (Mon, 10 Jul 2017 19:15:12 GMT):
Hi, Has there been any testing or implementations with a larger number of peers (has anyone done anything with more than ten peers that contain ledgers?) Thanks for any feedback!

mwagner (Tue, 11 Jul 2017 12:31:36 GMT):
reminder, meeting in 30 minutes - what do people want to discuss today ?

mwagner (Tue, 11 Jul 2017 12:33:30 GMT):
https://calendar.google.com/calendar/embed?src=linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0%40group.calendar.google.com&ctz=US/Arizona

LoveshHarchandani (Tue, 11 Jul 2017 13:09:11 GMT):
The whitepaper RedBelly's website's consensus section redirects to http://poseidon.it.usyd.edu.au/~concurrentsystems/doc/ConsensusRedBellyBlockchain.pdf

LoveshHarchandani (Tue, 11 Jul 2017 13:09:33 GMT):
This is the website btw

LoveshHarchandani (Tue, 11 Jul 2017 13:09:34 GMT):
http://poseidon.it.usyd.edu.au/~concurrentsystems/rbbc/index.html

qizhang (Tue, 11 Jul 2017 18:31:44 GMT):
Has joined the channel.

qizhang (Tue, 11 Jul 2017 18:48:15 GMT):
Hi, has anyone used this benchmark https://github.com/dongmingh/v1performance?

chenxuan (Tue, 11 Jul 2017 23:28:51 GMT):
@qizhang i use.it

qizhang (Wed, 12 Jul 2017 01:31:39 GMT):
@chenxuan Nice. Can you please let me know what is the throughput you get from this benchmark?

gen_el (Wed, 12 Jul 2017 12:55:08 GMT):
Has joined the channel.

whathewatt (Wed, 12 Jul 2017 13:41:38 GMT):
Has joined the channel.

thakkarparth007 (Thu, 13 Jul 2017 14:15:49 GMT):
Can someone post recording/minutes of the last meeting?

tkuhrt (Thu, 13 Jul 2017 15:51:38 GMT):
All meeting recordings can be found in the following directory: https://drive.google.com/drive/folders/0B_NJV6eJXAA1RHNnY2drSWpZcFU?usp=sharing

thakkarparth007 (Thu, 13 Jul 2017 16:27:39 GMT):
Thanks!

zhangchao (Mon, 17 Jul 2017 14:44:31 GMT):
Has joined the channel.

highlander (Tue, 18 Jul 2017 20:28:57 GMT):
Has joined the channel.

Senthil1 (Wed, 19 Jul 2017 07:59:23 GMT):
Has joined the channel.

warm3snow (Fri, 21 Jul 2017 06:42:27 GMT):
Has joined the channel.

tallharish (Sun, 23 Jul 2017 19:37:23 GMT):
Has joined the channel.

grapebaba (Mon, 24 Jul 2017 03:52:21 GMT):
Has joined the channel.

mwagner (Mon, 24 Jul 2017 13:44:11 GMT):
any special topics people want to cover in Tues call ?

vu3mmg (Tue, 25 Jul 2017 03:47:55 GMT):
Has joined the channel.

mwagner (Wed, 26 Jul 2017 15:00:52 GMT):
PSWG members vote on proposed charter ongoing via email. please check your inbox

albrandt (Thu, 27 Jul 2017 16:47:35 GMT):
Has joined the channel.

sidrmsh (Tue, 01 Aug 2017 16:10:59 GMT):
Has joined the channel.

dklesev (Fri, 04 Aug 2017 02:28:05 GMT):
can someone help me out with PTE (https://github.com/dongmingh/v1performance)? even after following the README I get errors... https://pastebin.com/9ibsTspL

rojanjose (Mon, 07 Aug 2017 15:04:08 GMT):
Has joined the channel.

guoger (Tue, 08 Aug 2017 13:47:10 GMT):
Has joined the channel.

binhn (Wed, 09 Aug 2017 12:45:33 GMT):
Has joined the channel.

binhn (Wed, 09 Aug 2017 12:56:36 GMT):
@dklesev if you still looking for help, you might want to post on #fabric-quality channel

mwagner (Thu, 10 Aug 2017 11:58:24 GMT):
based on feedback, I made some additional changes to the proposed charter. please check your email.

baohua (Wed, 16 Aug 2017 03:44:35 GMT):
Hope can finalize on this weeks' TSC meeting.

Ratnakar (Thu, 17 Aug 2017 23:54:07 GMT):
Has joined the channel.

grapebaba (Sat, 19 Aug 2017 07:34:45 GMT):
does it exist a guide for production server capability such cpu, memory, storage for peer, orderer,ca?

danielleekc (Mon, 21 Aug 2017 04:16:37 GMT):
Has left the channel.

baohua (Mon, 21 Aug 2017 07:25:12 GMT):
as far as i know, there's no official one yet.

baohua (Tue, 22 Aug 2017 13:51:44 GMT):
If the meeting is regular now, we may put it on the wiki: https://wiki.hyperledger.org/groups/pswg/performance-and-scale-wg

baohua (Tue, 22 Aug 2017 13:52:12 GMT):
Currently, there's no date/time info. @mwagner

tkuhrt (Tue, 22 Aug 2017 19:44:45 GMT):
@baohua : Added details to the wiki.

recurrence (Tue, 22 Aug 2017 20:10:16 GMT):
Has joined the channel.

baohua (Wed, 23 Aug 2017 01:55:56 GMT):
thanks tkuhrt!

mwagner (Wed, 23 Aug 2017 13:22:07 GMT):
sorry i missed yesterdays meeting. I was at the oral surgeon having two teeth removed. What was covered in the meeting ?

ikocsis (Wed, 23 Aug 2017 13:40:49 GMT):
Hi Mark

ikocsis (Wed, 23 Aug 2017 13:41:06 GMT):
sorry to hear about your teeth, best wishes

ikocsis (Wed, 23 Aug 2017 13:41:39 GMT):
Marta Piekarska was in the call to check in on the WG

ikocsis (Wed, 23 Aug 2017 13:42:08 GMT):
The Caliper guys presented their proposal again (many, including me, were not present last time)

ikocsis (Wed, 23 Aug 2017 13:43:03 GMT):
Marta directed them towards the Requirements WG, where representative use cases are supposedly coming along nicely

ikocsis (Wed, 23 Aug 2017 13:43:35 GMT):
Kent (?) and Alex (?) were also there

ikocsis (Wed, 23 Aug 2017 13:44:13 GMT):
The Caliper guys basically asked for the results of this WG so that they can incorporate them in their tool

ikocsis (Wed, 23 Aug 2017 13:45:07 GMT):
I suggested to them to share what they have as a metric-set set now and promised to share my personal very rough draft (see my mail to the list)

ikocsis (Wed, 23 Aug 2017 13:45:52 GMT):
It came up whether we should begin to discuss the dictionary, but there was no sense to do that in the remaining 10 minutes

ikocsis (Wed, 23 Aug 2017 13:46:02 GMT):
Basically this

ikocsis (Wed, 23 Aug 2017 13:48:10 GMT):
My personal opinion: it's very good that Caliper is being developed (we may have a student who will begin to kick its tires in a few weeks), but the lines between the PSWG and Caliper seem to be rather blurry

ikocsis (Wed, 23 Aug 2017 13:51:02 GMT):
I had a look at the PSWG dictionary document and will share my (uninvited) view on it (again) in a few minutes. There are some good things in there, but in my opinion this should be definitely discussed next time (maybe even earlier?).

ikocsis (Wed, 23 Aug 2017 13:52:24 GMT):
Also: Marta and the Caliper guys talked about a face to face between them and the req guys (and also for PSWG? sorry, I don't remember) in Chicago.

mwagner (Wed, 23 Aug 2017 14:55:07 GMT):
thanks! btw you comments on the dictionary are not only invited but encouraged!

ikocsis (Wed, 23 Aug 2017 15:02:23 GMT):
ok, thanks :)

ikocsis (Wed, 23 Aug 2017 15:05:13 GMT):
Hopefully, the Caliper guys will also share something, although they didn't really commit themselves

ikocsis (Wed, 23 Aug 2017 15:07:35 GMT):
And I went through the little available material on Blockchain benchmarking - no classic metric/quality aspect analysis anywhere (although from the software point of view, some impressive contributions)

ikocsis (Wed, 23 Aug 2017 15:07:36 GMT):
So one question: do you/we have any "representative" use cases by now?

Ricardo-Neisse (Thu, 24 Aug 2017 13:28:03 GMT):
Has joined the channel.

dongming (Fri, 25 Aug 2017 16:20:59 GMT):
Has joined the channel.

Haojun (Sat, 26 Aug 2017 02:42:43 GMT):
Hi ikocsis, in fact we have already added some definitions in the dictionary directly, not using comments. Please check version on Aug 23 :grinning:

Haojun (Sat, 26 Aug 2017 02:56:44 GMT):
As discussed on the TSC meeting, Caliper should only provide tools, no test results should be provided in the project as official testing. And the definition of performance metrics and use cases should be discussed in PSWG, that helps us to focus our discussion in one place. So Caliper now mainly focuses on the developing of the architecture and functionality, integrating more blockchain systems, etc, and we will continues to contribute to the PSWG. I hope that would help to clarify the line between the PSWG and Caliper .

mwagner (Mon, 28 Aug 2017 13:29:01 GMT):
@Haojun How can I become more involved with Caliper ?

ikocsis (Mon, 28 Aug 2017 16:11:41 GMT):
Hi Haojun, thanks for the clarification, for whatever reason my impression was slightly different based on my skim of the project proposal document. Regarding version august 23: I think I even commented on that part.

ikocsis (Mon, 28 Aug 2017 16:18:24 GMT):
@mwagner : I stumbled upon this today: http://www.chainthat.com/updates/2017/7/5/using-hyperledger-fabric-v1-in-reinsurance I don't know whether they are already involved in the work of the requirements WG. It could be a good idea to reach out to them whether they want to/could support PSWG with their use case. Their solution seems to be at least reasonably mature and publishing that shows openness.

Haojun (Tue, 29 Aug 2017 01:33:45 GMT):
@mwagner Currently, you can create github issues if you have any comments, ideas or bug fixes. If the project is approved, we could start a new rocket channel. Anyway, you can always reach me by email .

VipinB (Wed, 30 Aug 2017 18:50:42 GMT):
Has joined the channel.

lovesh (Thu, 31 Aug 2017 15:45:44 GMT):
Has joined the channel.

jworthington (Fri, 01 Sep 2017 09:47:54 GMT):
Has joined the channel.

lmrln (Fri, 01 Sep 2017 10:10:14 GMT):
Has joined the channel.

ArnabChatterjee (Mon, 04 Sep 2017 00:51:25 GMT):
Has joined the channel.

dinesh.rivankar (Mon, 04 Sep 2017 04:05:22 GMT):
Has joined the channel.

dinesh.rivankar (Mon, 04 Sep 2017 09:44:16 GMT):
any 1 using caliper ..... getting undefined for var fabric = Client.getConfigSetting('fabric');

dinesh.rivankar (Mon, 04 Sep 2017 09:44:16 GMT):
Client.addConfigFile(config_path); console.log(config_path); // /caliper/benchmark/simple/fabric.json var fabric = Client.getConfigSetting('fabric'); // this returns null fabric var return null

ynkumar143 (Mon, 04 Sep 2017 12:00:03 GMT):
Has joined the channel.

ynkumar143 (Mon, 04 Sep 2017 12:01:21 GMT):
I am interested to know the performance of Fabric v1.0 in real time production system?

ynkumar143 (Mon, 04 Sep 2017 12:01:30 GMT):
can anyone please help on this.

dinesh.rivankar (Tue, 05 Sep 2017 05:09:26 GMT):
Test results for Hyperledger v1.0 with 4 peer network on single VM useing Cliper framework. Are this results correct? +------+-------+------+------+-----------+-----------+-----------+-----------+----------------+----------------+----------------+ | Test | OPT | Succ | Fail | Send Rate | Max Delay | Min Delay | Avg Delay | Max Throughput | Min Throughput | Avg Throughput | |------|-------|------|------|-----------|-----------|-----------|-----------|----------------|----------------|----------------| | 0 | open | 4994 | 6 | 98 tps | 84.53 s | 1.71 s | 51.00 s | 311 tps | 1 tps | 52 tps | |------|-------|------|------|-----------|-----------|-----------|-----------|----------------|----------------|----------------| | 1 | query | 5000 | 0 | 97 tps | 2.25 s | 0.01 s | 0.20 s | 199 tps | 14 tps | 99 tps | +------+-------+------+------+-----------+-----------+-----------+-----------+----------------+----------------+----------------+ ### Resource stats (maximum) ### +-----------------------------------+-----------------------------------+-------------+----------+------------+-------------+ | ID | NAME | Memory(max) | CPU(max) | Traffic In | Traffic Out | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | fa51436f87519428f32895f99...6a110 | dev-peer0.org1.example.co...le-v0 | 6.3MB | 7.96% | 5.6MB | 1.6MB | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | 09693983cd1d8369b76938132...8a11d | dev-peer1.org2.example.co...le-v0 | 5.5MB | 5.80% | 5.6MB | 1.5MB | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | 8a44ef4761d8510716e177d01...2c84b | dev-peer1.org1.example.co...le-v0 | 5.4MB | 3.41% | 3.2MB | 1.1MB | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | 288117e7e7565c47df22851d8...34e92 | dev-peer0.org2.example.co...le-v0 | 12.4MB | 9.14% | 6.2MB | 2.1MB | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | 7f39f0f071799851aea657a05...02e42 | peer1.org1.example.com | 154.1MB | 43.38% | 22.6MB | 13.9MB | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | 53b84ce6840ed728f14fdae12...fa63e | peer1.org2.example.com | 151.0MB | 44.23% | 20.6MB | 10.8MB | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | 3cdbd017cced8a6972f5f6c89...aab03 | peer0.org2.example.com | 212.9MB | 99.33% | 26.8MB | 48.4MB | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | a1a32c526823264d97eb741e8...a0c46 | peer0.org1.example.com | 176.4MB | 64.69% | 25.4MB | 62.1MB | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | 7dc9c4a062e02f3e5b55f877f...8572f | ca_peerOrg2 | 4.5MB | 0.00% | 5.0KB | 0B | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | 597cd6d8b652375706f47a2f2...a282a | orderer.example.com | 145.1MB | 46.24% | 21.3MB | 77.0MB | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | 244c10c28f73db33643ea0d20...bb01f | couchdb | 60.4MB | 3.86% | 5.0KB | 0B | |-----------------------------------|-----------------------------------|-------------|----------|------------|-------------| | ee5a2bfbcb8a781b2cce107e3...2b93f | ca_peerOrg1 | 4.5MB | 0.01% | 5.0KB | 0B | +-----------------------------------+-----------------------------------+-------------+----------+------------+-------------+

dinesh.rivankar (Tue, 05 Sep 2017 05:12:28 GMT):

Message Attachments

Haojun (Tue, 05 Sep 2017 05:46:16 GMT):
it seems you limited the send rate to 100 tps, you can try to improve the number until the avg throughput reaches the upper limit

dinesh.rivankar (Tue, 05 Sep 2017 06:07:14 GMT):
Thanks @Haojun... Should we do this test on different distributed systems or on a single system using docker ? Also when we have different combination of send rate the code breaks with error: Invoke chaincode failed, Error: Failed to send Proposal or receive valid response. Response null or status is not 200. exiting... at channel.sendTransactionProposal.then (/caliper/src/fabric/e2eUtils.js:614:10)

dinesh.rivankar (Tue, 05 Sep 2017 06:07:14 GMT):
Thanks @Haojun ... Should we do this test on different distributed systems or on a single system using docker ? Also when we have different combination of send rate the code breaks with error: Invoke chaincode failed, Error: Failed to send Proposal or receive valid response. Response null or status is not 200. exiting... at channel.sendTransactionProposal.then (/caliper/src/fabric/e2eUtils.js:614:10)

Haojun (Tue, 05 Sep 2017 06:24:40 GMT):
That depends on your test purpose. A distributed systems should get better performance result than deploying all peers on the same host. Could you send me your configuration file @dinesh.rivankar ? It seems the proposal is rejected by endorsers.

Haojun (Tue, 05 Sep 2017 06:37:02 GMT):
Another possibility is that the client did not get the response in time (there is a 60s timeout for request). How many clients are you using? Check the cpu percentage of node process, if it's too high, try to add more clients

dinesh.rivankar (Tue, 05 Sep 2017 06:51:20 GMT):

Message Attachments

dinesh.rivankar (Tue, 05 Sep 2017 06:51:34 GMT):

Message Attachments

Haojun (Tue, 05 Sep 2017 07:27:37 GMT):
@dinesh.rivankar I can not reproduce the failure...... so 1. use 'top' to check if the node process is too busy as i suggested before. If your vm is too limited to run all the clients and fabric peers, try to test on a distributed system. I guess that's the main problem. 2. you can try to increase the 'request-timeout' value, which is in the first line of getcontext function in e2eUtils.js line 393 3. there is a bug to handle the error message which caused the query test failed when querying a nonexistent item. Thanks for the test. I will fix it later, you can create a issue on github if you want

dinesh.rivankar (Tue, 05 Sep 2017 08:20:56 GMT):
@Haojun Thanks for the response. will try on different distributed systems.

jsmitchell (Tue, 05 Sep 2017 21:09:48 GMT):
are meeting minutes posted anywhere?

tkuhrt (Tue, 05 Sep 2017 21:33:06 GMT):
@jsmitchell : Recordings are captured here: https://drive.google.com/open?id=0B_NJV6eJXAA1RHNnY2drSWpZcFU

jsmitchell (Tue, 05 Sep 2017 21:33:44 GMT):
thanks tracy! I was wondering if anyone was summarizing minutes.

tkuhrt (Tue, 05 Sep 2017 21:39:46 GMT):
Not that I am aware of

tkuhrt (Tue, 05 Sep 2017 21:40:09 GMT):
Hopefully someone hear will surprise us

tkuhrt (Tue, 05 Sep 2017 21:40:09 GMT):
Hopefully someone here will surprise us

smith (Wed, 06 Sep 2017 02:52:07 GMT):
Has joined the channel.

moriohara (Thu, 07 Sep 2017 13:28:03 GMT):
FYI: The ECB (European Central Bank) and the BOJ (Bank of Japan) jointly published a performance report on Hyperledger Fabric V0.6 for their use cases at http://www.boj.or.jp/en/announcements/release_2017/rel170906a.htm. This may be useful for us to define performance metrics.

niteshsolanki (Fri, 08 Sep 2017 04:28:48 GMT):
Has joined the channel.

niteshsolanki (Fri, 08 Sep 2017 04:31:43 GMT):
Hi @Haojun , i am trying to run the caliper benchmark test. I have set up 4 different peers on 4 separate VM's in docker containers. I am not able to monitor the stats for remote docker containers. Getting following error: "Failed to read monitoring data".

Haojun (Fri, 08 Sep 2017 05:59:37 GMT):
@niteshsolanki , how do you define the container in the configuration file? Can you fetch the remote container's data using curl? Docker Remote API must be enabled with those docker service, which is usually disabled by default.

niteshsolanki (Fri, 08 Sep 2017 06:00:22 GMT):
@Haojun it worked now :-) i was not specifying the correct container ID. thanks for response

Haojun (Fri, 08 Sep 2017 06:01:22 GMT):
@niteshsolanki great, you are welcome

niteshsolanki (Fri, 08 Sep 2017 06:04:04 GMT):
Hey @Haojun. i would like to share the results of experiments we performed on 4 VMs with 8 GB ram and 2 CPU.

niteshsolanki (Fri, 08 Sep 2017 06:04:04 GMT):

Message Attachments

niteshsolanki (Fri, 08 Sep 2017 06:04:56 GMT):
can u give us some feedbacks on it.

niteshsolanki (Fri, 08 Sep 2017 06:04:56 GMT):
can u pls give us some feedbacks on it.

harsha (Mon, 11 Sep 2017 09:16:30 GMT):
@niteshsolanki : when you say you performed experiments, what was the nature of those experiments ? How many peer/orderer/fabric-ca container(s) did you have in your setup ...

niteshsolanki (Mon, 11 Sep 2017 09:18:32 GMT):
@harsha 4 peers, 1 orderer, 2 CAs

harsha (Mon, 11 Sep 2017 09:19:15 GMT):
And nature of experiments as in e2e-cli or something else /

niteshsolanki (Mon, 11 Sep 2017 09:20:15 GMT):
can u pls ellaborate?

harsha (Mon, 11 Sep 2017 09:21:03 GMT):
Did you run any transactions on top of your blockchain network ?

niteshsolanki (Mon, 11 Sep 2017 09:24:57 GMT):
ofcourse

slender (Tue, 12 Sep 2017 03:04:21 GMT):
Has joined the channel.

zachary.singh (Tue, 12 Sep 2017 16:37:23 GMT):
Has joined the channel.

zachary.singh (Tue, 12 Sep 2017 17:48:39 GMT):
Hi everyone, I am new to hyperledger and had some performance related questions I am hoping you can answer or point me in the right direction. My first question is what is the complexity of reading blocks from the blockchain. My second question is if the structure of chaining blocks or grouping them into channels provide faster access to the underlying data. Any guidance is appreciated!

hanhzf (Wed, 13 Sep 2017 01:25:11 GMT):
Has joined the channel.

idpattison (Thu, 14 Sep 2017 16:09:26 GMT):
Has joined the channel.

msoumeit (Sun, 17 Sep 2017 12:24:25 GMT):
Has joined the channel.

scottz (Mon, 18 Sep 2017 15:32:13 GMT):
Has joined the channel.

thakkarparth007 (Mon, 18 Sep 2017 16:49:45 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=5iZPCMczPPxj52ctC) @niteshsolanki What do you mean by request/sec and transactions per second?

niteshsolanki (Tue, 19 Sep 2017 09:03:47 GMT):
@thakkarparth007 request/s= rate at which the transactions were sent by client per sec tx/s= number of transactions that got committed successfully per sec

mwagner (Tue, 19 Sep 2017 14:03:15 GMT):
Great discussion today folks! Thanks

guyho (Thu, 21 Sep 2017 13:54:07 GMT):
Has joined the channel.

guyho (Thu, 21 Sep 2017 16:31:31 GMT):
Hi folks - just joined this chat. I'm with R3 and would truly like to participate in this WG. My hope is that you would encourage R3 participation. Beyond this Rocket.chat, how best to plug-in to this wg? There's mention of an email distr list that I imagine might be used for calendar invites, etc.

danconway (Thu, 21 Sep 2017 19:04:51 GMT):
Has joined the channel.

tkuhrt (Thu, 21 Sep 2017 20:06:35 GMT):
@guyho : Welcome. Check out this Wiki page: https://wiki.hyperledger.org/groups/pswg/performance-and-scale-wg

tkuhrt (Thu, 21 Sep 2017 20:06:47 GMT):
It has information about the meetings and the mailing lists

tkuhrt (Thu, 21 Sep 2017 20:08:46 GMT):
Performance and Scalability Working Group

tkuhrt (Thu, 21 Sep 2017 20:08:57 GMT):
For additional information on this working group, see: https://wiki.hyperledger.org/groups/pswg/performance-and-scale-wg

guyho (Thu, 21 Sep 2017 21:30:31 GMT):
Got it! Thanks! Just subscribed.

marcioamr (Fri, 29 Sep 2017 10:06:47 GMT):
Has joined the channel.

marcioamr (Fri, 29 Sep 2017 11:26:52 GMT):
is anyone knows of any Hyperledger Fabric 1.0 network in production that performs more than 1000 per second?

vu3mmg (Tue, 03 Oct 2017 11:30:36 GMT):
Could you please help me in getting some metrics for hyperledger V1

Dan (Tue, 03 Oct 2017 14:59:13 GMT):
Has joined the channel.

nkl199 (Wed, 04 Oct 2017 15:08:00 GMT):
I've been using Caliper and had some really good output/results. You can also use PTE, which is within the Fabric git repositories

nkl199 (Thu, 05 Oct 2017 07:23:34 GMT):
https://github.com/Huawei-OSG/caliper and https://github.com/hyperledger/fabric/tree/release/test/tools/PTE

dongming (Thu, 05 Oct 2017 13:05:06 GMT):
PTE is moved to https://github.com/hyperledger/fabric-test, under directory tools/PTE

toddinpal (Thu, 05 Oct 2017 22:13:27 GMT):
Has joined the channel.

qiang0723 (Mon, 09 Oct 2017 04:19:11 GMT):
Has joined the channel.

nharshita (Tue, 10 Oct 2017 10:13:25 GMT):
Has joined the channel.

udaykhambadkone (Fri, 13 Oct 2017 12:51:13 GMT):
Has joined the channel.

guyho (Mon, 16 Oct 2017 19:50:06 GMT):

PerfConsidersForDLT_V0.01.docx

mwagner (Tue, 17 Oct 2017 12:24:14 GMT):
reminder perf/scale call in 35 minutes

cre8bidio (Tue, 17 Oct 2017 13:59:53 GMT):
Has joined the channel.

shuaili87 (Fri, 20 Oct 2017 08:11:49 GMT):
Has joined the channel.

Jay (Mon, 23 Oct 2017 09:28:26 GMT):
Has joined the channel.

VipinB (Mon, 23 Oct 2017 19:08:16 GMT):
@mwagner We have a call tomorrow?

VipinB (Mon, 23 Oct 2017 19:12:06 GMT):
I see that we have, looking through mailinglist archive as I don't get emails from the list

VipinB (Mon, 23 Oct 2017 19:12:26 GMT):
@mwagner - don't need to answer

FiratSertgoz (Thu, 26 Oct 2017 12:36:37 GMT):
Has joined the channel.

meridian (Sat, 28 Oct 2017 13:56:37 GMT):
Has joined the channel.

meridian (Sat, 28 Oct 2017 13:56:54 GMT):
hello, how can we submit proposals ?

swangbj (Mon, 30 Oct 2017 08:30:20 GMT):
Has joined the channel.

ornit17 (Mon, 30 Oct 2017 13:33:02 GMT):
Has joined the channel.

mwagner (Mon, 30 Oct 2017 17:06:55 GMT):
@meridan , not sure what you mean. If its perf and scale related you can send it to the mailing list.

tkuhrt (Mon, 30 Oct 2017 19:55:23 GMT):
https://lists.hyperledger.org/mailman/listinfo/hyperledger-perf-and-scale-wg

divyank (Thu, 02 Nov 2017 13:47:29 GMT):
Has joined the channel.

grapebaba (Fri, 03 Nov 2017 04:15:46 GMT):
@hereI am working on fabric metrics task https://jira.hyperledger.org/browse/FAB-3388, several metrics defined but still a little, would you guys like define whole picture what metrics need collected and add some comments there?

jexek (Fri, 03 Nov 2017 09:40:34 GMT):
Has joined the channel.

bennettneale (Fri, 03 Nov 2017 16:27:01 GMT):
Has joined the channel.

as93717913 (Mon, 06 Nov 2017 16:11:44 GMT):
Has joined the channel.

mwagner (Mon, 06 Nov 2017 19:17:13 GMT):
Reminder, no meeting this week due to members summit and travel needs

JosephChang (Mon, 06 Nov 2017 23:47:19 GMT):
Has joined the channel.

kedarr (Fri, 10 Nov 2017 14:13:05 GMT):
Has joined the channel.

mwagner (Tue, 14 Nov 2017 14:03:05 GMT):
forgot to send email but the perf and scale call is happening now

VipinB (Wed, 15 Nov 2017 14:50:54 GMT):
@mwagner, apologies was not able to attend. However I had met with @guyho to talk about PSWG and hopefully he was present on the meeting

VipinB (Wed, 15 Nov 2017 14:51:41 GMT):
@mwagner/ others- please attend Identity WG- full agenda etc. on the channel and in mailing list

Pardha (Fri, 17 Nov 2017 13:02:02 GMT):
Has joined the channel.

dante (Sun, 19 Nov 2017 03:30:03 GMT):
Has joined the channel.

moriohara (Tue, 21 Nov 2017 14:18:24 GMT):
Hello, do we have a call today? I do not see anyone online yet.

mwagner (Tue, 21 Nov 2017 14:44:35 GMT):
@moriohara we tried to have a call but there only 5 of us so we decided to cancel at 10 past the hour

moriohara (Tue, 21 Nov 2017 14:46:41 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=L4coHeKR6rturyWDh) @mwagner I see. I joined late because my previous meeting was extended. Sorry about it. Anyway, hope to talk to you next week.

FiratSertgoz (Wed, 22 Nov 2017 09:53:01 GMT):
Hello, I have been conducting scalability tests on Hyperledger Fabric 1.0.3 where I try to define how TPS and time spent on certain components in the network differ as I increase the number of endorsers. I have came up with some results until now, however there is something strange that I cannot really understand. When a transaction proposal is sent to the peers in parallel, the peers should simulate the transaction and respond back to the client from my understanding. If this is the case all of the endorsing peers should do this in parallel and the total time of client -> peer -> client should not change dramatically when I increase the number of endorsing peers. In my tests I have seen that this time increases linearly inside the peers. Has anyone did such a performance/scalability test or know why this is the case? Sorry for the really long question.

smithsj (Wed, 22 Nov 2017 18:00:38 GMT):
Has joined the channel.

SaranyaM (Thu, 23 Nov 2017 10:54:13 GMT):
Has joined the channel.

SaranyaM (Thu, 23 Nov 2017 10:54:35 GMT):
Hi anybody knows how to use the CALIPER for the existing channel to benchmark the blockchain's performance ??

mikykey (Sat, 25 Nov 2017 08:11:08 GMT):
Has joined the channel.

Haojun (Mon, 27 Nov 2017 07:41:15 GMT):
@SaranyaM you can try to use '"deployed": true' for channel configuration

srics (Thu, 30 Nov 2017 01:52:00 GMT):
Has joined the channel.

rbraniste (Thu, 30 Nov 2017 02:21:41 GMT):
Has joined the channel.

SDChoi (Mon, 04 Dec 2017 03:45:35 GMT):
Has joined the channel.

poisontofu (Wed, 06 Dec 2017 02:07:28 GMT):
Has joined the channel.

snowy13 (Fri, 08 Dec 2017 00:14:24 GMT):
Has joined the channel.

oralzb (Fri, 08 Dec 2017 15:37:49 GMT):
Has joined the channel.

alvaradojl (Sun, 10 Dec 2017 09:02:19 GMT):
Has joined the channel.

netwalker2000 (Wed, 13 Dec 2017 08:55:48 GMT):
Has joined the channel.

LabibFarag (Thu, 14 Dec 2017 21:24:34 GMT):
Has joined the channel.

mwagner (Mon, 18 Dec 2017 20:36:03 GMT):
Reminder, PSWG meeting on Tues.

SuzanneSSB (Mon, 18 Dec 2017 21:47:13 GMT):
Has joined the channel.

atian15 (Tue, 26 Dec 2017 01:42:24 GMT):
Has joined the channel.

chalene (Thu, 28 Dec 2017 08:45:31 GMT):
Has joined the channel.

smcnamara (Thu, 04 Jan 2018 19:17:26 GMT):
Has joined the channel.

pchaivong (Fri, 05 Jan 2018 10:01:26 GMT):
Has joined the channel.

b9lab-damien (Fri, 05 Jan 2018 11:55:32 GMT):
Has joined the channel.

KSLee (Tue, 09 Jan 2018 08:02:09 GMT):
Has joined the channel.

toddinpal (Thu, 11 Jan 2018 01:25:10 GMT):
@FiratSertgoz

toddinpal (Thu, 11 Jan 2018 01:26:42 GMT):
@FiratSertgoz Did you determine what was going on? Sounds like your test environment might have been resource limited or resource bound. Also what configuration were you using with regards to state/history database and orderer?

jonreid (Thu, 11 Jan 2018 16:38:07 GMT):
Has joined the channel.

jonreid (Thu, 11 Jan 2018 16:42:21 GMT):
@FiratSertgoz I'm interested in this linear relationship you describe. Are you running the peers across a true decentralised architecture or are they all on the same infrastructure instance? If it is the latter you can imagine how you might get a sort of linear performance curve as the parallelism you are testing is not physical.

eabiodun (Thu, 11 Jan 2018 21:14:09 GMT):
Has joined the channel.

smcnamara (Tue, 16 Jan 2018 13:49:56 GMT):
sorry i cant make todays PSWG call as I have an appointment.

VipinB (Tue, 16 Jan 2018 14:19:07 GMT):
Will be at the call briefly.

VipinB (Tue, 16 Jan 2018 14:19:23 GMT):
Guy's comment on linking to performance is great

VipinB (Tue, 16 Jan 2018 14:20:38 GMT):
IoT is key as well as @mwagner comments

javrevasandeep (Wed, 17 Jan 2018 08:43:43 GMT):
Has joined the channel.

AshishMishra 1 (Wed, 17 Jan 2018 16:44:24 GMT):
Has joined the channel.

AshishMishra 1 (Wed, 17 Jan 2018 16:48:02 GMT):
Guys, I 've trying to have a blockchain based on composer model. But I 'm seeing a performance dip of 30-40% when using composer to deploy my blockchain vs directly deploying my chaincode and use native sdk to invoke the chaincode. Is that kind of performance penalty expected with composer?

tkuhrt (Wed, 17 Jan 2018 18:22:25 GMT):
@AshishMishra 1 : I suggest asking on the #composer channel

javrevasandeep (Thu, 18 Jan 2018 11:01:14 GMT):
i am getting the error Failed to invoke chaincode. cause:Error: Problem setting up the event hub :Error: EventHub has been shutdown after storing around 3000 records in blockchain. This error is going away automatically after few minutes and the same error appearing again after storing few more records. I am using balance transfer example more information below [2018-01-18 10:55:14.310] [ERROR] invoke-chaincode - REQUEST_TIMEOUT:localhost:7053 [2018-01-18 10:55:14.314] [ERROR] invoke-chaincode - Problem setting up the event hub :Error: EventHub has been shutdown [2018-01-18 10:55:14.322] [ERROR] invoke-chaincode - Error: Problem setting up the event hub :Error: EventHub has been shutdown at eh.registerTxEvent (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/app/invoke-transaction.js:115:14) at closer (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/node_modules/fabric-client/lib/EventHub.js:433:5) at EventHub._closeAllCallbacks (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/node_modules/fabric-client/lib/EventHub.js:443:3) at EventHub._disconnect (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/node_modules/fabric-client/lib/EventHub.js:384:8) at EventHub.disconnect (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/node_modules/fabric-client/lib/EventHub.js:373:8) at Timeout.setTimeout (/home/bteam/go/src/github.com/hyperledger/fabric-samples/smartProperty24Nov/app/invoke-transaction.js:93:10) at ontimeout (timers.js:469:11) at tryOnTimeout (timers.js:304:5) at Timer.listOnTimeout (timers.js:264:5)

tkuhrt (Thu, 18 Jan 2018 16:39:53 GMT):
@javrevasandeep : I suggest asking in one of the`fabric` channels -- maybe #fabric-questions channel

AshishMishra 1 (Fri, 19 Jan 2018 10:23:32 GMT):
Hi team, I want some generic guidelines in increasing the performance.. of fabric blockchain. I 've tried scaling the peers vertically and horizontally and also tried to scaling the orderer service horizontally.. but I 'm not able to cross a 80 TPS even with 10 peers. I 'm able to get about 55-60 TPS from 1 peer (c4.2x large and 2000 IOPS SSD disks), but with 10 peers the performance didn't increase much. What are the things I can look for? I 'm using c4 type instances on AWS and ELB for load-balancing the requests from my web application to orderer and fabric peers.

AshishMishra 1 (Fri, 19 Jan 2018 10:25:06 GMT):
Loadbalacing the traffic from applications to all peers should increase the performance or I should only send to few peers and other peers would just replicate the blocks. Same goes for orderer, I 'm using kafka based orderer.

AshishMishra 1 (Fri, 19 Jan 2018 10:29:15 GMT):
I 'm worried for the fact that my chaincode is very simple at the moment doing a simple asset transfer, when I build on that more complex logic. The performance could get a serious hit. My aim is to at least reach 500 TPS.

fz (Sat, 20 Jan 2018 03:48:36 GMT):
Has joined the channel.

gshap (Sun, 21 Jan 2018 03:17:34 GMT):
Has joined the channel.

boredsocial (Sun, 21 Jan 2018 11:04:51 GMT):
Has joined the channel.

javrevasandeep (Mon, 22 Jan 2018 12:38:55 GMT):
@AshishMishra 1 Hi ashish. Even i am fiddling around the performance issues. I am not even getting 10 TPS using just 2 orgs with 2 peers each. Could you pls help me sharing your network configuration. Are you trying on multihost environment using cello or locally? are you using node-sdk to invoke and query? and what are the docker-compose files u r using for orderer, peer and CA

AshishMishra 1 (Tue, 23 Jan 2018 11:55:52 GMT):
@javrevasandeep , I 'm using multihost enviroement with the with 1 org, a kafka based orderer service and 2 orderer containers and 3-4 peers. I 've basically split the compose file and execute them separately , which comes with the sample projects.

javrevasandeep (Tue, 23 Jan 2018 13:44:56 GMT):
if possible could you pls share your docker-compose files. I am very much interested in running kafka based orderer service in multi host environment. Please

AshishMishra 1 (Wed, 24 Jan 2018 13:37:04 GMT):

dc-compose_peer.txt

AshishMishra 1 (Wed, 24 Jan 2018 13:37:19 GMT):
@javrevasandeep , you can see that for reference..

AshishMishra 1 (Wed, 24 Jan 2018 13:37:46 GMT):
I 've used extra hosts, to enable cross host communication

javrevasandeep (Wed, 24 Jan 2018 13:53:51 GMT):
Thanks @AshishMishra 1 . Could you please also share your docker-compose for kafka and orderers. Probably I am missing some configuration there

javrevasandeep (Wed, 24 Jan 2018 14:04:21 GMT):
@AshishMishra 1 could you please share your docker-compose for kafka and orderer services. I have the similar requirement for my usecase

AshishMishra 1 (Wed, 24 Jan 2018 14:08:28 GMT):

kakfa.txt

AshishMishra 1 (Wed, 24 Jan 2018 14:08:35 GMT):
It's working for me.

AshishMishra 1 (Thu, 25 Jan 2018 06:21:11 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=2ytTs8cW9fAmwehLQ) guys can anyone revert on this please? I 'd be really helpful if I know the ceiling for fabric performance.

ArnabChatterjee (Fri, 26 Jan 2018 09:09:34 GMT):
Hello All, I was doing a load test on my application with Node SDK as the front end and CouchDB as World state. While doing it, I found that the getState takes about 10~15 times (approx) more than the putState operation. Although it is in milliseconds, I am still curious to know why is there such a big difference. I took the difference in times in the logs in the peer logs to obtain the result. Thank you. :)

tkuhrt (Sat, 27 Jan 2018 12:38:01 GMT):
@ArnabChatterjee @AshishMishra 1 : You might want to post this to one of the `fabric` channels. This channel is for the performance and scalability working group that is working to define the right metrics for measuring performance and scale of a blockchain network. You are most likely not reaching the group of people that can help.

ArnabChatterjee (Sat, 27 Jan 2018 15:31:52 GMT):
@tkuhrt - Thank you.

KathyXu (Thu, 01 Feb 2018 14:20:49 GMT):
Has joined the channel.

frankz (Mon, 05 Feb 2018 11:37:25 GMT):
Has joined the channel.

gshap (Tue, 06 Feb 2018 12:01:36 GMT):
Hi. Firstly,, this is a great group and something I am very interested in. I have been working through the instructions to test sawtooth here https://github.com/Huawei-OSG/caliper I am trying to run the simple benchmark using this command: npm test -- simple -c ./benchmark/simple/config.json -n ./benchmark/simple/sawtooth.json but I am getting an error. Client 28921: error SyntaxError: /home/ubuntu/sawtooth-core/sdk/javascript/protobuf/protobuf_bundle.json: Unexpected end of JSON input at JSON.parse () at Object.Module._extensions..json (module.js:662:27) at Module.load (module.js:556:32) at tryModuleLoad (module.js:499:12) at Function.Module._load (module.js:491:3) at Module.require (module.js:587:17) at require (internal/module.js:11:18) at Object. (/home/ubuntu/sawtooth-core/sdk/javascript/protobuf/index.js:22:37) at Module._compile (module.js:643:30) at Object.Module._extensions..js (module.js:654:10) at Module.load (module.js:556:32) at tryModuleLoad (module.js:499:12) at Function.Module._load (module.js:491:3) at Module.require (module.js:587:17) at require (internal/module.js:11:18) at Object. (/home/ubuntu/sawtooth-core/sdk/javascript/processor/index.js:28:5) at Module._compile (module.js:643:30) at Object.Module._extensions..js (module.js:654:10) at Module.load (module.js:556:32) at tryModuleLoad (module.js:499:12) at Function.Module._load (module.js:491:3) at Module.require (module.js:587:17) Anyone able to help? The only piece of info I could find was that it may be due to using the latest version of protbufs. See here: https://github.com/dcodeIO/ProtoBuf.js/wiki/Changes-in-ProtoBuf.js-3.8 Anyhelp would be appreciated as I am trying to run caliper to get some performance results for sawtooth and then would like to run the tests on some other blockchains as part of a univesity research project.

gshap (Tue, 06 Feb 2018 12:01:36 GMT):
Hi. Firstly,, this is a great group and something I am very interested in. I have been working through the instructions to test sawtooth here https://github.com/Huawei-OSG/caliper I am trying to run the simple benchmark using this command: npm test -- simple -c ./benchmark/simple/config.json -n ./benchmark/simple/sawtooth.json but I am getting an error. Client 28921: error SyntaxError: /home/ubuntu/sawtooth-core/sdk/javascript/protobuf/protobuf_bundle.json: Unexpected end of JSON input at JSON.parse () at Object.Module._extensions..json (module.js:662:27) at Module.load (module.js:556:32) at tryModuleLoad (module.js:499:12) at Function.Module._load (module.js:491:3) at Module.require (module.js:587:17) at require (internal/module.js:11:18) at Object. (/home/ubuntu/sawtooth-core/sdk/javascript/protobuf/index.js:22:37) at Module._compile (module.js:643:30) at Object.Module._extensions..js (module.js:654:10) at Module.load (module.js:556:32) at tryModuleLoad (module.js:499:12) at Function.Module._load (module.js:491:3) at Module.require (module.js:587:17) at require (internal/module.js:11:18) at Object. (/home/ubuntu/sawtooth-core/sdk/javascript/processor/index.js:28:5) at Module._compile (module.js:643:30) at Object.Module._extensions..js (module.js:654:10) at Module.load (module.js:556:32) at tryModuleLoad (module.js:499:12) at Function.Module._load (module.js:491:3) at Module.require (module.js:587:17) Anyone able to help? The only piece of info I could find was that it may be due to using the latest version of protbufs. See here: https://github.com/dcodeIO/ProtoBuf.js/wiki/Changes-in-ProtoBuf.js-3.8 Any help would be appreciated as I am trying to run caliper to get some performance results for sawtooth and then would like to run the tests on some other blockchains as part of a university research project. Many thanks

mwagner (Tue, 06 Feb 2018 14:00:31 GMT):
I am going to be a few minutes late, feel free to start w/o me

Henni (Tue, 06 Feb 2018 14:04:20 GMT):
Has joined the channel.

tallharish (Wed, 07 Feb 2018 20:57:13 GMT):
Summary of the Meeting on Feb 06: https://docs.google.com/document/d/11tB0CPAZIEqimeOp36ysd3C6tWxOhsoC7OleuUIsou8/edit

pasimoes (Thu, 08 Feb 2018 06:09:37 GMT):
Has joined the channel.

mikykey (Mon, 12 Feb 2018 21:27:55 GMT):
Hello to everybody! I'm doing some performances test on hyperledger fabric. I tried to execute the same sequence of writing operations on a multi organization, single channel blockchain. Operations executed using command line interface. I modified the endorsement policies with 2 configurations: 1) AND(org1MSP.member,org2MSP.member, ... , orgNMSP.member) 2) OR (org1MSP.member,org2MSP.member, ... , orgNMSP.member) All the operations conducted with first endorsement policy (*AND*) required *less time* (about 20%) than the operations with OR. I measured the time requried with _time_ command of bash. If AND requires the endorsement of at least one member of all organizations, why did it required less time? thanks in advance.

grkvlt (Tue, 13 Feb 2018 16:05:48 GMT):
Has joined the channel.

tallharish (Tue, 13 Feb 2018 16:17:27 GMT):
Summary of meeting on Feb 13: https://docs.google.com/document/d/1acSXyF6T25JycoBOcBoBEJvGaSNYKtymC5V9Yloo2ro/edit?usp=sharing

tallharish (Tue, 13 Feb 2018 16:17:27 GMT):
Another productive meeting. Summary of meeting (on Feb 13): https://docs.google.com/document/d/1acSXyF6T25JycoBOcBoBEJvGaSNYKtymC5V9Yloo2ro/edit?usp=sharing

toddinpal (Tue, 13 Feb 2018 18:10:40 GMT):
With respect to this whole throughput vs goodput, would it make sense to indicate that both need to be measured? Generally goodput is what users think of when characterizing throughput. However some systems may not have a linear relationship between throughput and goodput. Imagine that as a system gets more heavily loaded, while it's throughput may go up linearly, it's goodput may not. This is especially true as systems are driven into overload conditions.

toddinpal (Tue, 13 Feb 2018 18:13:15 GMT):
Would it make sense to suggest that throughput must always include the breakdown of transactions with respect to successful or not? How many were dropped because the messages were malformed. How many were dropped because of other protocol errors (sequence, whatever), How many were not processed because of timeouts due to overloading? How many failed due to failed logic checks such as transferring more money than I have or selling something I don't own?

pmettu (Tue, 13 Feb 2018 23:16:40 GMT):
Has joined the channel.

JayJong (Wed, 14 Feb 2018 08:47:55 GMT):
Has joined the channel.

minollo (Fri, 16 Feb 2018 13:01:17 GMT):
Has joined the channel.

Dan (Fri, 16 Feb 2018 16:34:03 GMT):
yes I think that all makes sense to describe in the workload section. I think its important that we report TPS as goodput. Otherwise a system that is failing horribly will show very high numbers which would convey entirely the wrong result.

novusopt (Wed, 21 Feb 2018 18:58:19 GMT):
Has joined the channel.

robinrob (Fri, 23 Feb 2018 10:52:24 GMT):
Has joined the channel.

smcnamara (Tue, 27 Feb 2018 13:21:28 GMT):
FYI I’m travelling this afternoon with patchy comms so might not be able to connect the call.

mwagner (Tue, 27 Feb 2018 13:58:32 GMT):
ok, thanks

salmanbaset (Tue, 27 Feb 2018 14:08:39 GMT):
Has joined the channel.

tallharish (Tue, 27 Feb 2018 18:42:34 GMT):
Summary of Feb 27 meeting: https://docs.google.com/document/d/1VBRCskRhTI9Eqt372j_VN-W6Li96-7CIKMb9vyALx8M/edit?usp=sharing

vmuravyev (Sat, 03 Mar 2018 11:45:17 GMT):
Has joined the channel.

smcnamara (Thu, 08 Mar 2018 15:32:07 GMT):
Caliper documentation updated to reflect current status and thinking. comments welcome.

smcnamara (Thu, 08 Mar 2018 15:32:18 GMT):
https://docs.google.com/document/d/1cwScsNgYUj72vP2fqZ6vihYiuQcy45Ml2C_yLRI7EoQ

smcnamara (Thu, 08 Mar 2018 15:34:02 GMT):
We're getting ready to propose it to TSC and welcome any formal or informal support from the team here at PSWG. :)

tkuhrt (Mon, 12 Mar 2018 21:11:41 GMT):
FYI: For tomorrow's PSWG, we will move to Zoom conferencing. Here are the details: Join from PC, Mac, Linux, Chromebook, iOS or Android: https://zoom.us/j/336954997 Or iPhone one-tap : \\ US: +16465588656,,336954997# or +16699006833,,336954997# Or Telephone: \\ US: +1 646 558 8656 or +1 669 900 6833 US (Toll Free): +1 855 880 1246 or +1 877 369 0926 Meeting ID: 336 954 997 International numbers available: https://zoom.us/zoomconference?m=PZe41QaQol-hljNTvHlOhwWrG6puKvwB

baohua (Tue, 13 Mar 2018 02:05:34 GMT):
Has left the channel.

bartman250 (Tue, 13 Mar 2018 07:32:07 GMT):
Has joined the channel.

mwagner (Tue, 13 Mar 2018 13:01:47 GMT):
looks like someone needs to login to start the meeting

smcnamara (Tue, 13 Mar 2018 13:06:02 GMT):
im not able to connect. Anyone else get in ok?

ikocsis (Tue, 13 Mar 2018 13:09:06 GMT):
I'm not able to connect, either

smcnamara (Tue, 13 Mar 2018 13:09:28 GMT):
@mwagner is @tkuhrt the owner? seems like someone needs to kick if off

toddinpal (Tue, 13 Mar 2018 13:11:06 GMT):
likewise, still waiting

smcnamara (Tue, 13 Mar 2018 13:11:37 GMT):
maybe the rest are still on uber?

toddinpal (Tue, 13 Mar 2018 13:11:56 GMT):
For me it says another meeting is in progress

VipinB (Tue, 13 Mar 2018 13:12:11 GMT):
Should be the chair or designee is the owner

VipinB (Tue, 13 Mar 2018 13:12:31 GMT):
We should tell tkuhrt

mwagner (Tue, 13 Mar 2018 13:12:36 GMT):
I dont have the credentials to kick it off

mwagner (Tue, 13 Mar 2018 13:12:44 GMT):
falling back to uberconf

tallharish (Tue, 13 Mar 2018 13:12:57 GMT):
2 of us were in the call. No one else showed up

mwagner (Tue, 13 Mar 2018 13:13:20 GMT):
ok, now zoom just started

mwagner (Tue, 13 Mar 2018 13:13:40 GMT):
zoom or uber ?

VipinB (Tue, 13 Mar 2018 13:14:22 GMT):
I amon call

smcnamara (Tue, 13 Mar 2018 13:14:27 GMT):
zoom started i see a few people there

VipinB (Tue, 13 Mar 2018 13:14:28 GMT):
Zoom

smcnamara (Tue, 13 Mar 2018 13:24:53 GMT):
Caliper link - https://docs.google.com/document/d/1cwScsNgYUj72vP2fqZ6vihYiuQcy45Ml2C_yLRI7EoQ/edit#heading=h.rr70f5i636xx

mwagner (Tue, 13 Mar 2018 13:43:08 GMT):
https://docs.google.com/document/d/1DQ6PqoeIH0pCNJSEYiw7JVbExDvWh_ZRVhWkuioG4k0

ricotmo (Tue, 13 Mar 2018 13:50:53 GMT):
Has joined the channel.

tkuhrt (Tue, 13 Mar 2018 16:23:01 GMT):
@mwagner : Was Project Caliper approved to be brought to the TSC this week?

smcnamara (Tue, 13 Mar 2018 18:59:27 GMT):
Hi Tracy, yes there was agreement to proceed at todays meeting. There was a good discussion of the issues and questions previously raised by the TSC and no objections to moving forward.

tkuhrt (Tue, 13 Mar 2018 19:20:59 GMT):
Great! Thanks, @smcnamara

VipinB (Tue, 13 Mar 2018 20:40:46 GMT):
How can we get Caliper on the Agenda?

tkuhrt (Tue, 13 Mar 2018 20:43:10 GMT):
When Todd Benzies asks tomorrow, I will let him know, @VipinB

smcnamara (Wed, 14 Mar 2018 08:25:16 GMT):
FYI Mark emailed Todd & Chris already Vipin so I think we're all set.

ikocsis (Wed, 14 Mar 2018 14:21:13 GMT):
Hi guys, I just found this in CoinDesk Daily: https://www.coindesk.com/huawei-building-tech-can-stress-test-blockchains/

tracy (Wed, 14 Mar 2018 20:29:52 GMT):
Has joined the channel.

tracy (Wed, 14 Mar 2018 20:54:26 GMT):
Has left the channel.

smcnamara (Thu, 15 Mar 2018 14:42:17 GMT):
fyi TSC just voted to approve Caliper as a HL Project. Thanks to everyone here at PSWG for supporting the metrics work and helping improve Caliper!

VipinB (Thu, 15 Mar 2018 15:01:13 GMT):
Congrats all!

smcnamara (Thu, 15 Mar 2018 15:30:37 GMT):
Feel free to join the chat on the shinny new #caliper channel.

sillysachin (Fri, 16 Mar 2018 10:11:39 GMT):
Has joined the channel.

Rajrup (Sat, 17 Mar 2018 04:00:27 GMT):
Has joined the channel.

praspadm (Sat, 17 Mar 2018 04:50:30 GMT):
Has joined the channel.

sillysachin (Sat, 17 Mar 2018 10:28:35 GMT):
Has anybody done hyperledger setup with hardware sizing in mind? What sort of setup allows 1000 or 10,000 transactions per day ?

Dan (Sun, 18 Mar 2018 20:22:19 GMT):
This working group is geared more towards defining what performance means for blockchain. Actual tuning and deployment guidelines are the purview of each of the projects like #sawtooth, #burrow, #fabric, #iroha.

ikocsis (Sun, 18 Mar 2018 23:22:18 GMT):
@sillysachin While @Dan is completely right, I'd just like to point out that 10k Tx/day translates to ~7 Tx/min, if I'm right (and I know that we are not accounting for the intra-day bursts here) - to the best of my knowledge, that's trivial for all Blockchain techs in Hyperledger. Should be completely doable with fabric, or even Composer + fabric on reasonable hardware. Actually - this should be a trivial load for any permissioned Blockchain. (Modulo smart contract complexity, certainly.)

Dan (Sun, 18 Mar 2018 23:45:59 GMT):
or public blockchain for that matter.

william123 (Mon, 19 Mar 2018 15:13:13 GMT):
Has joined the channel.

moriohara (Mon, 19 Mar 2018 23:54:23 GMT):
hi, unfortunately I won't be able to join the call this week due to a conflict. sorry about it.

mrtrantuan (Tue, 20 Mar 2018 04:30:53 GMT):
Has joined the channel.

smcnamara (Tue, 20 Mar 2018 12:57:13 GMT):
I also can’t join as I have a conflict. As you know #caliper was approved and the website is up & the repo has been moved over. https://www.hyperledger.org/projects/caliper

mwagner (Tue, 20 Mar 2018 13:09:25 GMT):
https://docs.google.com/document/d/1DQ6PqoeIH0pCNJSEYiw7JVbExDvWh_ZRVhWkuioG4k0

ShikarSharma (Tue, 20 Mar 2018 22:55:21 GMT):
Has joined the channel.

klenik (Wed, 21 Mar 2018 20:29:44 GMT):
Has joined the channel.

CarlXK (Fri, 23 Mar 2018 07:25:08 GMT):
Has joined the channel.

Tuoba (Mon, 26 Mar 2018 21:14:45 GMT):
Has joined the channel.

mwagner (Tue, 27 Mar 2018 13:07:37 GMT):
https://wiki.hyperledger.org/groups/tsc/wg-updates/pswg-2018-apr

mwagner (Tue, 27 Mar 2018 13:22:45 GMT):
https://docs.google.com/document/d/1DQ6PqoeIH0pCNJSEYiw7JVbExDvWh_ZRVhWkuioG4k0

tallharish (Tue, 27 Mar 2018 16:11:02 GMT):
Meeting summary for March 27: https://docs.google.com/document/d/1hHfI1qaa8Kg0Z6ELfwiZzTLe43DTFtue0uLG7NBUb-A/\

tallharish (Tue, 27 Mar 2018 16:13:27 GMT):
Meeting summary for March 20: https://docs.google.com/document/d/1RoIMxJA8VWxhLeikhplbDVo19vcoeqyBsQK7lfG62Dk/

tallharish (Tue, 27 Mar 2018 16:13:27 GMT):
Meeting summary for March 20: https://docs.google.com/document/d/1RoIMxJA8VWxhLeikhplbDVo19vcoeqyBsQK7lfG62Dk

mwagner (Wed, 28 Mar 2018 13:02:14 GMT):
thanks!

KOttoni (Wed, 28 Mar 2018 16:56:03 GMT):
Has joined the channel.

mwagner (Thu, 29 Mar 2018 14:40:31 GMT):
reminder no meeting on 03-April

rjones (Thu, 29 Mar 2018 21:10:06 GMT):
Has joined the channel.

kpkrish (Fri, 30 Mar 2018 06:48:25 GMT):
Has joined the channel.

TreyZhong (Fri, 30 Mar 2018 16:47:48 GMT):
Has joined the channel.

zscole (Fri, 30 Mar 2018 17:07:44 GMT):
Has joined the channel.

LeoSelochnik (Sat, 31 Mar 2018 13:08:24 GMT):
Has joined the channel.

neharprodduturi (Fri, 06 Apr 2018 14:27:48 GMT):
Has joined the channel.

Ryan2 (Tue, 10 Apr 2018 04:58:54 GMT):
Has joined the channel.

mwagner (Tue, 10 Apr 2018 12:44:06 GMT):
meeting today in 16 minutes

Ryan2 (Thu, 12 Apr 2018 09:17:06 GMT):
Hi experts, I got some unclear points, really thankful if you guys can help me clear out 1. for hyperledger fabric kafka-Orderer base consensus, what is scalability concept definition. 2. I got info from this resource http://www.oodlestechnologies.com/blogs/Scaling-Up-The-Hyperledger-Fabric Is that true that, adding new Org is the way to scale the system, 3. What is the problem need to be solved regarding scalability aspect, I mean, when system get scaled which is the benefit 4. How to evaluate the scalabiity of the system

Ryan2 (Thu, 12 Apr 2018 09:17:06 GMT):
Hi experts, I got some unclear points regarding hyperledger fabric kafka-Orderer base consensus system, really thankful if you guys can help me clear out 1. what is scalability concept definition. 2. I got info from this resource http://www.oodlestechnologies.com/blogs/Scaling-Up-The-Hyperledger-Fabric Is that true that, adding new Org is the way to scale the system, 3. What is the problem need to be solved regarding scalability aspect, I mean, when system get scaled which is the benefit 4. How to evaluate the scalabiity of the system

VipinB (Thu, 12 Apr 2018 10:12:19 GMT):
@Ryan2 please read https://arxiv.org/abs/1801.10228 and post further questions on #fabric channel

Ryan2 (Thu, 12 Apr 2018 12:18:24 GMT):
thank you @VipinB for your help

tallharish (Thu, 12 Apr 2018 15:31:02 GMT):
Meeting summary for April 10: https://docs.google.com/document/d/1TJvIkpP9TtQgBr1f9v1SOXMXXefw_w8Lph1a56mf8jo/

tallharish (Thu, 12 Apr 2018 15:34:30 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=kK4oGSTybbXavKLfY) @Ryan2 One way it is defined in the blockbench paper to measure the change in throughput as network size increases. In case of fabric it will be only the peers participating in the ordering service (Kafka + OSN nodes). ZK nodes are mainly for fault tolerance (high availability). Ref: http://www.comp.nus.edu.sg/~ooibc/blockbench.pdf (note that they have analyzed v0.6 and not v1.0+ which are very different architectures.

Ryan2 (Thu, 12 Apr 2018 21:56:25 GMT):
thank you @tallharish

toddinpal (Fri, 13 Apr 2018 01:02:02 GMT):
@Dan I'm still trying to figure out what you're trying to capture with the blockchain work metric. Is this a measure of the work (computing resources?) consumed by the blockchain? You say "provides meaningful characterization of blockchain performance rather than database performance.", but I'm not sure what that means.

toddinpal (Fri, 13 Apr 2018 01:03:14 GMT):
@Dan What is the relationship between a blockchain of 1 node handling 1,000 tps and a 1,000 node blockchain handling 1 tps?

Dan (Fri, 13 Apr 2018 01:12:08 GMT):
Hi @toddinpal we had our first discussion about that last tuesday so it's pretty early thinking. I'm looking for something that relates the size of the network with the throughput. Where size is intended to proxy the availability and integrity guarantees of the system. For example a single validator with high throughput does not offer any availability or integrity benefit over a traditional database. In contrast, ethereum mainnet with thousands (?) of validating nodes participating in consensus has very high integrity and availability but relatively low throughput. Your example points out this is not real useful expressed as a simple product. A different(?) Todd said he'd put some thought into a way of expressing that relationship. I think in an earlier discussion I had suggested a metric like [blockchain work @ network size] with the downside that you are back to showing two numbers which may be confusing. I think [other] Todd suggested a slope might be useful. But then we would probably need to specify the range for computing the slope.

toddinpal (Fri, 13 Apr 2018 01:12:46 GMT):
I am the other Todd... :-)

Dan (Fri, 13 Apr 2018 01:12:54 GMT):
lol :D

Dan (Fri, 13 Apr 2018 01:13:17 GMT):
You are trying to trick me into helping with your homework :P

toddinpal (Fri, 13 Apr 2018 01:13:25 GMT):
lol

toddinpal (Fri, 13 Apr 2018 01:13:45 GMT):
So why don't we add metrics for availability and integrity?

toddinpal (Fri, 13 Apr 2018 01:13:57 GMT):
Then we can relate throughput more directly

toddinpal (Fri, 13 Apr 2018 01:14:49 GMT):
I'm thinking in a partitioned scheme, increasing nodes (partitions) doesn't increase availability, and probably not integrity

toddinpal (Fri, 13 Apr 2018 01:15:09 GMT):
OK, I'll do my homework.... :-)

Dan (Fri, 13 Apr 2018 01:18:09 GMT):
If you figure this out I will give you a :star: sticker on your homework.

zscole (Fri, 13 Apr 2018 17:56:15 GMT):
Hey @Dan, I've developed a blockchain testing platform that could probably be of use.

mwall (Sun, 15 Apr 2018 13:01:05 GMT):
Has joined the channel.

mavericklam (Mon, 16 Apr 2018 03:41:11 GMT):
Has joined the channel.

mavericklam (Mon, 16 Apr 2018 03:41:39 GMT):
hello! Did anyone do performance test on the node SDK? What is the maximum TPS we can get on version 1.1 for invoking trans? Thank you

Dan (Mon, 16 Apr 2018 14:32:14 GMT):
@mavericklam this work group is about defining performance metrics, criteria, and workloads. We do not list measurements for individual platforms. Also please be aware that hyperledger is an umbrella project with multiple blockchain platforms.

Dan (Mon, 16 Apr 2018 14:33:12 GMT):
@zscole don't leave us hanging :) You can post a link to your code and/or docs or offer to present your platform at an upcoming working group meeting.

toddinpal (Mon, 16 Apr 2018 17:17:53 GMT):
@Dan ok, so I submitted my homework. Let me know what you think

zscole (Mon, 16 Apr 2018 20:24:47 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=yYSHHEHMYNDqEwRs7) @Dan hey sorry, been busy. heading to london today. our website is www.whiteblock.io.

zscole (Mon, 16 Apr 2018 20:25:11 GMT):
check it out and let me know what you think. if you want, i can demo the platform for you.

zscole (Mon, 16 Apr 2018 20:26:18 GMT):
i'd love to do a demo at an upcoming working group meeting, just let me know what i need to do in order to get the ball rolling on that. i also have a quick product overview if you want to check that out. just shoot me a DM. also, you can add me on telegram @zcole

Dan (Tue, 17 Apr 2018 02:18:38 GMT):
@toddinpal great job on your homework!

krabradosty (Tue, 17 Apr 2018 10:56:10 GMT):
Has joined the channel.

krabradosty (Tue, 17 Apr 2018 10:56:17 GMT):
Hi folks. I perform load testing for Hyperledger Fabric and Composer. I faced with degrading of latency near the 70 rps to the blockchain state (CouchDB). You can find more information here https://stackoverflow.com/questions/49875309/attempt-to-achieve-high-throughput-in-hyperledger-fabric-network. Please add a comment on StackOverflow if you have any thoughts or ideas. Thanks!

Dan (Tue, 17 Apr 2018 12:33:21 GMT):
@mwagner I may be a few min late to today's meeting.

mwagner (Tue, 17 Apr 2018 12:56:12 GMT):
@Dan Bring a note.....

Dan (Tue, 17 Apr 2018 13:02:11 GMT):
"Dog ate it"

Dan (Tue, 17 Apr 2018 13:02:19 GMT):
can you paste the zoom link here?

mwagner (Tue, 17 Apr 2018 13:03:04 GMT):
PSWG Meeting starting now https://zoom.us/j/336954997

VipinB (Tue, 17 Apr 2018 13:03:05 GMT):
: https://zoom.us/j/336954997

Dan (Tue, 17 Apr 2018 13:03:11 GMT):
thanks

VipinB (Tue, 17 Apr 2018 13:05:54 GMT):
Right in the middle of the Identity WG meeting

toddinpal (Tue, 17 Apr 2018 14:04:03 GMT):
Do we want to have a section in the document that addresses performance in light of infrastructure characteristics? So packet loss or latency impacts performance in this manner. Or my nodes are really cheap but not so reliable, how does their failure rate impact performance or availability?

tallharish (Tue, 17 Apr 2018 14:31:50 GMT):
Meeting summary for April 17: https://docs.google.com/document/d/1rHYt7t49pc7Cn1wOCQ0WFNAdxBNHWjwsBGHG0z2IuX4/edit?usp=sharing

tallharish (Tue, 17 Apr 2018 14:37:58 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=7AF6QF6Gj5XqfP2ey) @toddinpal Perhaps add this in the "Test Environment" section?

toddinpal (Tue, 17 Apr 2018 14:49:45 GMT):
By the way, who is Ryan Le and why did he mark sections as resolved?

tallharish (Tue, 17 Apr 2018 14:56:02 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=7YpajGSgZkYXCyG2W) @toddinpal I discussed with him, he did it by mistake. I "reopened" the comments I could. I asked Dan to "reopen" the ones he can. If you see ones you can reopen, please do so.

tallharish (Tue, 17 Apr 2018 14:59:22 GMT):

Clipboard - April 17, 2018 10:59 AM

tallharish (Tue, 17 Apr 2018 14:59:43 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=kMcZ3ARagNDzjHrAS) By clicking on the chat-like button and reopening them.

tallharish (Tue, 17 Apr 2018 14:59:43 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=kMcZ3ARagNDzjHrAS) By clicking on the chat-like button and reopening them (Ctrl Alt Shift A)

JayJong (Mon, 23 Apr 2018 08:53:24 GMT):
caliper

ikocsis (Tue, 24 Apr 2018 00:32:05 GMT):
I added a few words on faults (and what would be a way to incorporate them into performance measurement) to the metrics document

ikocsis (Tue, 24 Apr 2018 00:33:47 GMT):
Rather rough and simplistic - but maybe still too much to ask from "industrial self-reporting"

moriohara (Tue, 24 Apr 2018 12:56:52 GMT):
unfortunately I won't be able to join the weekly call today due to a conflict. sorry for this short notice.

mwagner (Tue, 24 Apr 2018 13:02:08 GMT):
thanks Moriohara For the rest meeting starting now

mwagner (Tue, 24 Apr 2018 13:04:45 GMT):
https://docs.google.com/document/d/1DQ6PqoeIH0pCNJSEYiw7JVbExDvWh_ZRVhWkuioG4k0/edit#heading=h.t3gztry2ja8i

VipinB (Tue, 24 Apr 2018 14:11:31 GMT):
https://www.swift.com/news-events/press-releases/swift-completes-landmark-dlt-poc is the swift PoC. The full paper is available as a link to download from there. They certainly used Fabric 1.0.

VipinB (Tue, 24 Apr 2018 14:11:31 GMT):
https://www.swift.com/news-events/press-releases/swift-completes-landmark-dlt-poc is the swift PoC press release. The full paper is available as a link to download from there. They used Fabric 1.0.

ikocsis (Tue, 24 Apr 2018 14:26:56 GMT):
Thanks, much appreciated

ikocsis (Tue, 24 Apr 2018 14:29:32 GMT):
Vipin - could you give me your mail address or drop me a note (ikocsis@mit.bme.hu)? thanks

toddinpal (Tue, 24 Apr 2018 16:09:31 GMT):
@ikocsis By the way, I think it is fantastic to have some academic participation! Not an academic myself, I think there is value is aligning semantics with what is happening in research and academia.

ikocsis (Tue, 24 Apr 2018 16:58:12 GMT):
@toddinpal :) thanks. Note that we have @tallharish, too, from Duke (the group of Professor Kishor Trivedi). And to be honest, Harish has been more active than I could be lately :) Personally, I find the ongoing conversation really interesting - locally, our involvement with people from industry is more often than not about teaching them the basics of performance evaluation.

tallharish (Tue, 24 Apr 2018 17:13:00 GMT):
@toddinpal @ikocsis I like the way conversations are shaping up. And hope we can continue the rhythm with this document and next set of documents in line.

tallharish (Tue, 24 Apr 2018 17:13:54 GMT):
Meeting summary for April 24: https://docs.google.com/document/d/1rBir9kXkyPTgtMZohesmIj2sJ32m-V48O_BKVZ4RD5Y/

mwagner (Tue, 24 Apr 2018 17:28:45 GMT):
@toddinpal I am also not an academic, first grade was the toughest 6 years of my life.....

toddinpal (Tue, 24 Apr 2018 18:06:10 GMT):
I know I've mentioned this before, but have we looked at what other organizations have done around defining performance and scalability? I'm thinking of things like TPC which I'm quite familiar with, but I know there are others such as SPEC. I know we've been shying away from defining benchmarks, but those organizations may have valuable information/background for us.

toddinpal (Tue, 24 Apr 2018 18:07:32 GMT):
And I guess a related question is: Do we think we should be defining those sorts of benchmarks?

mwagner (Tue, 24 Apr 2018 18:41:07 GMT):
I have been involved with both orgs in the past. I checked with our consortium rep last week and he has not seen any dlt activity in either yet

mwagner (Tue, 24 Apr 2018 18:41:41 GMT):
the tsc was clear that the didn't want us becoming an auditing body

mwagner (Tue, 24 Apr 2018 18:41:51 GMT):
at least that is my recollection

VipinB (Tue, 24 Apr 2018 19:27:01 GMT):
Benchmarks will be developed by someone, because the industry uses them for making decisions (or at least to have the cover of objectivity)...This is a question we encounter, currently we only have methods to do some qualitative analysis

VipinB (Tue, 24 Apr 2018 21:11:58 GMT):
See Benchmarking study by University of Cambridge (I didn't say Cambridge Analytics) https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3040224

surendra-kushwaha (Thu, 26 Apr 2018 19:28:22 GMT):
Has joined the channel.

gormand (Fri, 27 Apr 2018 12:19:39 GMT):
Has joined the channel.

mwagner (Tue, 01 May 2018 01:46:00 GMT):
Note that the Zoom meeting details have changed from Hyperledger.. Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community

bartman250 (Tue, 01 May 2018 12:06:19 GMT):
hello folks - sorry I missed the meeting - I got the timezone one hour out

mwagner (Tue, 01 May 2018 12:08:01 GMT):
PSWG meeting starts in 52 minutes

mwagner (Tue, 01 May 2018 13:02:19 GMT):
remember PSWG call is on a new zoom number today!

moriohara (Tue, 01 May 2018 13:02:26 GMT):
For some reason I cannot join because of an error message, "the host has another meeting in progress"

mwagner (Tue, 01 May 2018 13:02:49 GMT):
https://zoom.us/j/4034983298

moriohara (Tue, 01 May 2018 13:04:25 GMT):
thank you. the new url works

mwagner (Tue, 01 May 2018 13:07:24 GMT):
https://gitlab.com/emerald-platform/emerald/wikis/emerald%20benchmark

mwagner (Tue, 01 May 2018 13:07:47 GMT):
https://emerald-platform.gitlab.io/static/emeraldTechnicalPaper.pdf

tallharish (Tue, 01 May 2018 14:10:13 GMT):
Great discussion everyone. Thanks to Mark Simpson for sharing the benchmark. Meeting summary for May 1: https://docs.google.com/document/d/1hVxF4forXVpkNjqkr-Uymsvlnlk0X0ywqLajgVtPNAo/edit I will be happy to add discussion items that I missed. Please suggest.

tallharish (Tue, 01 May 2018 14:10:13 GMT):
Great discussion everyone. Thanks to Mark Simpson for sharing the benchmark. Meeting summary for May 1: https://docs.google.com/document/d/1hVxF4forXVpkNjqkr-Uymsvlnlk0X0ywqLajgVtPNAo/edit Please suggest me the discussion items that I missed

bartman250 (Tue, 01 May 2018 15:49:30 GMT):
yes - thanks folks - that was a good meeting -> I'm happy to answer any other questions you may have

Lexliw (Sat, 05 May 2018 17:39:43 GMT):
Has joined the channel.

Starseven (Tue, 08 May 2018 11:47:50 GMT):
Has joined the channel.

Dan (Tue, 08 May 2018 12:41:14 GMT):
Probably going to miss today

mwagner (Tue, 08 May 2018 13:01:19 GMT):
omw now

mwagner (Tue, 08 May 2018 13:06:24 GMT):
PSWG meeting now, anyone else coming ?

mwagner (Tue, 08 May 2018 13:06:42 GMT):
https://zoom.us/j/4034983298

mwagner (Tue, 08 May 2018 13:29:09 GMT):
@Dan we are giving you all the action items ! ;)

toddinpal (Tue, 08 May 2018 14:13:48 GMT):
So I believe the issue we need to deal with is how does finality relate to transaction throughput and latency

toddinpal (Tue, 08 May 2018 14:15:17 GMT):
and this is related to the goodput notion... Does it make sense to consider transactions that aren't final or transactions that may fail validation as part of the calculations for throughput and latency?

toddinpal (Tue, 08 May 2018 14:19:49 GMT):
Some real world examples: In Fabric, a poorly designed smart contract may cause most transactions to be endorsed, but fail validation as they all try to modify the same key. So 100 transactions may be submitted and successfully endorsed in one second, yet 99 of them are invalidated due to MVCC. Clearly a transaction throughput of 100/sec isn't correct. Likewise in PoW systems, 100 transactions may be submitted and committed in one second, yet be rolledback 5 minutes later. What is the throughput then?

toddinpal (Tue, 08 May 2018 14:21:21 GMT):
Do we attempt to graph these relationships? If so, it is a multidimensional graph with the number of axes greater than 3, ugh.

toddinpal (Tue, 08 May 2018 14:24:25 GMT):
Personally I think if we want to strive for a single number, we only consider transactions that are valid, committed, and final, although that is still problematic with systems that don't have absolute finality.

toddinpal (Tue, 08 May 2018 14:26:05 GMT):
Any other number, i.e., just using submitted or committed transactions can be gamed, and also don't help understand the real throughput or latency

Dan (Tue, 08 May 2018 14:58:40 GMT):
Thanks for the free action items @mwagner :P

Dan (Tue, 08 May 2018 15:07:49 GMT):
@toddinpal I agree that only committed transactions should count for throughput. For finality I think we are circling around the bitcoin-ng paper's definitions of epsilon and delta. see section 6. https://www.usenix.org/system/files/conference/nsdi16/nsdi16-paper-eyal.pdf The simple version is, at what point do all the validators respond with the same state. You'd want to use tolerances in a public network, but we have an easier problem in measuring permissioned networks because the population and topology are known.

ikocsis (Tue, 08 May 2018 15:52:00 GMT):
Uhm - why don't we just say that the "transaction finality threshold/predicate/function/..." used is part of the SUT description (maybe with explicit constraints in benchmark definitions and methodological suggestions in our document) and leave it at that? I love fiddling with the measurability of consensus properties as much as the next man (well... maybe even more), but for me, all this stuff seems to be more technical than necessary. For general-purpose performance comparison of "distributed ledger services" (emphasis on service), I would just say "delay for Txs that are considered final", "goodput for Txs that are considered final", etc. What "being final" means is situational, so maybe belongs into SUT definition. The important thing is that its there, so if a vendor tries to pull some *expletive*, it can be called upon its *expletive*.

ikocsis (Tue, 08 May 2018 15:52:35 GMT):
But this is certainly just my opinion.

ikocsis (Tue, 08 May 2018 15:53:12 GMT):
its -> it's

ikocsis (Tue, 08 May 2018 16:19:27 GMT):
@toddinpal - my view is that the throughput, delay and ratio of "valid, committed and final" transactions are the _primary_ and truly "service" level KPIs, so it's not a problem if we focus on those :) The relationships you are referring to - those seem to be internal affairs of the specific technology. We could even call it "effective throughput", but throughput in itself should be enough of a term if we understand it at the application level. For your Fabric example, in my book that's 1 Tx/s and a delay of <1 sec (with default block time). We can debate error rate; one can make an argument that if the clients are conscious of the nature of Fabric MVCC and do a (time-limited) number of retries: the error rate can be zero, throughput a whopping 1 Tx/s and delay a nice biggish number of seconds. For your PoW example: I would say that the "finality" criterium should be (correctly) specified in the SUT description (6 blocks, 1 hour, etc.); benchmark/measurement definition should say that a measurement where there are rollbacks beyond that are deemed invalid; and for your example, throughput (effective throughput, goodput, ... whatever we call it) would be 0. And average delay NaN. Does that make sense?

tallharish (Tue, 08 May 2018 17:00:53 GMT):
Meeting summary for May 8: https://docs.google.com/document/d/12tkS6O_if_idOMqhRlG_ZBUJwjVJzyjnDPQ6EaHkgEU/

tallharish (Tue, 08 May 2018 17:18:36 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=FYc3a2bY4PG8RBvxe) @toddinpal Correct. We had discussed this several months back. One proposal was to provide both goodput and throughput numbers along with the reasons for transactions failing (check Appendix B). But its hard to align reasons across BC platforms. Plus its beyond our scope. Thats why we settled for considering only "valid" transactions in throughput.

tallharish (Tue, 08 May 2018 17:18:36 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=FYc3a2bY4PG8RBvxe) @toddinpal Correct. We had discussed this several months back. One proposal was to provide both goodput and throughput numbers along with the reasons for transactions failing (check Appendix b). But its hard to align reasons across BC platforms. Plus its beyond our scope. Thats why we settled for considering only "valid" transactions in throughput.

VipinB (Tue, 08 May 2018 19:34:49 GMT):
I think we had discussions focused on (some ground that we had trodden before). In short we had a. probabilistic consensus vs. definite consensus b. separate sub chains vs global chain c. validation then ordering vs. ordering and validation separated. This has resulted in debates in the paper around. a. Finality debate ( epsilon delta etc) b. The definition of "global"and "Blockchain work" c. "definitions of consensus" This begs the question of what should be measured and alluded to in the metrics document. I agree with Imre. All others are measuring edge conditions, pathologies, recoverability- resiliency etc. Appropriate for stress tests for particular topologies (huge network diameter etc.)

VipinB (Tue, 08 May 2018 19:34:49 GMT):
I think we had discussions focused on some ground that we had trodden before. In short we had a. probabilistic consensus vs. definite consensus b. separate sub chains vs global chain c. validation then ordering vs. ordering and validation separated. This has resulted in debates in the paper around. a. Finality debate ( epsilon delta etc) b. The definition of "global"and "Blockchain work" c. "definitions of consensus" This begs the question of what should be measured and alluded to in the metrics document. I agree with Imre. All others are measuring edge conditions, pathologies, recoverability- resiliency etc. Appropriate for stress tests for particular topologies (huge network diameter etc.)

VipinB (Tue, 08 May 2018 19:35:34 GMT):
BTW I found the reference to 6 in Satoshi's bitcoin paper Solving for P less than 0.1%... P < 0.001 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340

VipinB (Tue, 08 May 2018 19:35:34 GMT):
BTW I found the reference to 6 confirmations in Satoshi's bitcoin paper-page 8 However p is the probability that the attacker will catch up Solving for P less than 0.1%... P < 0.001 The first point mentioned is z=5

VipinB (Tue, 08 May 2018 19:35:34 GMT):
BTW I found the reference to 6 confirmations in Satoshi's bitcoin paper-page 8 p is the probability that the attacker will catch up Solving for P less than 0.1%... P < 0.001 The first point mentioned is z=5

VipinB (Tue, 08 May 2018 19:35:34 GMT):
BTW I found the reference to 6 confirmations in Satoshi's bitcoin paper-page 8 Where he does a probabilistic analysis using a Poisson function to see whether the attacker will catch up. p is the probability that the attacker will catch up Solving for P less than 0.1%... P < 0.001 The first point mentioned is z=5

VipinB (Tue, 08 May 2018 19:35:34 GMT):
BTW I found the reference to 6 confirmations in Satoshi's bitcoin paper-page 8 Where (s)he does a probabilistic analysis to see whether the attacker will catch up. Using the Gambler's ruin problem from W. Feller, "An introduction to probability theory and its applications," 1957. p is the probability that the attacker will catch up Solving for P less than 0.1%... P < 0.001 The first point mentioned is z=5

VipinB (Tue, 08 May 2018 19:36:01 GMT):
z=5 is 6 blocks (zero based)

VipinB (Tue, 08 May 2018 20:15:28 GMT):
This also neatly slots into 1 hour, because hasrate is setup to create blocks every 10 minutes

VipinB (Tue, 08 May 2018 20:15:28 GMT):
This also neatly slots into 1 hour, because difficulty is setup to create blocks every 10 minutes based on collective hashrate of the network

toddinpal (Tue, 08 May 2018 20:31:30 GMT):
I find it interesting that for financial transactions, a probability of 0.1% is considered acceptable. For something like SWIFT, that represents about 5 billion dollars as they move about 5 trillion dollars a day.

mwagner (Tue, 08 May 2018 20:39:52 GMT):
They can send it to me....just a few hours worth....

mwagner (Tue, 08 May 2018 20:43:05 GMT):
btw, I sent email to the list, not sure if people have a conflict next week with Consensus, if you are attending the conference feel free to recruit for our WG

VipinB (Tue, 08 May 2018 21:25:57 GMT):
@toddinpal this is related to the probability of each transaction where the attacker will catch up; if you are buying a coffee then merchant can take just one confirmation (maybe a high probability); but if you are selling a Renoir the you might wait for 600 blocks where the probability of being attacked reduces considerably. But the 6 blocks figure will give you something like 0.1% probability. Which is acceptable to most normal transactions which are not of high value.

VipinB (Tue, 08 May 2018 21:27:05 GMT):
This analysis was done when BTC was meant to be used for transactions #whatwillsatoshithink

VipinB (Tue, 08 May 2018 21:27:29 GMT):
of todays situation where hodlers dominate

ikocsis (Tue, 08 May 2018 21:28:00 GMT):

Clipboard - May 8, 2018 11:27 PM

ikocsis (Tue, 08 May 2018 21:28:27 GMT):
y is probability to catch up, x is the block depth the attacker begins with

ikocsis (Tue, 08 May 2018 21:28:56 GMT):
colors encode the hash rate portion the attacker controls

VipinB (Tue, 08 May 2018 21:29:52 GMT):
Satoshi's analysis was z=5 when q=0.1

ikocsis (Tue, 08 May 2018 21:30:06 GMT):
meaning that even if you control much less than "51%", there may be a real probability for a successful attack

ikocsis (Tue, 08 May 2018 21:30:36 GMT):
Satoshi gave the formula and computed for z=5 and q=0.1

VipinB (Tue, 08 May 2018 21:30:42 GMT):
and probability of success < 0.1 %

ikocsis (Tue, 08 May 2018 21:31:00 GMT):
ikocsis graphed the formula for this year's Bitcoin lecture :)

VipinB (Tue, 08 May 2018 21:31:19 GMT):
My take is that the figure of waiting for 6 confirmations can be traced back to the original paper

ikocsis (Tue, 08 May 2018 21:31:21 GMT):
(sorry for the off topic, I couldn't resist)

ikocsis (Tue, 08 May 2018 21:31:25 GMT):
sure

ikocsis (Tue, 08 May 2018 21:31:26 GMT):
yes

VipinB (Tue, 08 May 2018 21:31:40 GMT):
Which is what I said in the call

VipinB (Tue, 08 May 2018 21:33:47 GMT):
We have that 6 sprinkled around in our paper which may not be appropriate

VipinB (Tue, 08 May 2018 21:35:12 GMT):
Actually this 6 confirmation business is never properly explained anywhere- it is often thrown around as a random number

VipinB (Tue, 08 May 2018 21:35:12 GMT):
Actually this 6 confirmation business is not properly explained when people cite the number- it is often thrown around as a random number- however it relates to the original paper

VipinB (Tue, 08 May 2018 21:36:08 GMT):
In fact in the paper we have P < 0.001 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340

VipinB (Tue, 08 May 2018 21:39:10 GMT):
So if your x axis is extended to 340, we should see the q=.45 almost touch the x axis to be close to .1 %; since your x-axis stops at 12.5 we do not see this

VipinB (Tue, 08 May 2018 21:39:30 GMT):
Of course at 51% we don't stand a chance

VipinB (Tue, 08 May 2018 21:40:14 GMT):
The point of all this is to re-examine the 6 confirmation refernces we have in our metrics paper

ikocsis (Tue, 08 May 2018 21:40:47 GMT):
But it isn't random at all - see exactly what you cite :)

ikocsis (Tue, 08 May 2018 21:41:08 GMT):
But it is certainly very misleading - what about Ethereum? 6 sure as heck won't be enough

VipinB (Tue, 08 May 2018 21:41:19 GMT):
I agree, I don't say it is random

ikocsis (Tue, 08 May 2018 21:42:22 GMT):
And that is PoW, too (yet)

VipinB (Tue, 08 May 2018 21:42:23 GMT):
I am saying people throw that number 6 around as a random choice without seeing that it is based on the paper and the table that Satoshi created

ikocsis (Tue, 08 May 2018 21:42:32 GMT):
oh, I see

ikocsis (Tue, 08 May 2018 21:42:36 GMT):
that's true

ikocsis (Tue, 08 May 2018 21:42:36 GMT):
that's very true

VipinB (Tue, 08 May 2018 21:46:45 GMT):
In this light we should look at the references to the number 6 in OUR metrics paper

VipinB (Tue, 08 May 2018 21:49:44 GMT):
It is good to see your graph @ikocsis

VipinB (Tue, 08 May 2018 21:50:26 GMT):
Did you use Satoshi's C code

ikocsis (Tue, 08 May 2018 21:50:35 GMT):
heh

VipinB (Tue, 08 May 2018 21:50:35 GMT):
to generate the graph

ikocsis (Tue, 08 May 2018 21:51:53 GMT):
no, as much of what I did in the last few years is rather data sciency stuff (I wouldn't call it actual science) - just gave it in closed form to R

ikocsis (Tue, 08 May 2018 21:53:29 GMT):
I didn't really understand why it was given in C code in the Satoshi paper (I mean there's R, Matlab, Octave, ... for such stuff) - but this must be a cultural thing. Security people tend to think in C and bash...

VipinB (Tue, 08 May 2018 21:55:01 GMT):
It is also an age thing

VipinB (Tue, 08 May 2018 21:55:21 GMT):
We were coding in c back then

VipinB (Tue, 08 May 2018 21:56:32 GMT):
Even when we thought we were coding in C++

ikocsis (Tue, 08 May 2018 21:57:46 GMT):
well, there must be something to that, too - my education mostly covered the ASM - C - C++ - Java route and I heavy R specialization came later... meaning that I'm somewhat ok with Python, Go is a bit strange, but nice at places - but I do vehemently dislike JavaScript

ikocsis (Tue, 08 May 2018 21:57:46 GMT):
well, there must be something to that, too - my education mostly covered the ASM - C - C++ - Java route and heavy R specialization came later... meaning that I'm somewhat ok with Python, Go is a bit strange, but nice at places - but I do vehemently dislike JavaScript

ikocsis (Tue, 08 May 2018 21:59:56 GMT):
Even though I simply loved MoscowML (and oh yes, Prolog)

ikocsis (Tue, 08 May 2018 22:00:01 GMT):
Anyhow

VipinB (Tue, 08 May 2018 22:00:22 GMT):
So back to the paper- let me look at refernces to 6 confirmations

ikocsis (Tue, 08 May 2018 22:00:31 GMT):
Ok, sure

VipinB (Tue, 08 May 2018 22:00:47 GMT):
in the metrics paper

ikocsis (Tue, 08 May 2018 22:01:36 GMT):
And if you have time - I don't have any solid reference on this for Ethereum (stackoverflow isn't exactly that), but an authoritative and argued number would be nice there, too

ikocsis (Tue, 08 May 2018 22:02:44 GMT):
This is actually exactly why I try to say that we should make metric definitions on a "when the Tx can be deemed final" basis, leaving the definition of finality to the SUT definition phase

VipinB (Tue, 08 May 2018 22:02:56 GMT):
I agree

ikocsis (Tue, 08 May 2018 22:03:43 GMT):
Otherwise we can't meaningfully compare say, Ethereum and Fabric - what is I'm convinced to be actually doable

ikocsis (Tue, 08 May 2018 22:03:43 GMT):
Otherwise we can't meaningfully compare, say, Ethereum and Fabric - what is I'm convinced to be actually doable

ikocsis (Tue, 08 May 2018 22:04:35 GMT):
Vipin, thanks for this - I have to bail now, I still have a midterm test to put together

VipinB (Tue, 08 May 2018 22:04:37 GMT):
Got to run now...will talk later

ikocsis (Tue, 08 May 2018 22:04:43 GMT):
Ok, bye

ikocsis (Tue, 08 May 2018 22:04:57 GMT):
I will think more about this and see how I can contribute

ikocsis (Tue, 08 May 2018 22:13:17 GMT):
@mwagner - for what it's worth, I will be next week at the ISO TC 307 meeting (Blockchain standardisation) in London; I will try to make known the work we are doing here. (Although Consensus would be nicer...)

ikocsis (Tue, 08 May 2018 22:19:02 GMT):
Also - I don't know whether people looked at my two blurbs related to faultload (zero comments on that part); I'm fully ok with simply deleting those, if the consensus is that they are too tangential or otherwise problematic

toddinpal (Wed, 09 May 2018 01:44:07 GMT):
@ikocsis Not sure I fully understand what a faultload is... My concern, which I'm not sure is related, is that publishing a number about transaction throughput or latency without an understanding of what a transaction is, makes the number meaningless. If we define a transaction as something that is valid, committed, and final, then we have a more concrete number. If we don't consider those attributes, someone can publish performance numbers that are totally meaningless. My Fabric example above actually pointed out a potential performance problem with Fabric due to poor design, but if we allow someone to benchmark Fabric with only one endorsing peer and a solo orderer and hundreds or thousands of channels, they can probably hit 10,000 or more TPS. But that configuration has nearly zero trust and relatively low availability. Well readers understand that?

ikocsis (Wed, 09 May 2018 01:45:42 GMT):
With the faultload stuff I was actually referring to self-contained, not reviewed parts of the metrics document - so I think that's unrelated

toddinpal (Wed, 09 May 2018 01:46:08 GMT):
Another trivial example is if someone tries to submit transactions with an invalid signature, does anyone even care about those? They'll get invalidated at some point, and they clearly don't provide any useful work (not to be confused with Dan's work)

toddinpal (Wed, 09 May 2018 01:46:35 GMT):
ok, I'm not following.. sorry

ikocsis (Wed, 09 May 2018 01:46:46 GMT):
I fully agree that we should absolutely focus on "valid, committed and final" transactions

toddinpal (Wed, 09 May 2018 01:47:10 GMT):
yeah

ikocsis (Wed, 09 May 2018 01:48:18 GMT):
my apologies, I should probably just finish up stuff and go to sleep,

ikocsis (Wed, 09 May 2018 01:48:18 GMT):
my apologies, I should probably just finish up stuff and go to sleep

toddinpal (Wed, 09 May 2018 01:48:40 GMT):
no apologies needed... good input. Thanks!

mwagner (Wed, 09 May 2018 19:02:34 GMT):
great Discussion!

mwagner (Mon, 14 May 2018 15:12:20 GMT):
Reminder, no meeting this week

krabradosty (Mon, 14 May 2018 16:15:15 GMT):
Hi folks! Any help will be useful. https://stackoverflow.com/questions/50334489/performance-test-of-the-hyperledger-fabric Please share this question with Fabric developers that can help if you know them. Thanks.

tallharish (Mon, 21 May 2018 18:21:06 GMT):
@toddinpal @VipinB @ikocsis : Just caught up with the above discussion. Regarding finality, we have had discussions in the past that are reflected in the current version of Appendix A. Although it is written in context of latency, it very well applies to throughput as well. It will be worth revisiting the text, and see what cases we haven't covered, or polish the text, or fix the references, etc.

tallharish (Mon, 21 May 2018 18:22:54 GMT):
@toddinpal @VipinB @ikocsis: Just caught up with the above discussion. Regarding finality, we have had discussions in the past that are reflected in the current version of Appendix A. Although it is written in context of latency, it very well applies to throughput as well. It will be worth revisiting the text, and see what cases we haven't covered, or polish the text, or fix the references, etc. @toddinpal : In consensus with our WG, we can stick to Tx as "(committed) transactions per sec." as the ONLY metric a Caliper-like tool is suppose to provide. Just that in case of networks with prob. finality, a Caliper-like tool will present the measurements in a `historic' sense, like tps in (now-3) to (now-1) hour, since the transactions in the past 1 hr might be in a block that gets stale eventually. For immediate consensus, the throughput metrics are more 'live' and can be viewed as the perf. test is coming along. @VipinB @ikocsis : Assuming a geometric distribution for tx to get included in a block, I have a plot in case 3 of Appendix B, using the following R code. This is just for representation, to get the concept clear for the readers. I haven't had a chance to review your analysis from Satoshi's paper. ``` #Discrete case: x = 1 + rgeom(1000, 0.7); sorted_x = sort(x); n = length(x); ecdf_y = (1:(n))/(n); plot(sorted_x, ecdf_y, type='s', xlab="Block Number", ylab="Cum. prob (transaction confirmed)") #Continuous case: x_exp <- rexp(1000, 0.1) plotty <- ecdf(x_exp) x_exp_cdf <- plotty(unique(x_exp)) plot(x_exp, x_exp_cdf, type='p', xlab="Time (sec.)", ylab="Cum. prob (transaction confirmed)") ```

tallharish (Mon, 21 May 2018 18:22:54 GMT):
@toddinpal @VipinB @ikocsis: Just caught up with the above discussion. Regarding finality, we have had discussions in the past that are reflected in the current version of Appendix A. Although it is written in context of latency, it very well applies to throughput as well. It will be worth revisiting the text, and see what cases we haven't covered, or polish the text, or fix the references, etc. @toddinpal : In consensus with our WG, we can stick to Throughput as "(committed) transactions per sec." as the ONLY metric a Caliper-like tool is suppose to provide. Just that in case of networks with prob. finality, a Caliper-like tool will present the measurements in a `historic' sense, like tps in (now-3) to (now-1) hour, since the transactions in the past 1 hr might be in a block that gets stale eventually. For immediate consensus, the throughput metrics are more 'live' and can be viewed as the perf. test is coming along. @VipinB @ikocsis : Assuming a geometric distribution for tx to get included in a block, I have a plot in case 3 of Appendix B, using the following R code. This is just for representation, to get the concept clear for the readers. I haven't had a chance to review your analysis from Satoshi's paper. ``` #Discrete case: x = 1 + rgeom(1000, 0.7); sorted_x = sort(x); n = length(x); ecdf_y = (1:(n))/(n); plot(sorted_x, ecdf_y, type='s', xlab="Block Number", ylab="Cum. prob (transaction confirmed)") #Continuous case: x_exp <- rexp(1000, 0.1) plotty <- ecdf(x_exp) x_exp_cdf <- plotty(unique(x_exp)) plot(x_exp, x_exp_cdf, type='p', xlab="Time (sec.)", ylab="Cum. prob (transaction confirmed)") ```

tallharish (Mon, 21 May 2018 18:22:54 GMT):
@toddinpal @VipinB @ikocsis: Just caught up with the above discussion. Regarding finality, we have had discussions in the past that are reflected in the current version of Appendix A. Although it is written in context of latency, it very well applies to throughput as well. It will be worth revisiting the text, and see what cases we haven't covered, or polish the text, or fix the references, etc. @toddinpal : In consensus with our WG, we can stick to Throughput as "(committed) transactions per sec." as the ONLY metric a Caliper-like tool is suppose to provide. Just that in case of networks with prob. finality, a Caliper-like tool will present the measurements in a `historic' sense, like tps in `(now-3)` to `(now-1)` hour, since the transactions in the past 1 hr might be in a block that gets stale eventually. For immediate consensus, the throughput metrics are more 'live' and can be viewed as the perf. test is coming along. @VipinB @ikocsis : Assuming a geometric distribution for tx to get included in a block, I have a plot in case 3 of Appendix B, using the following R code. This is just for representation, to get the concept clear for the readers. I haven't had a chance to review your analysis from Satoshi's paper. ``` #Discrete case: x = 1 + rgeom(1000, 0.7); sorted_x = sort(x); n = length(x); ecdf_y = (1:(n))/(n); plot(sorted_x, ecdf_y, type='s', xlab="Block Number", ylab="Cum. prob (transaction confirmed)") #Continuous case: x_exp <- rexp(1000, 0.1) plotty <- ecdf(x_exp) x_exp_cdf <- plotty(unique(x_exp)) plot(x_exp, x_exp_cdf, type='p', xlab="Time (sec.)", ylab="Cum. prob (transaction confirmed)") ```

tallharish (Mon, 21 May 2018 18:22:54 GMT):
@toddinpal @VipinB @ikocsis: Just caught up with the above discussion. Regarding finality, we have had discussions in the past that are reflected in the current version of Appendix A. Although it is written in context of latency, it very well applies to throughput as well. It will be worth revisiting the text, and see what cases we haven't covered, or polish the text, or fix the references, etc. @toddinpal : In consensus with our WG, we can stick to Throughput as "(committed) transactions per sec." as the ONLY metric a Caliper-like tool is suppose to provide. Just that in case of networks with prob. finality, a Caliper-like tool will present the measurements in a 'historic' sense, like tps in `(now-3)` to `(now-1)` hour, since the transactions in the past 1 hr might be in a block that gets stale eventually. For immediate consensus, the throughput metrics are more 'live' and can be viewed as the perf. test is coming along. @VipinB @ikocsis : Assuming a geometric distribution for tx to get included in a block, I have a plot in case 3 of Appendix B, using the following R code. This is just for representation, to get the concept clear for the readers. I haven't had a chance to review your analysis from Satoshi's paper. ``` #Discrete case: x = 1 + rgeom(1000, 0.7); sorted_x = sort(x); n = length(x); ecdf_y = (1:(n))/(n); plot(sorted_x, ecdf_y, type='s', xlab="Block Number", ylab="Cum. prob (transaction confirmed)") #Continuous case: x_exp <- rexp(1000, 0.1) plotty <- ecdf(x_exp) x_exp_cdf <- plotty(unique(x_exp)) plot(x_exp, x_exp_cdf, type='p', xlab="Time (sec.)", ylab="Cum. prob (transaction confirmed)") ```

tallharish (Mon, 21 May 2018 18:22:54 GMT):
@toddinpal @VipinB @ikocsis: Just caught up with the above discussion. Regarding finality, we have had discussions in the past that are reflected in the current version of Appendix A. Although it is written in context of latency, it very well applies to throughput as well. It will be worth revisiting the text, and see what cases we haven't covered, or polish the text, or fix the references, etc. @toddinpal : In consensus with our WG, we can stick to Throughput as "(committed) transactions per sec." as the ONLY metric a Caliper-like tool is suppose to provide. In case of networks with prob. finality, while a performance test is on-going, a Caliper-like tool will present the measurements in a 'historic' sense, like tps in `(now-3)` to `(now-1)` hour, since some of the transactions in the past 1 hr might be in a block that gets stale eventually. For immediate consensus, the throughput metrics are more 'live' and can be viewed as the perf. test is coming along. @VipinB @ikocsis : Assuming a geometric distribution for tx to get included in a block, I have a plot in case 3 of Appendix B, using the following R code. This is just for representation, to get the concept clear for the readers. I haven't had a chance to review your analysis from Satoshi's paper. ``` #Discrete case: x = 1 + rgeom(1000, 0.7); sorted_x = sort(x); n = length(x); ecdf_y = (1:(n))/(n); plot(sorted_x, ecdf_y, type='s', xlab="Block Number", ylab="Cum. prob (transaction confirmed)") #Continuous case: x_exp <- rexp(1000, 0.1) plotty <- ecdf(x_exp) x_exp_cdf <- plotty(unique(x_exp)) plot(x_exp, x_exp_cdf, type='p', xlab="Time (sec.)", ylab="Cum. prob (transaction confirmed)") ```

tallharish (Mon, 21 May 2018 18:22:54 GMT):
@toddinpal @VipinB @ikocsis: Just caught up with the above discussion. Regarding finality, we have had discussions in the past that are reflected in the current version of Appendix A. Although it is written in context of latency, it very well applies to throughput as well. It will be worth revisiting the text, and see what cases we haven't covered, or polish the text, or fix the references, etc. @toddinpal : In consensus with our WG, we can stick to Throughput as "(committed) transactions per sec." as the ONLY metric a Caliper-like tool is suppose to provide. In case of networks with prob. finality, while a performance test is on-going, a Caliper-like tool will present the measurements in a 'historic' sense, like tps in `(now-3)` to `(now-1)` hour, since some of the transactions in the past 1 hr might be in a block that gets stale eventually. For immediate consensus, the throughput metrics are more 'live' and can be viewed as the perf. test is coming along. @VipinB @ikocsis : Assuming a geometric distribution for tx to get included in a block, I have a plot in case 3 of Appendix B, using the following R code. This is just for representation, to get the concept clear for the readers. I haven't had a chance to review your analysis from Satoshi's paper. ```#Discrete case: x = 1 + rgeom(1000, 0.7); sorted_x = sort(x); n = length(x); ecdf_y = (1:(n))/(n); plot(sorted_x, ecdf_y, type='s', xlab="Block Number", ylab="Cum. prob (transaction confirmed)") #Continuous case: x_exp <- rexp(1000, 0.1) plotty <- ecdf(x_exp) x_exp_cdf <- plotty(unique(x_exp)) plot(x_exp, x_exp_cdf, type='p', xlab="Time (sec.)", ylab="Cum. prob (transaction confirmed)")```

tallharish (Mon, 21 May 2018 18:22:54 GMT):
@toddinpal @VipinB @ikocsis: Just caught up with the above discussion. Regarding finality, we have had discussions in the past that are reflected in the current version of Appendix A. Although it is written in context of latency, it very well applies to throughput as well. It will be worth revisiting the text, and see what cases we haven't covered, or polish the text, or fix the references, etc. @toddinpal : In consensus with our WG, we can stick to Throughput as "(committed) transactions per sec." as the ONLY metric a Caliper-like tool is suppose to provide. In case of networks with prob. finality, while a performance test is on-going, a Caliper-like tool will present the measurements in a 'historic' sense, like tps in `(now-3)` to `(now-1)` hour, since some of the transactions in the past 1 hr might land up in a stale (uncle) block. For immediate consensus, the throughput metrics are more 'live' and can be viewed as the perf. test is coming along. @VipinB @ikocsis : Assuming a geometric distribution for tx to get included in a block, I have a plot in case 3 of Appendix B, using the following R code. This is just for representation, to get the concept clear for the readers. I haven't had a chance to review your analysis from Satoshi's paper. ```#Discrete case: x = 1 + rgeom(1000, 0.7); sorted_x = sort(x); n = length(x); ecdf_y = (1:(n))/(n); plot(sorted_x, ecdf_y, type='s', xlab="Block Number", ylab="Cum. prob (transaction confirmed)") #Continuous case: x_exp <- rexp(1000, 0.1) plotty <- ecdf(x_exp) x_exp_cdf <- plotty(unique(x_exp)) plot(x_exp, x_exp_cdf, type='p', xlab="Time (sec.)", ylab="Cum. prob (transaction confirmed)")```

tallharish (Mon, 21 May 2018 18:32:04 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=CmzBnCRmPBCDjHDHk) @ikocsis People say its '12' in case of Ethereum [Weber-17].

tallharish (Mon, 21 May 2018 18:35:45 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=sJhMPRk42Rzgrnao3) @ikocsis The text nicely summarizes what you described in the meeting earlier. However, I feel it doesn't fit well with this document, where we are focused on metrics and how to measure it. We should keep this text for a future document, where we can have a section on (sensible) load generation.

mwagner (Mon, 21 May 2018 18:38:45 GMT):
@toddinpal @ikocsis @tallharish @VipinB so should I put finality on the agenda for tomorrow or let it sit for a week ?

jsmitchell (Mon, 21 May 2018 18:42:37 GMT):
@krabradosty what percentage of transactions are you submitting which modify the same location?

jsmitchell (Mon, 21 May 2018 18:44:18 GMT):
I believe there is an effect where those transactions need to be re-submitted/simulated due to the fabric MVCC design

jsmitchell (Mon, 21 May 2018 18:44:40 GMT):
if some percentage of your transactions fall into this category, that may be why you aren't getting the results you expect

nickaleks (Tue, 22 May 2018 08:30:23 GMT):
Has joined the channel.

mwagner (Tue, 22 May 2018 13:06:42 GMT):
PSWG meeting has started

mwagner (Tue, 22 May 2018 13:07:21 GMT):
https://docs.google.com/document/d/1DQ6PqoeIH0pCNJSEYiw7JVbExDvWh_ZRVhWkuioG4k0/edit#

VipinB (Tue, 22 May 2018 13:08:52 GMT):
@mwagner , I have to leave in 30 minutes.

salmanbaset (Tue, 22 May 2018 13:12:50 GMT):
is this the correct zoom? https://zoom.us/j/336954997

tallharish (Tue, 22 May 2018 13:15:05 GMT):
https://zoom.us/j/4034983298

sativ (Tue, 22 May 2018 13:24:04 GMT):
Has joined the channel.

IsaacWong (Tue, 22 May 2018 13:25:27 GMT):
Has joined the channel.

VipinB (Tue, 22 May 2018 13:38:50 GMT):
From: https://stackoverflow.com/questions/50334489/performance-test-of-the-hyperledger-fabric Fabric performance: Fabric is a queueing system. With a high load, the waiting time increases exponentially (queueing property) and hence the transaction latency. However, for golevelDB, we should get at least 2000 tps with a low latency. From the CPU utilization plot, it looks like only 16 vCPUs are utilized fully out of 36 vCPUs. What value is set for validatorPoolSize in core.yaml for each peer? You can set this value equal or lesser than the block size and check whether the throughput increases. The performance would differ based on the 1. workload (fabcar vs fabcoin), 2. disk (hdd vs ssd, local vs network attached), 3. load generator (CLI vs SDK), 4. load generation method (open system vs closed system (https://www.usenix.org/legacy/event/nsdi06/tech/full_papers/schroeder/schroeder.pdf) vs some distribution) and 5. network bandwidth (at least 1.6 Gbps for 2700 tps). Also, ensure that the load generator is not becoming a bottleneck. It would be better the latency can be divided further into (endorsement latency, ordering latency, commit latency) and collect other resource utilization such as network and disk so that the bottleneck can be identified easily. You can refer to our technical paper titled Performance Benchmarking and Optimizing Hyperledger Fabric (https://drive.google.com/file/d/1OsIoPtlv5X2PWyOAlDn1FCnHCZPyrF57/view) . We have conducted a comprehensive empirical study. With levelDB, we should get at least 2000 tps with a low latency.

GPhysics (Fri, 25 May 2018 05:30:46 GMT):
Has joined the channel.

Gandalf (Sun, 27 May 2018 04:30:57 GMT):
Has joined the channel.

donatopellegrino (Mon, 28 May 2018 13:23:17 GMT):
Has joined the channel.

VipinB (Tue, 29 May 2018 14:54:55 GMT):
How did the meeting go?

ikocsis (Tue, 29 May 2018 15:13:17 GMT):
Hi all, sorry that I have missed today's call - I got stuck in an endless (and meaningless) meeting

tallharish (Wed, 30 May 2018 02:24:08 GMT):
I missed it too :-(. Thanks to a deadline. Hopefully will be back in action soon

jwaup (Wed, 30 May 2018 13:58:51 GMT):
Has joined the channel.

mwagner (Wed, 30 May 2018 15:20:43 GMT):
Guy, Mark Simpson, and i talked about finality for about 25 minutes. My main takeaway was there are multiple definitions of finality based on the use case. In the simple bank case, a small check may clear immediately, but a large check may have a 3 day hold placed on the funds. So different levels of finality. Now how to capture that in a document and as a measurement

abraham (Sat, 02 Jun 2018 04:03:51 GMT):
Has joined the channel.

mwagner (Mon, 04 Jun 2018 17:14:38 GMT):
canceling the meeting for Tues 05-Jun

dappcoder (Tue, 05 Jun 2018 13:03:19 GMT):
Has joined the channel.

dappcoder (Tue, 05 Jun 2018 13:04:36 GMT):
Hi everyone!

dappcoder (Tue, 05 Jun 2018 13:06:04 GMT):
My name is Alex Males. I am part of Hashgraph development community. We are interested in building a PoC to plug-in Hashgraph consensus (aBFT) into Fabric's Orderer.

dappcoder (Tue, 05 Jun 2018 13:08:16 GMT):
Hashgraph is a high throughput (200k+ TPS) consensus algorithm that has been proved viable for permissioned ledger use cases. They are also in plan to launch a public ledger this year.

dappcoder (Tue, 05 Jun 2018 13:11:24 GMT):
Can you help me figure out if an integration Fabric Orderer + Hashgraph would be helpful? As I see it, hashgraph needs a good dev toolset/framework (like Composer or chaincode) while Fabric might benefit from BFT provided by Hashgraph. I saw that there is a BFT consensus implementation in the works in hyperledger JIRA.

dappcoder (Tue, 05 Jun 2018 13:16:38 GMT):
I've found this group in hyperledger calendar - I thought performance & scale might be interested in this integration. Joined the zoom conf call, but only now I saw that today's session has been canceled :)

eabiodun (Tue, 05 Jun 2018 23:01:24 GMT):
@dappcoder implementing it on the order may be an over simplification of the problem. Happy to discuss it with you. PM me.

tallharish (Wed, 06 Jun 2018 20:08:34 GMT):
@dappcoder Try looking for folks in #fabric channel (perhaps @ mastersingh24) On this channel, we discuss performance metrics across blockchain platforms.

knagware9 (Thu, 07 Jun 2018 18:33:32 GMT):
Has joined the channel.

tkuhrt (Thu, 07 Jun 2018 21:28:32 GMT):
@dappcoder : You may also be interested in http://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#making-feature-enhancement-proposals

tkuhrt (Thu, 07 Jun 2018 21:29:02 GMT):
@rjones and I would be happy to help if you are having any problems with working through the process of contributing code.

wangrangli (Mon, 11 Jun 2018 09:30:22 GMT):
Has joined the channel.

VipinB (Mon, 11 Jun 2018 15:32:10 GMT):
As @mwagner will not be available, I have volunteered to run the call. Let us fix on Agenda items

VipinB (Mon, 11 Jun 2018 15:32:40 GMT):
Let me know who all are interested in turning up...

Dan (Mon, 11 Jun 2018 18:14:58 GMT):
fyi, I've conflicts with other HL meetings this week. Have fun without me. :)

tallharish (Mon, 11 Jun 2018 19:54:47 GMT):
I will be there.

tallharish (Tue, 12 Jun 2018 13:05:14 GMT):
We have dialed in on https://zoom.us/j/4034983298

tallharish (Tue, 12 Jun 2018 13:05:14 GMT):
We have dialed in on https://zoom.us/j/4034983298.

VipinB (Tue, 12 Jun 2018 13:05:25 GMT):
Proposed Agenda: -Anti-trust -Go through comments in doc- depending on attendance to check various comments https://docs.google.com/document/d/1DQ6PqoeIH0pCNJSEYiw7JVbExDvWh_ZRVhWkuioG4k0/edit#

guyho (Tue, 12 Jun 2018 13:12:32 GMT):
My calendar indicates this is the meeting url, is this old? https://zoom.us/j/336954997

tallharish (Tue, 12 Jun 2018 13:14:32 GMT):
@guyho I have the same stale entry as well.

guyho (Tue, 12 Jun 2018 13:15:07 GMT):
just dialed in, thx for posting the correct one. Will ask Mark if he can refresh the calendar invites. I rely on those :)

ikocsis (Tue, 12 Jun 2018 13:22:50 GMT):
For me, the easiest proved to be just to use https://zoom.us/my/hyperledger.community

ikocsis (Tue, 12 Jun 2018 13:23:11 GMT):
And that gets tranlated to the appropriate link

guyho (Tue, 12 Jun 2018 14:29:27 GMT):
@ikocsis thx!

Dan (Tue, 12 Jun 2018 19:28:08 GMT):
yep. the calendar never sends updates. always gotta check the HL calendar. https://wiki.hyperledger.org/community/calendar-public-meetings

neocameback (Wed, 13 Jun 2018 10:32:10 GMT):
Has joined the channel.

tungdt_socoboy (Wed, 13 Jun 2018 10:32:41 GMT):
Has joined the channel.

tallharish (Wed, 13 Jun 2018 19:34:32 GMT):
Just came across this report and thought of sharing it. Not a solid piece of worth, might still be worth a read. https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/Technology/IE_C_blockchain_performance_report.pdf

tallharish (Wed, 13 Jun 2018 19:34:32 GMT):
Just came across this report and thought of sharing it. Not a solid piece of work, might still be worth a read. https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/Technology/IE_C_blockchain_performance_report.pdf

tallharish (Wed, 13 Jun 2018 19:35:30 GMT):
Meeting summary for June 12: https://docs.google.com/document/d/1edYpoVm4L6e9z_2iXG4Q6-EQUCymaBd5TwLzS_BJ1w0/edit?usp=sharing

VipinB (Tue, 19 Jun 2018 12:46:54 GMT):
As @mwagner is away, I have volunteered to facilitate the meeting We will use the Zoom number - https://zoom.us/j/4034983298 Topics we should cover: 1) Antitrust notice -- Please make sure you are in compliance with the notice before the meeting . https://drive.google.com/file/d/0B_ObsXjgeZdNSFBrejY3MUpRMTFWQ2tDcjBmRzdDNzhoRVFZ/view 2) Assuming we will meet next week. Will many people be around on 03-July ? 3) Amsterdam Hackfest. Is anyone from this WG going ? Should we try to do anything as a WG ? 4) Move forward on the metrics document. https://docs.google.com/document/d/1DQ6PqoeIH0pCNJSEYiw7JVbExDvWh_ZRVhWkuioG4k0 Please review before the meeting. Any open comments will be discussed and hopefully resolved. Feel encouraged to use the mailing list for discussions as well. Lets wrap this important milestone up! 5) Other topics ? Notes Reminder on our online library at : https://wiki.hyperledger.org/groups/pswg/library Our "Working Documents" google Drive is here: https://drive.google.com/drive/folders/0B_NJV6eJXAA1dVZMRDNpd2RhdHM Calendar for Hyperledger public meetings https://wiki.hyperledger.org/community/calendar-public-meetings

VipinB (Tue, 19 Jun 2018 12:47:12 GMT):
That was Mark's Agenda that he sent out

toddinpal (Tue, 19 Jun 2018 12:58:47 GMT):
I will miss today's call, stuck on another call

cbf (Tue, 19 Jun 2018 13:00:45 GMT):
Hey Vipin, here to help provide additional support

VipinB (Tue, 19 Jun 2018 13:02:58 GMT):
Good Chris

ikocsis (Tue, 19 Jun 2018 13:30:34 GMT):
hi guys, sorry, in contrast to my original plans I can't participate today

cbf (Tue, 19 Jun 2018 14:00:27 GMT):
no worries, feel free to leave comments in the doc

VipinB (Tue, 19 Jun 2018 14:07:10 GMT):
Good meeting, we resolved quite a few comments...

bartman250 (Tue, 19 Jun 2018 14:54:37 GMT):
I've added my updates to the doc - hope they make sense !

VipinB (Wed, 20 Jun 2018 09:20:04 GMT):
Will check

harsha0826 (Wed, 20 Jun 2018 09:23:37 GMT):
Has joined the channel.

harsha0826 (Wed, 20 Jun 2018 10:55:18 GMT):
do anyone have idea on performance testing of API calls in blockchain?

bartman250 (Wed, 20 Jun 2018 12:53:02 GMT):
@harsha0826 - hello - in what sense do you mean?

bartman250 (Wed, 20 Jun 2018 12:53:47 GMT):
do you mean testing the performance of the apis themselves and separating that from the state persistence?

stanliberman (Wed, 20 Jun 2018 15:05:43 GMT):
Has joined the channel.

harsha0826 (Wed, 20 Jun 2018 15:47:24 GMT):
API themselves

harsha0826 (Mon, 25 Jun 2018 09:39:09 GMT):
do anyone work on caliper here ?

harsha0826 (Mon, 25 Jun 2018 09:39:17 GMT):
@rjones

klenik (Mon, 25 Jun 2018 12:17:02 GMT):
@harsha0826 I work with/on Caliper, mainly with the workload and Fabric-related parts.

harsha0826 (Tue, 26 Jun 2018 05:34:51 GMT):
what are the key performance indicators should be checked in Block Chain application?

bartman250 (Tue, 26 Jun 2018 09:47:27 GMT):
@harsha0826 -we're working through these - but the main one is 'finality' i.e. the point at which the data has reach consensus and is very hard to change

bartman250 (Tue, 26 Jun 2018 09:48:25 GMT):
this is similar to ordinary databases, in terms of the time it takes to commit a transaction

bartman250 (Tue, 26 Jun 2018 09:48:50 GMT):
the second is throughput - > i.e. how many transactions per second can the whole blockchain network process

harsha0826 (Tue, 26 Jun 2018 09:56:39 GMT):
so only two KPI's we are looking in Block chain at present? @bartman250

bartman250 (Tue, 26 Jun 2018 13:00:27 GMT):
@harsha0826 - the above are the main two - others are under discussion

mwagner (Tue, 26 Jun 2018 13:03:42 GMT):
meeting time!

mwagner (Tue, 26 Jun 2018 13:15:17 GMT):
https://docs.google.com/document/d/1DQ6PqoeIH0pCNJSEYiw7JVbExDvWh_ZRVhWkuioG4k0/edit#

tallharish (Tue, 26 Jun 2018 16:42:24 GMT):
Meeting summary for June 26: https://docs.google.com/document/d/1tqKU_dXWpY6PFQmWmcT34FYm5LkCnI2tYnETEaNFuCw/edit?usp=sharing

oborovyk (Wed, 27 Jun 2018 12:51:07 GMT):
Has joined the channel.

AbidiBassem (Fri, 29 Jun 2018 11:04:12 GMT):
Has joined the channel.

n1zyz (Mon, 02 Jul 2018 12:32:56 GMT):
Has joined the channel.

mwagner (Tue, 03 Jul 2018 12:55:58 GMT):
apologies, just got call from hospital, need to head there now for scheduled surgery, wont be on PSWG call today

guyho (Tue, 03 Jul 2018 14:19:25 GMT):
Hope all works out well for you @mwagner

gouthamkrishna31 (Tue, 03 Jul 2018 16:09:28 GMT):
Has joined the channel.

tallharish (Tue, 03 Jul 2018 16:30:29 GMT):
Meeting summary for July 3: https://docs.google.com/document/d/1aw6jkR6uA1NrcIQSRgMAtEkaWTHmFxBEDipBl_STFf4/edit?usp=sharing

tallharish (Tue, 03 Jul 2018 16:30:55 GMT):
Take care @mwagner. Wish you a speedy recovery.

mwagner (Thu, 05 Jul 2018 12:26:40 GMT):
thanks all, back home now . I will not have accew to my work email so please mwagner114@gmail.com . Already registered for the mailing list so only needed fr offlist communications

tallharish (Mon, 09 Jul 2018 00:19:51 GMT):
I might miss this Tuesday's meeting due to a deadline. I hope someone can take notes :) Thanks.

BlockExplorer (Mon, 09 Jul 2018 15:12:09 GMT):
Has joined the channel.

BlockExplorer (Mon, 09 Jul 2018 15:13:49 GMT):
Hi.. need some help about how to horizontally Scale Hyperledger fabric. For example , if the peer harddisk gets full after storing loads of data .

VipinB (Mon, 09 Jul 2018 15:46:08 GMT):
Please ask on Fabric specific channels @BlockExplorer . like #fabric

BlockExplorer (Mon, 09 Jul 2018 15:59:10 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=c6f7z27GHbdpR6ygM) @VipinB thanks, posted there. :)

rjones (Mon, 09 Jul 2018 16:26:58 GMT):
Could I ask that when you start and end your calls, you say that in the zoom chat room? Just say something like "started performance and scale call" and "ended call"? It would make my life easier tying recordings to meetings

mwagner (Mon, 09 Jul 2018 22:44:51 GMT):
@rjones sure will try to do that

rjones (Mon, 09 Jul 2018 23:15:57 GMT):
@mwagner thank you

davidorr (Tue, 10 Jul 2018 00:48:10 GMT):
Has joined the channel.

amolpednekar (Tue, 10 Jul 2018 06:21:24 GMT):
Has joined the channel.

Dan (Tue, 10 Jul 2018 13:05:17 GMT):
~~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

mwagner (Tue, 10 Jul 2018 13:26:36 GMT):
omw

guyho (Tue, 10 Jul 2018 13:56:32 GMT):
apols - have to skip today's meeting. Conflicting call

Dan (Tue, 10 Jul 2018 13:59:49 GMT):
~~~~~~~~~ End Meeting ~~~~~~~~~~~

toddinpal (Tue, 10 Jul 2018 14:13:15 GMT):
@Dan, the Tuxedo reference was with regard to distributed transaction management. Tuxedo developed the original XA protocol, which is a two phase commit protocol with presumed abort. XA is used by most middleware offerings to coordinate the updates to multiple resource managers (databases, queuing systems, etc.)

toddinpal (Tue, 10 Jul 2018 14:18:23 GMT):
In first phase of the commit, the transaction coordinator contacts each resource manager and asks them to prepare to commit, meaning that if they acknowledge they are prepared, they must be able to commit when the transaction coordinator tells them to, which usually means holding on to locks, etc. If any resource manager indicates it can't be prepared, the transaction coordinator tells all the resource managers to rollback their transaction branches. If they all indicate they can commit, then the transaction coordinator creates a persistent commit log entry and effectively at that point the transaction is committed, i.e., cannot be undone. The transaction coordinator then tells each of the resource managers to proceed with committing their branches. The presumed abort bit means that if there is an error, in general things get rolled back.

toddinpal (Tue, 10 Jul 2018 14:19:58 GMT):
There is a possibility for lack of agreement or integrity if a resource manager indicates it can commit, and then due to some catastrophic failure cannot commit, the transaction may end up being only partially committed, i.e., a heuristic outcome that must be resolved by some manual steps

toddinpal (Tue, 10 Jul 2018 14:20:31 GMT):
So in XA, finality is when the commit log entry is made by the transaction coordinator.

toddinpal (Tue, 10 Jul 2018 15:08:42 GMT):
@Dan was that what you were looking for?

toddinpal (Tue, 10 Jul 2018 15:11:25 GMT):
Regarding the discussion this morning, I think it is important to focus on finality instead of commitment, although it would be useful to have a table in an appendix that provides the differences between committed and final for the more common blockchains as a point of illustration.

lay-z (Tue, 10 Jul 2018 15:51:49 GMT):
Has joined the channel.

alokmatta (Tue, 10 Jul 2018 23:45:13 GMT):
Has joined the channel.

NoLimitHoldem (Wed, 11 Jul 2018 06:42:49 GMT):
Has joined the channel.

Dan (Wed, 11 Jul 2018 13:48:50 GMT):
@toddinpal yes, that's helpful thanks. Regarding finality, I'll need to revisit the consensus doc by the arch group. I'm hoping we can just find some existing text there then dealing with this rather nasty can of wor[d,m]s.

duncanjw (Fri, 13 Jul 2018 14:46:38 GMT):
Has joined the channel.

neewy (Mon, 16 Jul 2018 13:31:32 GMT):
Has joined the channel.

ales100 (Mon, 16 Jul 2018 13:42:19 GMT):
Has joined the channel.

guyho (Mon, 16 Jul 2018 18:47:08 GMT):
Sorry, won't be able to make tomorrow's call. Conflict again.

mwagner (Mon, 16 Jul 2018 19:08:26 GMT):
@guyho, you seem so conflicted lately....

mwagner (Tue, 17 Jul 2018 13:03:50 GMT):
~~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

neewy (Tue, 17 Jul 2018 13:08:55 GMT):
Right, I was really frustrated to find out anyone can edit directly.

neewy (Tue, 17 Jul 2018 13:09:36 GMT):
Google docs are fine, just leave everyone in suggest mode

neewy (Tue, 17 Jul 2018 13:09:47 GMT):
In the end you would have to merge it :)

mwagner (Tue, 17 Jul 2018 13:23:05 GMT):
Gold Star to Dan!!

mwagner (Tue, 17 Jul 2018 13:36:37 GMT):
Does Dans audio break up for other people or is it on my end ?

tallharish (Tue, 17 Jul 2018 13:52:37 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=6bsRCdhhp6rrYkRoS) @mwagner Yes it does. Every few mins.

mwagner (Tue, 17 Jul 2018 13:57:17 GMT):
~~~~~~~~~ End Meeting ~~~~~~~~~~~

tallharish (Tue, 17 Jul 2018 16:56:29 GMT):
Meeting summary for July 17: https://docs.google.com/document/d/12P7i35oZcohoFCh5lTUX5oA0W4v5gQ3nmjAI7yQXOjY/edit?usp=sharing

kodonnel (Wed, 18 Jul 2018 15:03:26 GMT):
Has joined the channel.

VipinB (Fri, 20 Jul 2018 11:37:24 GMT):
Interesting discussion on Performance & Scale WG mailing list on papers published on papers https://arxiv.org/abs/1805.11390 and of course https://arxiv.org/abs/1801.10228, I will tke a closer look at them to see whether they offer any lessons for the metrics definition. Obviously neither of them follow the metrics or other definitions that we have been creating.

VipinB (Fri, 20 Jul 2018 11:37:24 GMT):
Interesting discussion on Performance & Scale WG mailing list on papers published on performance https://arxiv.org/abs/1805.11390 and of course https://arxiv.org/abs/1801.10228, I will take a closer look at them to see whether they offer any lessons for the metrics definition. Obviously neither of them follow the metrics or other definitions that we have been creating.

VipinB (Fri, 20 Jul 2018 11:38:31 GMT):
They are specifically for Fabric

hiteshkhamesra (Fri, 20 Jul 2018 16:47:23 GMT):
Has joined the channel.

guyho (Tue, 24 Jul 2018 12:13:36 GMT):
Apols - have another conflict for today's meeting.

mwagner (Tue, 24 Jul 2018 13:11:00 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

Dan (Tue, 24 Jul 2018 14:16:03 GMT):
~~~~~ End meeting -15 min ~~~~~

tallharish (Tue, 24 Jul 2018 14:25:33 GMT):
Meeting summary for July 24: https://docs.google.com/document/d/15PZD7vSsoNuxDeU33X0iHWpc4sH7pwEn9QA5r8EzLjM/edit

arati_baliga (Fri, 27 Jul 2018 09:55:30 GMT):
Has joined the channel.

arati_baliga (Fri, 27 Jul 2018 10:13:39 GMT):
Hello folks. I just joined today. We, at Persistent Systems have done some work on performance benchmarking of Fabric and Quorum.

arati_baliga (Fri, 27 Jul 2018 10:18:09 GMT):
Below are the papers. ```1. Performance Characterization of Hyperledger Fabric - presented at the 1st Crypto Valley Conference on Blockchain Technology, 2018, Zug, Switzerland. (https://www.persistent.com/wp-content/uploads/2018/07/research-paper-performance-characterization-of-hyperledger-fabric.pdf)```2. Performance Evaluation of the Quorum Blockchain Platform (https://www.persistent.com/wp-content/uploads/2018/07/research-paper-performance-evaluation-of-the-quorum-blockchain-platform.pdf)```Could these be posted to the PSWG library since they are relevant contributions ? Thanks ! ``` ``` ```

arati_baliga (Fri, 27 Jul 2018 10:20:45 GMT):
1. Performance Characterization of Hyperledger Fabric (https://www.persistent.com/wp-content/uploads/2018/07/research-paper-performance-characterization-of-hyperledger-fabric.pdf). 2. Performance Evaluation of the Quorum Blockchain Platform (https://www.persistent.com/wp-content/uploads/2018/07/research-paper-performance-evaluation-of-the-quorum-blockchain-platform.pdf).

arati_baliga (Fri, 27 Jul 2018 10:21:44 GMT):
Paper 1 was presented at the First Crypto Valley Conference on Blockchain Technology, 2018 at Zug, Switzerland last month.

arati_baliga (Fri, 27 Jul 2018 10:23:20 GMT):
Considering the relevance of the contributions, may I request that the papers be added to the PSWG library ? Thanks.

ericmvaughn (Fri, 27 Jul 2018 15:29:47 GMT):
Has joined the channel.

NoLimitHoldem (Mon, 30 Jul 2018 02:33:04 GMT):
Hey everyone, I have generated ~20 million transactions (I have set number of transactions per block to 50). And it seems more the blocks/data or larger the ledger/chain, the network performance is worser (in terms of TPS). Particularly, peers' disk utilization is getting higher and higher. Is it normal?

mwagner (Tue, 31 Jul 2018 13:06:45 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

iserikov (Tue, 31 Jul 2018 13:11:32 GMT):
Has joined the channel.

ikocsis (Tue, 31 Jul 2018 13:13:59 GMT):
@mwagner - Mark, with reference to what you mentioned during the call: for a number of reasons I had to fall off the loop for the last two+ weeks, so I really don't know who should be considered a regular contributor and who not; if I am and you need my mail address, it's ikocsis@mit.bme.hu

mwagner (Tue, 31 Jul 2018 13:16:25 GMT):
@ikocsis you are on the list , thanks for the email addr

mwagner (Tue, 31 Jul 2018 14:01:08 GMT):
~~~~~ End meeting ~~~~~

tallharish (Tue, 31 Jul 2018 16:25:57 GMT):
Meeting summary for July 31: https://docs.google.com/document/d/1URjdq8uFvJxSlL0DUK2pqtanu4yXSJJBnQ_aUX0io74/edit?usp=sharing

jg507 (Tue, 31 Jul 2018 21:17:36 GMT):
Has joined the channel.

mwagner (Wed, 01 Aug 2018 01:42:05 GMT):
@arati_baliga thanks for the heads up. I will review them and bring to the PSWG as appropriate

mwagner (Wed, 01 Aug 2018 01:44:03 GMT):
@NoLimitHoldem Cant tell from your description, some blockchains slow down when the data needs to get replicated everywhere . Best to ask on the mailing list / chat channel of the DLT you are testing

raspydev (Thu, 02 Aug 2018 16:55:49 GMT):
Has joined the channel.

guyho (Tue, 07 Aug 2018 04:25:52 GMT):
Unable to make call Tuesday this week.

mwagner (Tue, 07 Aug 2018 13:03:04 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

mwagner (Tue, 07 Aug 2018 14:01:14 GMT):
~~~~~ End meeting ~~~~~

tallharish (Tue, 07 Aug 2018 16:53:44 GMT):
Meeting summary for Aug. 7: https://docs.google.com/document/d/1E99orobYftxRu3bbfO-8KlzqEhLGF23OBbPJFV2unMc/edit?usp=sharing

VipinB (Tue, 07 Aug 2018 17:14:30 GMT):
There is a freely available ebook on chaos engineering from oreilly that can help with the faultload topic, there is a github repo on chaos tools that could use a blockchain variant to be incorporated into tools like Caliper.

VipinB (Tue, 07 Aug 2018 17:15:39 GMT):
https://github.com/chaostoolkit

mwagner (Tue, 07 Aug 2018 18:11:53 GMT):
cool

VipinB (Tue, 07 Aug 2018 19:52:17 GMT):
Someone will have to write a blockchain variant for chaos tools, this will be a worthwhile endeaviur

VipinB (Tue, 07 Aug 2018 19:52:17 GMT):
Someone will have to write a blockchain variant for chaos tools, this will be a worthwhile endeavour

ChunTung (Wed, 08 Aug 2018 03:15:37 GMT):
Has joined the channel.

nrohith (Wed, 08 Aug 2018 17:23:08 GMT):
Has joined the channel.

mwagner (Tue, 14 Aug 2018 11:59:36 GMT):
meeting starts in one hour, grab some extra coffee :)

mwagner (Tue, 14 Aug 2018 13:03:59 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

tallharish (Tue, 14 Aug 2018 13:56:23 GMT):
@toddinpal can you point the sentences where propogation delay is missing? I agree with your point

mwagner (Tue, 14 Aug 2018 14:06:00 GMT):
~~~~~ End meeting ~~~~~

tallharish (Tue, 14 Aug 2018 15:10:19 GMT):
Meeting summary for Aug 14: https://docs.google.com/document/d/1QY_soPzLS9X1DLUN7Wt0qyHlo49M2-3kSe5XaSUMbO8/edit?usp=sharing

haggs (Tue, 14 Aug 2018 15:55:32 GMT):
Has joined the channel.

manuvarghese (Tue, 14 Aug 2018 22:23:49 GMT):
Has joined the channel.

gvorsanger (Mon, 20 Aug 2018 15:13:44 GMT):
Has joined the channel.

mwagner (Tue, 21 Aug 2018 12:02:09 GMT):
meeting in 58 minutes

Dan (Tue, 21 Aug 2018 12:34:37 GMT):
T-26 Min

mwagner (Tue, 21 Aug 2018 13:03:41 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

Dan (Tue, 21 Aug 2018 13:06:23 GMT):
my audio is dropping going to reconnect

Dan (Tue, 21 Aug 2018 13:06:36 GMT):
ok back

tallharish (Tue, 21 Aug 2018 13:26:12 GMT):
in the original document "query" writeup appeared after "read", but its reversed now. So need to modify writeup accordingly or change the ordering

guyho (Tue, 21 Aug 2018 13:41:36 GMT):
sorry, have to drop

mwagner (Tue, 21 Aug 2018 13:41:59 GMT):
bye

mwagner (Tue, 21 Aug 2018 13:59:52 GMT):
~~~~~ End meeting ~~~~~

tallharish (Tue, 21 Aug 2018 17:17:06 GMT):
Meeting summary for Aug 21: https://docs.google.com/document/d/17H5y3AGW42Z7HkiQRFN4uZsWYxaYJgi7T4eFbBekU5o/edit?usp=sharing

toddinpal (Mon, 27 Aug 2018 18:44:20 GMT):
Where are the recordings for the last few months of meetings? I don't see anything past March of this year

mwagner (Mon, 27 Aug 2018 19:30:11 GMT):
Let me check

mwagner (Mon, 27 Aug 2018 19:45:52 GMT):
@toddinpal I am updating the wiki page now, any particular week you are most interested in ?

mwagner (Mon, 27 Aug 2018 20:45:22 GMT):
@toddinpal recordings updated, will keep going to add meeting minutes

mwagner (Mon, 27 Aug 2018 20:45:34 GMT):
https://wiki.hyperledger.org/groups/pswg/performance-and-scale-wg/meetingminutes

mwagner (Tue, 28 Aug 2018 12:40:04 GMT):
meeting starts in 20 minutes or so

guyho (Tue, 28 Aug 2018 12:58:47 GMT):
Apols - have a boatload of activity to deal with this morning, have to bail on our call again. :(

mwagner (Tue, 28 Aug 2018 13:03:46 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

mwagner (Tue, 28 Aug 2018 14:02:21 GMT):
~~~~~ End meeting ~~~~~

tallharish (Tue, 28 Aug 2018 14:16:21 GMT):
@mwagner let me know which dates are you missing for meeting minutes, I can search quickly for the link.

tallharish (Tue, 28 Aug 2018 14:16:21 GMT):
@mwagner for which dates are you missing for meeting minutes? I can search for the links quickly. I missed a few meetings, so we might not have anything to share there.

huxiangdong (Thu, 30 Aug 2018 09:03:36 GMT):
Has joined the channel.

demonkm (Mon, 03 Sep 2018 06:59:09 GMT):
Has joined the channel.

toddinpal (Tue, 04 Sep 2018 12:55:32 GMT):
Do we have a call today?

tallharish (Tue, 04 Sep 2018 12:58:50 GMT):
Meeting summary for Aug 28: https://docs.google.com/document/d/10fw2MyA_rnI5GruN9BgYYDGodyaIJaWUDdZ9SlZRBIw/edit (Forgot to post this earlier, apologies)

toddinpal (Tue, 04 Sep 2018 13:02:46 GMT):
Begin meeting

tallharish (Tue, 04 Sep 2018 14:19:11 GMT):
End meeting.

tallharish (Tue, 04 Sep 2018 14:19:32 GMT):
Meeting summary for Sep 4: https://docs.google.com/document/d/17IzLQnRU1xl4_kcOwcVM0Y3TkhIuWcA4imOplxbOpOI/edit?usp=sharing

rodolfoleal (Tue, 04 Sep 2018 21:41:51 GMT):
Has joined the channel.

mighty-pirate (Thu, 06 Sep 2018 17:57:29 GMT):
Has joined the channel.

mwagner (Tue, 11 Sep 2018 13:01:36 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

mwagner (Tue, 11 Sep 2018 14:06:05 GMT):
~~~~~ End meeting ~~~~~

tallharish (Tue, 11 Sep 2018 14:40:08 GMT):
Meeting summary for Sep 11: https://docs.google.com/document/d/18M5colIeKf4dRTE46C5Q70Roa0TeTriEWn9S1VWG58w/edit Almost there with the document.

mwagner (Tue, 11 Sep 2018 19:54:42 GMT):
@toddinpal @Dan did you two get a chance to connect ? need anything from me or the community ?

toddinpal (Tue, 11 Sep 2018 21:15:35 GMT):
We didn't reach consensus... trying again tomorrow morning

Dan (Tue, 11 Sep 2018 22:03:20 GMT):
After an hour we hadn't even formed the transaction :)

mwagner (Wed, 12 Sep 2018 13:19:56 GMT):
I can commit some time to help today if needed

Dan (Wed, 12 Sep 2018 14:39:04 GMT):
Cool thanks. We just concluded that there's not a meaningful second definition of latency. However the process to get there involved diagraming and so we are going to try to make those diagrams presentable and put them in the appendix examples.

Dan (Wed, 12 Sep 2018 14:55:17 GMT):
@toddinpal fyi, a general diagram for random leader election is yucky. So I'm going to model one specifically on the example in the appendix that it's going to be attached to.

VipinB (Wed, 12 Sep 2018 15:00:18 GMT):
So what are the general ideas you are stuck on? Please put it succinctly(less than 30 words) @Dan @toddinpal , sometimes just restating can let us see where there are common points.

Dan (Wed, 12 Sep 2018 15:06:33 GMT):
Not stuck. Just realized when we look at the castro diagram and talk about the other protocols that the definition we have seems to cover all of them. The exercise of looking at the diagram was instructive so we are going to try to capture that in the doc so it's clear to others too.

Dan (Wed, 12 Sep 2018 15:07:01 GMT):
Now the trick will be making simple diagrams that relate to the examples.

mwagner (Wed, 12 Sep 2018 15:08:58 GMT):
You can expense some crayons if that helps....

Dan (Wed, 12 Sep 2018 15:12:36 GMT):
:crayon:

mwagner (Wed, 12 Sep 2018 17:51:18 GMT):
must say I don't what a castro diagram is...:/ google and wikipedia don't help

mwagner (Wed, 12 Sep 2018 17:52:14 GMT):
but I would say it doesn't need to be perfect, just capture the basics / general view and we can have the designers finish it up

Dan (Wed, 12 Sep 2018 20:05:23 GMT):
Yeah I tucked one of the diagrams in then got sucked into a meeting... (the diagram I was referencing is the PBFT diagram in the paper by Castro et al. ) Incidentally I don't know what the rules are for copying that graphic into our paper. I guess we can just cite the image? See fig 1: http://pmg.csail.mit.edu/papers/osdi99.pdf

Dan (Wed, 12 Sep 2018 20:49:28 GMT):
Ok, I'm happy with the additions to the examples. I pasted in a the graphic from the pbft paper with a link for citation. If someone who is practiced at writing citations can fill that in properly at the end of the doc that would be cool.

Dan (Wed, 12 Sep 2018 20:49:59 GMT):
@toddinpal will probably be adding one more example - time permitting.

toddinpal (Wed, 12 Sep 2018 21:21:24 GMT):
Yeah, I'm trying to create an equivalent diagram for Fabric

Dan (Wed, 12 Sep 2018 21:22:45 GMT):
Note I updated the labels at the top of my diagram to better align with the castro labels

Dan (Wed, 12 Sep 2018 21:22:56 GMT):
(vs. what I sent you earlier in ppt)

toddinpal (Wed, 12 Sep 2018 21:28:12 GMT):
ok

mwagner (Thu, 13 Sep 2018 01:52:46 GMT):
thanks gents

VipinB (Thu, 13 Sep 2018 13:24:34 GMT):
@toddinpal Is BFT or PBFT in prod on Fabric? I only see solo and Kafka in 1.2

toddinpal (Thu, 13 Sep 2018 15:25:08 GMT):
No, Kafka and Solo are the only ordering services in Fabric 1.2

mwagner (Thu, 13 Sep 2018 17:15:19 GMT):
@toddinpal @Dan is the document ready for group review yet ? If so can someone send an email or let me know and I will.

Dan (Thu, 13 Sep 2018 18:07:36 GMT):
I think my work was done. @toddinpal if you want to accept the proposed text for latency that I put in last weekend we can 'finalize' that part. If you want me to check in on your fabric example / diagram let me know. I don't have the doc up now to see if it's in.

mwagner (Thu, 13 Sep 2018 18:26:02 GMT):
btw, Gordon is tweaking now

tallharish (Thu, 13 Sep 2018 23:49:30 GMT):
@Dan @toddinpal I like the concepts introduced with the new figures.. I made the following figures, let me know if you find them more suitable, I can share the source in my github. Copyright free :)

tallharish (Thu, 13 Sep 2018 23:49:48 GMT):

prob_finality.jpg

tallharish (Thu, 13 Sep 2018 23:49:49 GMT):

pbft_finality.jpg

tallharish (Fri, 14 Sep 2018 00:06:49 GMT):
@Dan I added minor edits to Case 3 to make wordings clear. Should be a quick review.

tallharish (Fri, 14 Sep 2018 12:57:05 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=Jf7rEeA2RbNXpvBP6) Should have mentioned that the horizontal bars are block execution time. for respective blocks.

Dan (Fri, 14 Sep 2018 13:12:11 GMT):
@tallharish nice diagrams!

Dan (Fri, 14 Sep 2018 13:20:28 GMT):
@tallharish Feel free to drop those in to replace the ones I put. I accepted the wording changes you suggested. Feel free to resolve other text that you have reviewed.

tallharish (Fri, 14 Sep 2018 14:00:20 GMT):
@Dan: Thanks. Please review my changes on Appendix Case 3. And I will accept yours from Case 1, 2. For Case 2, perhaps we can go for a smaller example with 5-7 nodes, just to save space. We all know Sawtooth and PoET can scale well :sunglasses:

tallharish (Fri, 14 Sep 2018 14:00:20 GMT):
@Dan: Thanks. Please review my changes on Appendix Case 3. And I will accept yours from Case 1, 2. For Case 2, perhaps we can go for a smaller example with 5-7 nodes. We all know Sawtooth and PoET can scale well :sunglasses:

tallharish (Fri, 14 Sep 2018 14:01:17 GMT):
I will include the figures in document as well as high reso ones in Repo. For Gordon

Dan (Fri, 14 Sep 2018 14:01:47 GMT):
yeah i thought about using a smaller case, but it seemed like that might misconstrue part of the difference. I imagine the layout person can split the table in formatting so it's in columns and takes up less space.

Dan (Fri, 14 Sep 2018 14:01:59 GMT):
What did you end up using for creating your drawings?

tallharish (Fri, 14 Sep 2018 14:02:24 GMT):
i used libre draw. So you can edit it using libre or openoffice. Free and open-source

tallharish (Fri, 14 Sep 2018 14:21:24 GMT):
@Dan I resolved all yours and Gordan's comments. Only my comments remain, please review and accept. #BuddyCheck

mwagner (Fri, 14 Sep 2018 17:43:54 GMT):
@Dan @tallharish @VipinB @toddinpal Thanks to all who have really busted over the last few weeks to push this document through

mwagner (Fri, 14 Sep 2018 18:57:11 GMT):
Time to push the button on getting the doc out for the next steps. can folks reply to email thread and let us know if you agree or disagree please

mwagner (Tue, 18 Sep 2018 13:07:32 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

mwagner (Tue, 18 Sep 2018 13:07:32 GMT):
~~~~~~~~~~ End Meeting ~~~~~~~~~~~~~

tallharish (Tue, 18 Sep 2018 14:44:06 GMT):
Meeting summary for Sep 18 - https://docs.google.com/document/d/1k3JC3Yoc1NKPypJSPonQg8HlkRVTjj6s-m54cZuimOo/edit?usp=sharing

tallharish (Tue, 18 Sep 2018 14:45:22 GMT):
Great discussions. Good to dive head-first into the new document. Please suggest any missed point into the meeting summary.

toddinpal (Tue, 18 Sep 2018 16:37:11 GMT):
Can I suggest that as people feel inclined, to start writing down ideas about independent variables and also about use cases and share them among the group?

mwagner (Thu, 20 Sep 2018 15:14:50 GMT):
Just to let folks know, the TSC approved our paper with minor addition. Thanks to all for the hard work !

mwagner (Thu, 20 Sep 2018 15:15:44 GMT):
The addition is saying something to the effect that "this document is intended to be a starting point for discussion"

rajanashutosh (Fri, 21 Sep 2018 05:47:25 GMT):
Has joined the channel.

tallharish (Tue, 25 Sep 2018 00:31:22 GMT):
:tyvm:

tallharish (Tue, 25 Sep 2018 00:31:22 GMT):
:woo:

tallharish (Tue, 25 Sep 2018 00:31:55 GMT):
Woohoo !

mwagner (Tue, 25 Sep 2018 13:30:16 GMT):
was a quick meeting with only a few people today

VipinB (Tue, 25 Sep 2018 19:58:32 GMT):
Could not attend due to multiple conflicts. Hope to see y'all in Montreal

Dan (Wed, 26 Sep 2018 13:10:48 GMT):
Mais oui!

NoLimitHoldem (Fri, 28 Sep 2018 09:43:29 GMT):
Is there a max storage limit of Hyperledger Fabric? Such as, in the case of 6xTB or some other numbers... If so, in case that number is reached, what should we do?

NoLimitHoldem (Fri, 28 Sep 2018 09:43:45 GMT):
Also, I found that when the ledger size for 1 channel grows, the TPS is getting worse. In my 600 users simulation case, the rough correlation of TPS and # of transactions made (each is roughly 2.8x-3.x KB, the transaction just does a simple PutState) is -0.6. Anyone try more about that?

mwagner (Sun, 30 Sep 2018 13:43:10 GMT):
@NoLimitHoldem You should ask on the fabric channels, they should have better information

iserikov (Mon, 01 Oct 2018 15:15:54 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=Y3eoGxvQyNrJEzY9W) @NoLimitHoldem Tobby. Good day! Could you share info about your research? We are also having case where large amount of ledger is needed.

phaniac (Mon, 01 Oct 2018 18:14:17 GMT):
Has joined the channel.

bairathirahul (Mon, 01 Oct 2018 18:26:23 GMT):
Has joined the channel.

NoLimitHoldem (Tue, 02 Oct 2018 06:04:58 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=pZvuXbFBotAk9TNcz) @mwagner Thanks for reminding :)

NoLimitHoldem (Tue, 02 Oct 2018 06:05:36 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=K5GsGXpd3uq2HLzS2) @iserikov Seems there is no such limit, read some replies to my questions in fabric-quality channel

ghochstetler (Tue, 02 Oct 2018 13:01:33 GMT):
Has joined the channel.

antoniovassell (Tue, 02 Oct 2018 15:28:33 GMT):
Has joined the channel.

cinnnn (Wed, 03 Oct 2018 07:58:08 GMT):
Has joined the channel.

rajasushanth (Wed, 03 Oct 2018 16:14:53 GMT):
Has joined the channel.

uherr89 (Wed, 03 Oct 2018 18:53:02 GMT):
Has joined the channel.

rajanashutosh (Thu, 04 Oct 2018 04:22:13 GMT):
hi all, Need help on performing the load and performance tests. I have a fabric network with following architecture. Fabric network contains 3 Zookeepers containers, 4 Kafka brokers, 3 Orderers, 4 Organizations ( Each org has 1 dedicated CA, 2 Peers and dedicated CouchDb). They are deployed on to three VMs. \

rajanashutosh (Thu, 04 Oct 2018 04:23:04 GMT):
Being a multi-host environment we use docker swarm for clustering between VMs.

rajanashutosh (Thu, 04 Oct 2018 04:23:46 GMT):
Java SDK interacts with our Fabric network on top of which I have Spring to expose REST apis.

rajanashutosh (Thu, 04 Oct 2018 04:25:12 GMT):
While testing our throughput was stuck on 40 tps (Write), which after modifications on docker containers and swarm network (already and open issue) got increased to 200 tps.

rajanashutosh (Thu, 04 Oct 2018 04:25:37 GMT):
Kindly request you to please suggest where I might be wrong.

rajanashutosh (Thu, 04 Oct 2018 04:26:10 GMT):
Our CPU is 4 core with 20 gigs of ram.

fabienvicard (Thu, 04 Oct 2018 14:45:42 GMT):
Has joined the channel.

GowthamG (Fri, 05 Oct 2018 16:51:26 GMT):
Has joined the channel.

MatthewRubino (Mon, 08 Oct 2018 15:47:01 GMT):
Has joined the channel.

mwagner (Tue, 09 Oct 2018 13:09:57 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

mwagner (Tue, 09 Oct 2018 13:10:53 GMT):
from gordon https://www.gdf.io/

mwagner (Tue, 09 Oct 2018 14:01:32 GMT):
~~~~~~~~~~ end Meeting ~~~~~~~~~~~~~

raccoonrat (Wed, 10 Oct 2018 02:54:04 GMT):
Has joined the channel.

tkg (Fri, 12 Oct 2018 18:33:50 GMT):
Has joined the channel.

SumanPapanaboina (Sun, 14 Oct 2018 15:36:23 GMT):
Has joined the channel.

tahaf10 (Mon, 15 Oct 2018 10:06:31 GMT):
Has joined the channel.

tahaf10 (Mon, 15 Oct 2018 12:19:21 GMT):
Me and my team are considering conducting a research on performance optimization on a Hyperledger platform. If you have any ideas relating to that please let me know

VipinB (Mon, 15 Oct 2018 14:12:40 GMT):
@tahaf10 integral to any performance optimization would be the concept of measurement, for this we have a series of metrics defined in the PSWG paper, as well as a tool to conduct measurement as in #caliper . Which specific dlt are you interested in tuning? HL fabric, HL Sawtooth, others? There are efforts and papers in each of these platforms towards that end.

siva.a (Mon, 15 Oct 2018 17:44:57 GMT):
Has joined the channel.

tahaf10 (Tue, 16 Oct 2018 09:18:45 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=r6zsquDPHCbXQx7qR) @VipinB I'm still considering which Platform to go with. Which is why I wanted to get your valuable opinion on this. Most of my work has been on Hyperledger Fabric, and I'm particularly interested in the new concept of deploying Solidity based Smart Contracts on Fabric but I'm definitely open to learning new things. I was also looking at https://www.hyperledger.org/resources/research-topics & the optimization topic interests me the most

ghochstetler (Tue, 16 Oct 2018 12:54:48 GMT):
Sorry to have missed last week's call. Looks like I have to bail again today :(

VipinB (Tue, 16 Oct 2018 13:07:28 GMT):
Will have to bail around 30 minutes

mwagner (Tue, 16 Oct 2018 13:12:41 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

mwagner (Tue, 16 Oct 2018 13:12:59 GMT):
https://gitlab.com/emerald-platform/emerald/wikis/emerald%20benchmark

mwagner (Tue, 16 Oct 2018 13:36:40 GMT):
https://github.com/shadow/shadow

VipinB (Tue, 16 Oct 2018 16:41:15 GMT):
Mark Simpson (cant find your RC moniker) if you are here and need to look at what it takes to get stuff into labs https://wiki.hyperledger.org/labs

VipinB (Tue, 16 Oct 2018 16:41:33 GMT):
Hope you bring emerald along

VipinB (Tue, 16 Oct 2018 16:56:59 GMT):
*From Shadow FAQ: My interpolations are in bold* Shadow is a network simulator/emulator hybrid. It runs real applications, but it simulates network and system functions thereby emulating the kernel to the application. The suitability of Shadow to your problem depends upon what exactly you are trying to measure. *What it can do*: If you are interested in analyzing changes in application behavior, e.g. application layer queuing, failure modes, or design changes, and how those changes affect the operation of the system and network performance, then Shadow seems like a very good choice (especially if you want to minimize work on your end). *What it is not intended to do*: If your research relies on, e.g., the accuracy of specific kernel features or kernel parameter settings, or dynamic changes in Internet routing, then Shadow may not be the right choice as it does not precisely model these behaviors. Shadow is also not the best at measuring cryptographic overhead, so if that is desired then it should probably be done more directly as a separate research component.

VipinB (Tue, 16 Oct 2018 17:00:08 GMT):
Since consensus algorithms rely on some of the functions in the section outside of what shadow supports, I get the feeling that research into complex interactions along those lines may be difficult to do. I must confess that I have not looked at Shadow in depth, so I may be completely off base here.

VipinB (Tue, 16 Oct 2018 18:55:31 GMT):
Please see: http://www.dtcc.com/news/2018/october/16/dtcc-unveils-groundbreaking-study-on-dlt for some performance numbers...

VipinB (Tue, 16 Oct 2018 19:13:25 GMT):
Another one: https://www.gft.com/int/en/index/company/newsroom/press-releases/2018/gft-tests-performance-of-digital-asset-platform-exceeding-peak-equity-trade-volumes/

mwagner (Tue, 16 Oct 2018 19:19:39 GMT):
#labs

VipinB (Tue, 16 Oct 2018 20:01:28 GMT):
Obviously marketing based posts, but some interesting things become apparent when you look at these numbers.

Dan (Tue, 16 Oct 2018 23:54:13 GMT):
It looks like the GFT paper quotes our paper but then ignores the critical part of that, that performance should be reported in the context of the network size. It later reads to me that the test network had a single point of failure. "There is one dedicated clearinghouse node for each exchange."

push1st1k (Wed, 17 Oct 2018 11:25:06 GMT):
Has joined the channel.

VipinB (Wed, 17 Oct 2018 12:38:21 GMT):
They are doing this in the context of DTCC, and DAH is also working with ASX; both of these are very established and powerful entities. So I agree with you @Dan, they are not going to the pure solution. However it is possible that the matching and clearing functions can be automated and the matching and clearing will become less central as adoption takes hold. This was my argument to them when DAH/DTCC were sketching out Repo Trading, DTCC wanted to host nodes and I was arguing that the second phase should consider a more decentralized structure. Incremental change, rather than wholesale change. There are two other interesting points 1. The definition of transaction from the business point of view rather than the blockchain point of view 2.They give some sense of scale: "Since each DA Platform Node and DAML Application is comprised of multiple software components, many are deployed in separate Kubernetes pods. In this particular example, each exchange is deployed to the same pod as a trade injector, because they scale together, but each exchange-trade injector pair is in its own pod; in this simulation, *there are 25 such pairs*." You are right that they try to reproduce existing processes rather than seeing how the Business Process could be redesigned. As is evident from their description:

VipinB (Wed, 17 Oct 2018 12:39:57 GMT):
They attribute SUT etc. to Caliper...They do not seem to say anything about the PSWG

wyatt-noise (Thu, 18 Oct 2018 14:18:26 GMT):
Has joined the channel.

yusra (Sun, 21 Oct 2018 06:48:57 GMT):
Has joined the channel.

tian (Tue, 23 Oct 2018 06:47:02 GMT):
Has joined the channel.

mwagner (Tue, 23 Oct 2018 13:04:06 GMT):
anyone elso coming to the meeting ?

ikocsis (Tue, 23 Oct 2018 13:05:53 GMT):
yep

ikocsis (Tue, 23 Oct 2018 13:05:56 GMT):
2 minutes

mwagner (Tue, 23 Oct 2018 13:07:44 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

mwagner (Tue, 23 Oct 2018 13:56:40 GMT):
~~~~~~~~~~ End Meeting ~~~~~~~~~~~~~

iamsteveng (Wed, 24 Oct 2018 10:04:01 GMT):
Has joined the channel.

cagdast (Thu, 25 Oct 2018 08:25:11 GMT):
Has joined the channel.

MatthewRubino (Fri, 26 Oct 2018 13:00:29 GMT):
Has left the channel.

RajuSomala (Mon, 29 Oct 2018 09:36:37 GMT):
Has joined the channel.

houqinghui (Tue, 30 Oct 2018 07:54:02 GMT):
Has joined the channel.

houqinghui (Tue, 30 Oct 2018 08:02:01 GMT):
do we have the meeting memo of PSWG everyweek?

houqinghui (Tue, 30 Oct 2018 08:02:57 GMT):
where can i find it ? i want to read it .

mwagner (Tue, 30 Oct 2018 13:03:07 GMT):
I send the agenda to the perf mailing list every week.

mwagner (Tue, 30 Oct 2018 13:03:30 GMT):
I will not be able to join the call today, internal all hands meetings

ikocsis (Tue, 30 Oct 2018 14:09:21 GMT):
Hi guys, I'm terribly sorry I missed the call unintentionally... We just changed back from summer time and I didn't realize this has an impact on the meeting time :( Did anyone take notes?

mwagner (Tue, 30 Oct 2018 17:27:02 GMT):
@ikocsis I was not on the call either. Note that the US changes back to normal time this upcoming weekend so things should be back to normal

mwagner (Tue, 30 Oct 2018 17:27:06 GMT):
next week

shw8927 (Thu, 01 Nov 2018 01:14:43 GMT):
Has joined the channel.

karthikmohan91 (Fri, 02 Nov 2018 04:46:04 GMT):
Has joined the channel.

denis3007 (Fri, 02 Nov 2018 10:43:05 GMT):
Has joined the channel.

mwagner (Tue, 06 Nov 2018 12:30:57 GMT):
PSWG weekly call starts in 90 minutes!

mwagner (Tue, 06 Nov 2018 12:31:04 GMT):
;)

houqinghui (Tue, 06 Nov 2018 13:06:23 GMT):
no body

mwagner (Tue, 06 Nov 2018 13:26:39 GMT):
another 33 mins to start

laurasp (Thu, 08 Nov 2018 10:59:42 GMT):
Has joined the channel.

luxus (Mon, 12 Nov 2018 01:56:33 GMT):
Has joined the channel.

ghochstetler (Tue, 13 Nov 2018 13:57:09 GMT):
Apols guys. I've a conflict again today.

mwagner (Tue, 13 Nov 2018 14:02:38 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

VipinB (Tue, 13 Nov 2018 15:23:58 GMT):
Good meeting today!

Silona (Wed, 14 Nov 2018 21:40:18 GMT):
Has joined the channel.

mavericklam (Tue, 20 Nov 2018 02:10:39 GMT):
Hello, I am using Hyperledger Fabric 1.3 and I set up the balance transfer example on VM. However I found the peer is using many space and generate 7G data per day. Is there anything wrong in my configuration? Thanks for your help

VipinB (Tue, 20 Nov 2018 12:40:30 GMT):
@mavericklam better asked in #fabric channel

ghochstetler (Tue, 20 Nov 2018 13:25:56 GMT):
Client meeting conflict today.

mwagner (Tue, 20 Nov 2018 13:30:35 GMT):
@ghochstetler have fun!

mwagner (Tue, 20 Nov 2018 14:05:43 GMT):
~~~~~~~~~~ Begin Meeting ~~~~~~~~~~~~~

sergey.khoroshavin (Tue, 20 Nov 2018 14:48:42 GMT):
Has joined the channel.

Silona (Tue, 20 Nov 2018 14:50:20 GMT):
Great Presentation by @sergey.khoroshavin https://docs.google.com/presentation/d/1tHSIdjSsyXxgkQDOahkcc1H_-61TGh3BnTBJ9OIcBMI

sergey.khoroshavin (Tue, 20 Nov 2018 14:53:53 GMT):
There was a question about database schema - hope this piece of code can pass as an answer: https://github.com/hyperledger/indy-plenum/blob/master/plenum/common/metrics_collector.py#L366

sergey.khoroshavin (Tue, 20 Nov 2018 14:53:53 GMT):
There was a question from @houqinghui about database schema - hope this piece of code can pass as an answer: https://github.com/hyperledger/indy-plenum/blob/master/plenum/common/metrics_collector.py#L366

Silona (Tue, 20 Nov 2018 15:03:20 GMT):
also @klenik bought up a good point about integration btn projects

Silona (Tue, 20 Nov 2018 15:04:24 GMT):
and @VipinB asked great questions that help illustrate the resiliency in Sergey's design.

VipinB (Tue, 20 Nov 2018 15:21:40 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=XjgbWDtTfeWCS2Zgu) @sergey.khoroshavin From a quick read of this python code this seems to be the breakdown Key=utc+seqno; Value itself is a keyvalue pair (Metricname, value) Where Metricname is one of the enums in the class MetricNames (two groups, one base metric and one offset by 30000); Value is either a number or bignum (depending on the metric name)

VipinB (Tue, 20 Nov 2018 15:21:52 GMT):
Thanks for that

sergey.khoroshavin (Tue, 20 Nov 2018 15:24:19 GMT):
Yes, and seqno in key is used just to avoid situation when different metrics hits same timestamp and overwrite each other

sergey.khoroshavin (Tue, 20 Nov 2018 15:24:19 GMT):
Yes, and seqno in key is used just to avoid situation when different metrics hit same timestamp and overwrite each other

VipinB (Tue, 20 Nov 2018 15:24:53 GMT):
I get the use of seqno + bit fiddlery to gaurd against collisions

VipinB (Tue, 20 Nov 2018 15:24:53 GMT):
I get the use of seqno + bit fiddlery to guard against collisions

VipinB (Tue, 20 Nov 2018 15:26:24 GMT):
Since you have functions for encode, decode and encode_key all this is nicely wrapped....

sergey.khoroshavin (Tue, 20 Nov 2018 15:33:34 GMT):
Also wrapping things helps a lot with writing concise unit tests... I'd also like to clarify that bignum in value is actually binary encoded ValueAccumulator, and now all metrics are stored as these ValueAccumulators, not numbers. The reason why numbers are here are historical - first versions of metrics were writing all events to database, then we found it to be a bit expensive and switched to buffering and accumulating strategy. But we had some databases from older load test runs, hence support for two versions. In future plain numbers will be dropped.

sergey.khoroshavin (Tue, 20 Nov 2018 15:33:34 GMT):
Also wrapping things helps a lot with writing concise unit tests... I'd also like to clarify that bignum in value is actually binary encoded ValueAccumulator, and now all metrics are stored as these ValueAccumulators, not numbers. The reason why numbers are here are historical - first versions of metrics were writing all events to database, then we found it to be a bit expensive and switched to buffering and accumulating strategy. But we had some databases from older load test runs, hence transparent support for two versions. In future plain numbers will be dropped.

VipinB (Tue, 20 Nov 2018 15:34:35 GMT):
@sergey.khoroshavin I am wondering if many of these metrics can be derived from more primitive metrics - I have not looked at them in detail

VipinB (Tue, 20 Nov 2018 15:39:26 GMT):
Or have them be hooked up by level...i.e. a monitoring level log level or error_level? Might become more relevant as Sovrin (for example) gets productionized and the data accumulates. Also any refernce to your chaos engineering efforts will be useful

sergey.khoroshavin (Tue, 20 Nov 2018 15:47:40 GMT):
@VipinB we tried not to be redundant when adding metrics, but there are overlaps, especially between "normal" ones and "function profiling"

sergey.khoroshavin (Tue, 20 Nov 2018 15:48:43 GMT):
Adding monitoring levels is also interesting idea, thanks. Probably not critical issue now, but it could be useful in future

sergey.khoroshavin (Tue, 20 Nov 2018 15:56:00 GMT):
And as for chaos engineering - we have separate repository with system-level and chaos tests: https://github.com/hyperledger/indy-test-automation

VipinB (Tue, 20 Nov 2018 20:08:01 GMT):
Thanks for that... @sergey.khoroshavin I am taking a look at the actual tests that do the chaos

sergey.khoroshavin (Wed, 21 Nov 2018 11:15:25 GMT):
@VipinB if you have any questions on our chaos tests you can contact @ozheregelya - she had the most experience with them in our team

ozheregelya (Wed, 21 Nov 2018 11:15:26 GMT):
Has joined the channel.

MaheshBalan_Pravici (Wed, 21 Nov 2018 23:16:18 GMT):
Has joined the channel.

MaheshBalan_Pravici (Wed, 21 Nov 2018 23:20:51 GMT):
Folks we are running into an issue when the number of transactions in the ledger increases,ledger query performance degrades badly. In our Fabric 1.1 implementation, we have an asset defined as follows: asset TransferPointsTxn identified by transactionId { o String transactionId --> Account account } Basically we have a participant called account, and the transactions the account makes is recorded in this asset with transactionId pointing to the ledger transaction. What we are seeing is, when we try to look at an Account's transactions, cycling through the TransferPointTxn asset is pretty fast (it is from couchdb, and the query is indexed with a view etc) but when we try to pull the corresponding transaction from the ledger with a nested query based on transactionid, the retrieval from the ledger slows drown dramatically. With less than 100,000 transactions in the ledger, we are now seeing that it takes almost 2 seconds to retrieve each transaction from the ledger. The query on TransaferPointsTxn asset itself takes only a few seconds totally for a typical account, but the subquery to retrieve each transaction from the ledger is taking almost 2 seconds per transaction! This means if a customer has 20 transactions, we spend 2 + 20*2 = 42 seconds for the retrieval. 2018-11-15T23:31:34.030Z [886d63c2] DEBUG :NodeDataService :executeQuery() > {"selector":{"\\$class":"com.gm.lob.loyalty.TransferPoints","\\$registryType":"Transaction","\\$registryId":"com.gm.lob.loyalty.TransferPoints","transactionId":{"$eq":"0d38c9fbb1263b12d69f78855fc592ac2910a433b53baaa9aa9f71560bce3bd9"}}} 2018-11-15T23:31:36.563Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2533.00 2018-11-15T23:31:38.818Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2222.00 2018-11-15T23:31:41.449Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2619.00 2018-11-15T23:31:43.944Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2480.00 2018-11-15T23:31:46.113Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2152.00 2018-11-15T23:31:48.664Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2529.00 2018-11-15T23:31:50.347Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 1655.00 2018-11-15T23:31:52.645Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2262.00

stanleyc-trustscience (Thu, 22 Nov 2018 00:27:03 GMT):
Has joined the channel.

Gaurang (Thu, 22 Nov 2018 11:38:35 GMT):
Has joined the channel.

VipinB (Sat, 24 Nov 2018 15:43:13 GMT):
@MaheshBalan_Pravici How about asking on #fabric or #fabric-ledger. The performance & scale WG is a cross DLT WG for asking questions and answering generic concerns.

lwan2000 (Mon, 26 Nov 2018 17:12:24 GMT):
Has joined the channel.

MaheshBalan_Pravici (Mon, 26 Nov 2018 21:59:20 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=ukBrC6AusMNKkMgty) @VipinB I have posted in fabric-ledger as you suggested and gotten some guidance. Thank you.

bartman250 (Wed, 28 Nov 2018 09:43:23 GMT):
@mwagner - I've submitted as pull request for the emerald lab - I just need to add your git hub ID and state your role and I think it should be accepted !

VipinB (Wed, 28 Nov 2018 14:09:09 GMT):
Saw that @bartman250 , a small correction proposed. @mwagner does not need a github ID (can be good if he has it), I have suggested his role(s) that entitle him to sponsor; otherwise LGTM...

bartman250 (Fri, 30 Nov 2018 11:28:38 GMT):
@VipinB thanks for that - I think that works for the doc - I wasn't quite sure how to respond to the comment on that - I think the doc is ok now

VipinB (Sun, 02 Dec 2018 15:56:14 GMT):
@tkuhrt @lehors @trbs Anything else standing in the way of making the emerald test labs part of labs?

trbs (Sun, 02 Dec 2018 15:56:15 GMT):
Has joined the channel.

lehors (Sun, 02 Dec 2018 15:56:15 GMT):
Has joined the channel.

ghochstetler (Tue, 04 Dec 2018 13:44:59 GMT):
Tuesdays @9am ET seem to be the most popular meeting time. Have to bail again for another call.

VipinB (Tue, 04 Dec 2018 14:16:10 GMT):
https://gitlab.com/emerald-platform/emerald/wikis/Emerald-Benchmark

VipinB (Tue, 04 Dec 2018 14:21:35 GMT):
https://docs.google.com/document/d/1-WVtWEh5HKX9Lmbl7PMl5axHrd2uXwIPVZkeGfsHY3E/edit#heading=h.1vd1kqbu6t5j

VipinB (Tue, 04 Dec 2018 14:22:14 GMT):
Supply Chain use case

VipinB (Tue, 04 Dec 2018 14:53:26 GMT):
GS1 https://www.gs1.org/sites/default/files/docs/traceability/GS1_Global_Traceability_Standard_i2.pdf

VipinB (Tue, 04 Dec 2018 14:54:31 GMT):
https://docs.google.com/document/d/1b6ES0bKUK30E2iZizy3vjVEhPn7IvsW5buDo7nFXBE0/edit - Hyperledger Grid

VipinB (Tue, 04 Dec 2018 14:55:01 GMT):
Expanding on the Shared code and domain models in the diagram above: Fundamental Data Type Primitives Designed for blockchain (e.g. deterministically serializable and computable) Booleans Enums Structs Fixed precision numerics (in lieu of floating points) See extensible data types RFC linked earlier. Data Models Domain Nouns Organization Product Location Compliant with industry spec (e.g. GS1)

VipinB (Tue, 04 Dec 2018 15:22:32 GMT):
The output of HL Grid(the supplychain project) is meant to be (according to my understanding) 1. A Reference implementation- generalized through WASM 2. Reference Implementation contains a library of shared code and domain models complaint with GS1 which can be reused in other use case implementations (not just supply chain) 3. A launchpad to port this to other DLTs (Fabric, Burrow, Iroha, Quilt?) and using Indy: Helped by WASM integration as well as shared code for GS1 (industry spec)

bartman250 (Tue, 04 Dec 2018 15:36:21 GMT):
^^^ interesting - seeing the convergence towards WASM

ikocsis (Tue, 04 Dec 2018 15:42:04 GMT):
Is there now WASM support for Fabric? Is is this supposed to go through a node.js chaincode / Fabric is not a target? Or what am I missing?

ikocsis (Tue, 04 Dec 2018 15:42:04 GMT):
Is there now WASM support for Fabric? Or is this supposed to go through a node.js chaincode / Fabric is not a target? Or what am I missing? :)

ikocsis (Tue, 04 Dec 2018 15:54:09 GMT):
Ok, do I understand it right - the key thing is actually not the "shared code" (as in procedural stuff), but having an actual standardized data/domain/asset/... (however you want to call it) model prefabbed and ready for anybody to use? If yes, then this is really good and this should be definitely a "framework project", above Sawtooth/Fabric but below actual applications in the stack

Dan (Tue, 04 Dec 2018 16:15:04 GMT):
Yeah it's probably both. The code will be behind the wasm boundary so any project that wants to adopt the wasm interpreter should get all the code ported for free. There's another interesting bit that the code is going to be in rust (which compiles into wasm) so also if a platform doesn't want to use web assembly they could fork the rust and shim in their own native framework interface. And then to your point, yes this project will be pathfinding a lot of the schema questions - so just sorting that out will I think really move the needle on making it easier to develop useful more interoperable applications.

ikocsis (Tue, 04 Dec 2018 16:23:51 GMT):
Oh, ok, thanks, that makes sense.

rkrish82 (Wed, 05 Dec 2018 03:58:51 GMT):
Has joined the channel.

ghochstetler (Tue, 11 Dec 2018 13:53:27 GMT):
Apols again wrt HL PSWG mtg :/

aviralwal (Mon, 17 Dec 2018 11:51:24 GMT):
Has joined the channel.

mwagner (Mon, 17 Dec 2018 18:05:12 GMT):
@ghochstetler , all 18-Dec is our last meeting of the year!

mwagner (Tue, 18 Dec 2018 14:03:16 GMT):
Meeting time !

tallharish (Tue, 18 Dec 2018 19:46:28 GMT):
Meeting minutes for our meeting on Dec 18. https://docs.google.com/document/d/1rVtC8vjE1C_WzErGh9c3ohP2U1z3DWw60e5wl2OGgeI/edit?usp=sharing

tallharish (Tue, 18 Dec 2018 19:46:37 GMT):
Happy Holidays everyone. And see you in the new year

RameshT (Wed, 19 Dec 2018 09:56:04 GMT):
Has joined the channel.

wangqq (Mon, 24 Dec 2018 03:21:05 GMT):
Has joined the channel.

VipinB (Wed, 02 Jan 2019 19:29:46 GMT):
Hello all, Here is a link to an article that I published on the topic of Chaos Engineering and the Blockchain. Hope you will find it interesting. This is the first part of a two part publication, the next part will deal with the chaos experimentation framework implemented on top of Indy. Comments/reactions and or questions welcome. https://medium.com/@vipinsun/chaos-engineering-the-blockchain-51e60ae74d27

knagware9 (Thu, 03 Jan 2019 13:17:50 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=9kQCWj9gfQk5epkWG) @VipinB Nice read ..waiting for next article.

PoormaJinRao (Fri, 04 Jan 2019 03:17:13 GMT):
Has joined the channel.

n1zyz (Mon, 07 Jan 2019 17:49:49 GMT):
Hi, I am coming out of my Hibernation / winter slumber. Lets meet Tues at 9 AM EST !

n1zyz (Tue, 08 Jan 2019 14:15:40 GMT):
https://wiki2.hyperledger.org/display/PSWG

ajayatgit (Tue, 08 Jan 2019 14:17:36 GMT):
Has joined the channel.

bartman250 (Tue, 08 Jan 2019 15:22:48 GMT):
hello all - I've now opened the our test harness for emerald called 'benchmark' -> here https://gitlab.com/cordite/benchmark

bartman250 (Tue, 08 Jan 2019 15:23:21 GMT):
I wanted to update the docs a bit more, but ran out of time, so if you try to get it working and have trouble then let me know

mwagner (Tue, 08 Jan 2019 17:57:15 GMT):
thanks Mark

vreutskiy (Fri, 11 Jan 2019 08:19:17 GMT):
Has joined the channel.

tallharish (Sat, 12 Jan 2019 00:14:10 GMT):
Hi Everyone, I finished my Ph.D. thesis last month. Thank y'all for all the interaction over the last year, it helped me speed up my research. I thought of sharing our work on performance modeling of Fabric V1. Using stochastic modeling techniques, we developed a performance model of Fabric V1 network, from which we estimate various performance measures (throughput, latency, mean queue length) as a function of system and application configuration. We validated our models using a Fabric network setup in our lab. The relevant paper is attached here.

tallharish (Sat, 12 Jan 2019 00:15:05 GMT):

perf_model_HLF_Harish_18.pdf

tallharish (Sat, 12 Jan 2019 00:16:01 GMT):
I have documented extensive details of how to measure metrics for Fabric such as "time to endorsement", "time to ordering", "time to VSCC validation".... The diff files and related details are here: https://bitbucket.org/hvs2/fabric-perf-model/src/master/ Feel free to reach out to me with further questions.

boymiss (Mon, 14 Jan 2019 00:58:34 GMT):
Has joined the channel.

guyho (Tue, 15 Jan 2019 13:29:34 GMT):
backlog of tasks this morning. Have to bail on our meeting today.

mwagner (Tue, 15 Jan 2019 14:10:51 GMT):
ok, we will miss you

tallharish (Tue, 15 Jan 2019 17:28:39 GMT):
Meeting minutes for Jan 15: https://docs.google.com/document/d/1eV6kv9M3lWc2xTbIanhIt086guK5nvQR5YcY0MUIA1A/edit?usp=sharing

mwagner (Wed, 16 Jan 2019 19:02:11 GMT):
thanks folks! Hopefully you found it interesting

bartman250 (Wed, 16 Jan 2019 19:06:09 GMT):
indeed it was - thanks for organising

VipinB (Wed, 16 Jan 2019 19:58:01 GMT):
Looks like we have the following from the meeting: -STAC commercial model vs. our participation model -STAC is focused on financial sector, trading, trade-processing etc. -STAC Packs which are the standard instruments (i.e. software) for creating STAC benchmarks arise out of standard metric definitions and software purpose built to measure for a vendor, usually built by community(gated); run by vendors, can be certified by STAC if they control & audit the running of STAC PACK. -Having community based working groups (Capital Markets, Payments) inside Hyperledger will help drive some of the benchmark metrics in collaboration with STAC. -We do not have policy guidelines in HL PSWG document (i.e. guidance around auditing, testnet etc.) -No standards in Blockchain space nor standard apis for interaction that all DLTs follow. _There may be ISDA standards for specific products (Swaps & Derivatives) that we may be able to utilize_ (my comment) -We can collaborate - speaking at STAC summit, STAC will ask members about the business for Blockchain based benchmarks, future meetings over email or otherwise etc. Anything else?

mwagner (Wed, 16 Jan 2019 20:45:16 GMT):
@VipinB I think that captures everything I had

Gandalf (Fri, 18 Jan 2019 16:12:31 GMT):
Great writeup Vipin

saif_lesnar (Mon, 21 Jan 2019 01:43:06 GMT):
Has joined the channel.

CaixiangFan (Mon, 21 Jan 2019 17:24:36 GMT):
Has joined the channel.

gyc567 (Tue, 22 Jan 2019 08:34:34 GMT):
Has joined the channel.

gyc567 (Tue, 22 Jan 2019 08:43:03 GMT):
how to improve the fabric performance?

guyho (Tue, 22 Jan 2019 13:00:46 GMT):
Apols again. Conflicting meeting.

mwagner (Tue, 22 Jan 2019 14:46:51 GMT):
https://wiki.hyperledger.org/groups/sig-application

incarose (Wed, 23 Jan 2019 00:26:59 GMT):
Has joined the channel.

vreutskiy (Wed, 23 Jan 2019 02:42:15 GMT):
Hello, dear community member. I am writing from behalf of Soramitsu, the main contributor to Hyperledger Iroha. Can I as you about working link to shared directory with actual meeting minutes and meeting recordings? Those on the WG page in the Wiki (https://wiki.hyperledger.org/groups/pswg/performance-and-scale-wg) are looking outdated (last MM at 2018/08/18 and record at 2018/10/30).

vreutskiy (Wed, 23 Jan 2019 02:42:15 GMT):
Hello, dear community members. I am writing from behalf of Soramitsu, the main contributor to Hyperledger Iroha. Can I as you about working link to shared directory with actual meeting minutes and meeting recordings? Those on the WG page in the Wiki (https://wiki.hyperledger.org/groups/pswg/performance-and-scale-wg) are looking outdated (last MM at 2018/08/18 and record at 2018/10/30).

vreutskiy (Wed, 23 Jan 2019 02:42:15 GMT):
Hello, dear community members. I am writing from behalf of Soramitsu, the main contributor to Hyperledger Iroha. Can I ask you about working link to the shared directory with actual meeting minutes and meeting recordings? Those on the WG page in the Wiki (https://wiki.hyperledger.org/groups/pswg/performance-and-scale-wg) are looking outdated (last MM at 2018/08/18 and record at 2018/10/30).

vreutskiy (Wed, 23 Jan 2019 02:42:15 GMT):
Hello, dear community members. I am writing on behalf of Soramitsu, the main contributor to Hyperledger Iroha. Can I ask you about working link to the shared directory with actual meeting minutes and meeting recordings? Those on the WG page in the Wiki (https://wiki.hyperledger.org/groups/pswg/performance-and-scale-wg) are looking outdated (last MM at 2018/08/18 and record at 2018/10/30).

vreutskiy (Wed, 23 Jan 2019 02:45:36 GMT):
Hello, dear community members. I am writing from behalf of Soramitsu, the main contributor to Hyperledger Iroha. Can I as you about working link to shared directory with actual meeting minutes and meeting recordings? Those on the WG page in the Wiki (https://wiki.hyperledger.org/groups/pswg/performance-and-scale-wg) are looking outdated (last MM at 2018/08/18 and record at 2018/10/30).

VipinB (Wed, 23 Jan 2019 04:38:41 GMT):
Meeting minutes: We discussed strategy for the next steps Should we address Supply Chain (provenance) or Finance use cases to get to the next level of metrics Supply chain experts and others had contacted Mark In light of STAC call we should look at finance Benchmark Model in TPC is to have separate benchmarks for: a. OLTP (Online Transaction Processing) b. Data Integration (ETL- OLTP data combined with other data) c. Decision Support (Queries) - they also have another breakout based on big data, virtualized environment and so on. Do we need such a division? What would such a division look in the Blockchain world? STAC also has some some such division between their benchmarks. (STAC-T for tick to trade) processing and execution vs querying) there are many benchmarks. Mark Simpson will write down steps for provenance so that we can look at benchmarks falling out from this use case Vipin will try to map the TPC/STAC ontology to blockchains. These minutes will be captured in PSWG folder after getting feedback

YanLIU0822 (Thu, 24 Jan 2019 09:37:12 GMT):
Has joined the channel.

VipinB (Sun, 27 Jan 2019 17:09:54 GMT):
https://medium.com/@vipinsun/real-world-crypto-2019-b011922858d1 Real world crypto 2019, a summary report by yours truly

YanLIU0822 (Mon, 28 Jan 2019 07:56:08 GMT):
how much the TPS do you have?

YanLIU0822 (Mon, 28 Jan 2019 07:56:15 GMT):
I test only 19 TPS

YanLIU0822 (Mon, 28 Jan 2019 07:56:20 GMT):
it is too much low

YanLIU0822 (Mon, 28 Jan 2019 07:56:56 GMT):
hyperledger fabric 1.1

Nabilel 1 (Mon, 28 Jan 2019 10:50:12 GMT):
Has joined the channel.

klenik (Mon, 28 Jan 2019 16:47:26 GMT):
Hi All! I have a question about finality and the latency@threshold metric (in the context of Fabric and its support in Caliper). Problem: even if a transaction successfully goes through the consensus flow, there is the possibility of a transient error happening during actually committing the transaction or its entire encapsulating block (e.g., some DB access error). I think (but not exactly sure) that these kind of situations are signaled by a special error in Fabric, in which case the peer halts the processing of further transactions/blocks, and initiates some recovery protocol. Scenario: (at least) one peer confirms the success of a transaction, but other peers run into some transient error, notifying the client (Caliper in this case) about an unsuccessful transaction. But Fabric will _eventually_ synchronize the successful transactions across the network. Question 1) Should the transaction be considered as successful? (I think yes. It's committed on at least one peer and will be syncronized to faulty peers eventually.) Question 2) How do we calculate the latency@threshold metric in this case? Say we have the timestamps for 9 successful events and 1 unsuccessful one. Calculating latency@90% is no problem in this case. But if the percentage of nodes that successfully committed the transaction is below the threshold, then we don't have enough timing data to calculate the metric. Any insight is greatly appreciated! :)

VipinB (Tue, 29 Jan 2019 01:26:24 GMT):
@klenik we debated this question for many days in the finality debate; decided to go with the following separation probabilistic finality vs non-probabilistic; in the first case there can be a re-org and hence the transaction could be non-durable because of a fork. The case of Fabric is the second where the latency@threshold metric may not make sense; in any case the slower diffusion due to faults (which is what you bring up) may point to bigger problems and may not be fixed until the underlying faults are fixed.

VipinB (Tue, 29 Jan 2019 01:27:38 GMT):
So to measure a network that is limping along (90% fault rate) due to some other problem may not be worthwhile

VipinB (Tue, 29 Jan 2019 01:30:03 GMT):
Obviously if this fault keeps re-occurring there may be some configuration or other issues. Lower rates for the similar networks with similar rules and payloads than reported rates must be looked into before continuing the measurement

Gandalf (Tue, 29 Jan 2019 14:11:00 GMT):
Is there no PSWG meeting today?

VipinB (Tue, 29 Jan 2019 15:17:42 GMT):
No Mark had sent out a cancellation- the meeting was scheduled to be more an hour ago anyway

VipinB (Mon, 04 Feb 2019 14:43:57 GMT):
@cbf has written an article on Performance & Scale of HLF please take a look. https://www.ibm.com/blogs/blockchain/2019/01/answering-your-questions-on-hyperledger-fabric-performance-and-scale/ He has a shoutout for PSWG paper

VipinB (Mon, 04 Feb 2019 15:33:52 GMT):
Also this: https://arxiv.org/pdf/1901.00910.pdf

klenik (Mon, 04 Feb 2019 16:13:52 GMT):
@VipinB Thank you for the answer! So the semantics should be something like the following for Fabric (from a measuring/reporting point-of-view): even one successful confirmation means that the transactions is committed; and the latency@threshold kind of reflects the propagation/processing delay in the network, so it can be interpreted as a percentile calculation for the latency of transaction confirmations. Am I heading in the right direction?

cbf (Mon, 04 Feb 2019 16:15:22 GMT):
the Waterloo paper is great, we also had a recent fabric maintainers call with those guys - looking for the recording now

tallharish (Mon, 04 Feb 2019 17:50:57 GMT):
@cbf: Great article. I am looking forward to future articles. We had taken an analytical view of Fabric's performance, and glad to see our observations are consistent with yours. http://sites.duke.edu/hvs2/files/2018/11/perf_model_HLF_Harish_18.pdf

tallharish (Tue, 05 Feb 2019 17:13:05 GMT):
Meeting minutes for Feb 5 - https://docs.google.com/document/d/1BHpfjOvRbbYDqK4PaBP5ijLBj6AxN79DFgoFpiKn900/edit

Silona (Tue, 05 Feb 2019 20:44:47 GMT):
Hey y'alls update to the TSC is due https://wiki.hyperledger.org/display/HYP/TSC+Working+Group+Updates

mwagner (Thu, 07 Feb 2019 15:11:57 GMT):
@Silona my bad, ended up taking some vacation daze

mwagner (Mon, 11 Feb 2019 20:15:10 GMT):
no meeting this week 12-Feb-2019

kelly_ (Tue, 12 Feb 2019 22:03:32 GMT):
Has joined the channel.

kelly_ (Tue, 12 Feb 2019 22:03:55 GMT):
Came here to poke @mwagner on the update but I see Silona has beat me to it!

danacr (Thu, 14 Feb 2019 20:06:17 GMT):
Has left the channel.

mwagner (Tue, 19 Feb 2019 14:00:14 GMT):
meeting time

mwagner (Tue, 19 Feb 2019 14:00:32 GMT):
zoom 4034983298

VipinB (Tue, 19 Feb 2019 14:09:55 GMT):
https://arxiv.org/pdf/1901.00910.pdf

mwagner (Tue, 19 Feb 2019 14:24:06 GMT):
https://wiki.hyperledger.org/display/HYP/2019+Q1+Performance+and+Scale+WG

VipinB (Tue, 19 Feb 2019 14:44:21 GMT):
https://wiki.hyperledger.org/display/HYP/Financial+Markets+SIG+Proposal is the FM proposal For a difference between Trade Finance and Financial markets SIG please read the sections there. Also this is not directly related to the PSWG; however please help launch this SIG, because this will increase our interaction with STAC.

VipinB (Tue, 19 Feb 2019 15:10:02 GMT):
And increase discussion on use cases which we need as the background

tallharish (Tue, 19 Feb 2019 17:42:18 GMT):
Meeting minutes for Feb 19 - https://docs.google.com/document/d/1n2yIodeemiozdf-7NERP0bHfxcjg8-cKd-A1eqcbI5g/edit

mwagner (Tue, 19 Feb 2019 17:59:44 GMT):
thanks @tallharish

toddinpal (Mon, 25 Feb 2019 16:57:29 GMT):
Does anyone know why the Waterloo group didn't abandon the requirement that the ordering service is the source of complete blocks? Couldn't it just create blocks of transactions IDs and let the peers via gossip disseminate the transactions and create the blocks based upon the transaction ID's ordered by the ordering service?

VipinB (Tue, 26 Feb 2019 03:21:33 GMT):
It might be due to this "Notably, our approach does not require any modification of the existing ordering interface, allowing us to leverage existing Fabric clients and peer code." Taken directly from the paper. Of course you can

tallharish (Tue, 26 Feb 2019 03:21:47 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=cipzW476MCSfdNRhN) @toddinpal Perhaps coz they didn't want to change the interface between the nodes. All their changes are internal to each node / transaction phase.

VipinB (Tue, 26 Feb 2019 03:21:52 GMT):
talk to the guys in Waterloo.

VipinB (Tue, 26 Feb 2019 03:23:24 GMT):
Hey @tallharish and I had the same response... @toddinpal

tallharish (Tue, 26 Feb 2019 03:24:04 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=78EzZBkDK7WkdNas8) @VipinB we "timed" it well. :sunglasses:

VipinB (Tue, 26 Feb 2019 03:24:41 GMT):
We must be on a telepathic channel

mwagner (Tue, 26 Feb 2019 13:44:41 GMT):
The one of the Waterloo folks can talk to us next week, we can discuss in 15 minutes on the PSWG call

mwagner (Tue, 26 Feb 2019 14:00:19 GMT):
PSWG call starting

mwagner (Tue, 26 Feb 2019 14:47:18 GMT):
https://jira.hyperledger.org/browse/FAB-13582

tallharish (Tue, 26 Feb 2019 14:50:17 GMT):
https://arxiv.org/pdf/1706.04507.pdf "A Blockchain-based Approach for Data Accountability and Provenance Tracking"

toddinpal (Tue, 26 Feb 2019 16:19:56 GMT):
@tallharish Still seems like it would be a path to investigate and perhaps maybe they did. Do any of them participate in Fabric working groups?

tallharish (Tue, 26 Feb 2019 22:31:04 GMT):
Meeting minutes for Feb 26 - https://docs.google.com/document/d/1NryuDboLUEYg8lVdCgQqCBpZYo3zfG6rAxmdu3mzhSU/edit?usp=sharing

tallharish (Tue, 26 Feb 2019 22:32:38 GMT):
@toddinpal not sure if they participate in Fabric WGs. Regarding your thoughts, you might wanna look at this paper https://arxiv.org/abs/1808.08406 "StreamChain: Do Blockchains Need Blocks?"

YanLIU0822 (Wed, 27 Feb 2019 07:33:17 GMT):
hey I increase the size of BatchSize.MaxMessageCount, but the TPS and latency haven't changed can someone explain it to me. Many thanks

klenik (Wed, 27 Feb 2019 14:11:55 GMT):
@YanLIU0822 The ordering service constructs a block when __any__ of the following event happens: 1. `MaxMessageCount` is reached 2. `AbsoluteMaxBytes` is reached 3. `BatchTimeout` is reached So maybe it wasn't `MaxMessageCount` that triggered the block creation in your case, so changing (increasing/decreasing?) it didn't have any effect.

klenik (Wed, 27 Feb 2019 14:11:55 GMT):
@YanLIU0822 The ordering service constructs a block when _any_ of the following event happens: 1. `MaxMessageCount` is reached 2. `AbsoluteMaxBytes` is reached 3. `BatchTimeout` is reached So maybe it wasn't `MaxMessageCount` that triggered the block creation in your case, so changing (increasing/decreasing?) it didn't have any effect.

tallharish (Tue, 05 Mar 2019 05:47:58 GMT):
I might not be able to join the meeting on march 5. Meanwhile I reviewed FastFabric and thought about it from a performance modeling perspective. Here's my blog article. The most useful section is my comments on their setup. https://harish-sukhwani.blog/towards-performance-modeling-of-fastfabric/

tallharish (Tue, 05 Mar 2019 05:47:58 GMT):
I might not be able to join the meeting on march 5. Meanwhile I reviewed FastFabric and thought about it from a performance modeling perspective. Here's my blog article. For the folks here in PSWG, the most useful section is my comments on their setup. https://harish-sukhwani.blog/towards-performance-modeling-of-fastfabric/

mwagner (Tue, 05 Mar 2019 13:46:13 GMT):
@tallharish nice writeup (as always)

mwagner (Tue, 05 Mar 2019 13:48:01 GMT):
The FastFabric paper for todays call is here: https://arxiv.org/pdf/1901.00910.pdf

mwagner (Tue, 05 Mar 2019 14:00:06 GMT):
Meeting starting now

mwagner (Mon, 11 Mar 2019 11:46:07 GMT):
I canceled the meeting for tomorrow

Pradeep_Pentakota (Tue, 12 Mar 2019 13:07:51 GMT):
Has joined the channel.

VipinB (Sat, 16 Mar 2019 17:08:22 GMT):
The concept of a micro-benchmark : https://github.com/danintel/ursaspeed

VipinB (Sat, 16 Mar 2019 17:08:47 GMT):
This one is specifically for ursa speed both benchmarking and optimisation

Daniela_Barbosa (Sun, 17 Mar 2019 23:53:12 GMT):
Has joined the channel.

mwagner (Tue, 19 Mar 2019 12:12:50 GMT):
Reminder the US changed clocks a few weekends ago, the PSWG meeting will start in app47 minutes

kenty (Tue, 19 Mar 2019 14:03:49 GMT):
Has joined the channel.

kenty (Tue, 19 Mar 2019 14:04:10 GMT):
greetings, i am kent in Hong Kong

kenty (Tue, 19 Mar 2019 14:06:16 GMT):
please feel free to reach out to me

VipinB (Tue, 19 Mar 2019 14:53:53 GMT):
Hello Kent thanks for reaching out...and being on the call.

MHBauer (Tue, 19 Mar 2019 17:40:00 GMT):
Has joined the channel.

MHBauer (Tue, 19 Mar 2019 17:40:46 GMT):
are there any benchmarks for individual compenents? aka peer, orderer, etc?

MHBauer (Tue, 19 Mar 2019 17:42:40 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=tmJBzkXApF84JQ6t5) @mwagner I'm having diffuclty finding a playback recording or meeting notes for this?

MHBauer (Tue, 19 Mar 2019 22:22:14 GMT):
@mwagner thank you for wiki page

MHBauer (Tue, 19 Mar 2019 22:22:27 GMT):
https://wiki.hyperledger.org/display/PSWG/2019+Meeting+Recordings :+1:

MHBauer (Tue, 19 Mar 2019 22:23:53 GMT):
audio only?

mwagner (Wed, 20 Mar 2019 20:40:04 GMT):
for now

mwagner (Wed, 20 Mar 2019 20:40:35 GMT):
I need to figure out confluence

VipinB (Wed, 20 Mar 2019 20:43:56 GMT):
Mark, my reboot seems to have worked for the IDWG call- we will see what the evening meeting brings

VipinB (Wed, 20 Mar 2019 20:44:20 GMT):
We had 10 people today

rjones (Wed, 20 Mar 2019 21:07:55 GMT):
@VipinB I didn't set those to repeat, so if you want them to repeat, let me know

VipinB (Wed, 20 Mar 2019 21:13:47 GMT):
No Prob, just an experiment @rjones So I need two days today 8 pm EDT ( +1 00:00 UTC) and on April 3 the same time, If we are running with it then we will repeat

mwagner (Mon, 25 Mar 2019 17:52:34 GMT):
does anyone have agenda items for this weeks PSWG call ?

rjones (Mon, 25 Mar 2019 17:52:52 GMT):
Has left the channel.

MHBauer (Mon, 25 Mar 2019 18:14:46 GMT):
this is across all HL projects? when is it? can't find that on the wiki pages. I know I've seen it, and I fear it's too early in the morning for me, which is why I appreciate the recordings.

mwagner (Mon, 25 Mar 2019 18:38:52 GMT):
yes the perf and scale group looks across all projects

mwagner (Mon, 25 Mar 2019 18:39:35 GMT):
the call is tues 10AM EDT (eastern US, NYC)

mwagner (Mon, 25 Mar 2019 18:40:15 GMT):
https://wiki.hyperledger.org/display/HYP/Calendar+of+Public+Meetings

MHBauer (Mon, 25 Mar 2019 18:40:23 GMT):
that's the one

MHBauer (Mon, 25 Mar 2019 18:40:38 GMT):
should link that in the pwsg wiki somewhere.

mwagner (Mon, 25 Mar 2019 18:41:05 GMT):
top item in the "Groups" pull down

MHBauer (Mon, 25 Mar 2019 18:41:08 GMT):
anyway, yea, 7am for me.

MHBauer (Mon, 25 Mar 2019 18:41:25 GMT):
that's an interesting location.

MHBauer (Mon, 25 Mar 2019 18:41:35 GMT):
I'll try and remember. Thanks.

mwagner (Mon, 25 Mar 2019 18:41:37 GMT):
yeah we are considering some time changes or running two meetings

MHBauer (Mon, 25 Mar 2019 18:41:44 GMT):
I knew it was in there, just couldn't find it.

MHBauer (Mon, 25 Mar 2019 19:28:12 GMT):
@mwagner I think DST shifted the meeting. Shows as 6am Pacific, 9am Eastern right now. Alternatively, the calendar links need to be adlusted for daylight, not sure what to use as the TZ column...

louisliu2048 (Tue, 26 Mar 2019 07:17:29 GMT):
Has joined the channel.

mwagner (Tue, 26 Mar 2019 11:43:58 GMT):
@MHBauer gawd, I meant 9 AM EDT - my brain is fried

mwagner (Tue, 26 Mar 2019 11:52:46 GMT):
No performance and scale meeting today

MHBauer (Tue, 26 Mar 2019 17:14:18 GMT):
:-(

mwagner (Mon, 01 Apr 2019 17:47:27 GMT):
PSWG meeting is on for Tues, 2-April at 9 AM EDT

guyho (Tue, 02 Apr 2019 12:08:07 GMT):
Apols - have conflicting meeting today.

mwagner (Tue, 02 Apr 2019 12:58:01 GMT):
thanks for the heads up, we need to look at changing our meeting time

stone-ch (Wed, 03 Apr 2019 02:23:47 GMT):
Has joined the channel.

kjensen (Thu, 04 Apr 2019 13:47:12 GMT):
Has joined the channel.

suryalanka (Thu, 04 Apr 2019 21:22:58 GMT):
Has joined the channel.

bmos299 (Thu, 04 Apr 2019 21:26:40 GMT):
Has joined the channel.

Bobbijn (Fri, 05 Apr 2019 18:44:51 GMT):
Has joined the channel.

Bobbijn (Fri, 05 Apr 2019 18:44:58 GMT):

Clipboard - April 5, 2019 2:44 PM

Bobbijn (Fri, 05 Apr 2019 18:48:07 GMT):
https://wiki.hyperledger.org/display/LMDWG/Learning+Materials+Development+Working+Group

MHBauer (Fri, 05 Apr 2019 18:59:55 GMT):
looks cool

mwagner (Fri, 05 Apr 2019 20:18:44 GMT):
@Bobbijn time should be 1 PM EDT correct ?

Bobbijn (Sun, 07 Apr 2019 01:57:45 GMT):
Yes 1

Bobbijn (Sun, 07 Apr 2019 01:57:45 GMT):
Yes 1pm EDT

Bobbijn (Sun, 07 Apr 2019 01:58:12 GMT):
Pm

mwagner (Mon, 08 Apr 2019 19:47:40 GMT):
I was going to cancel the pswg call for 9 - Apr unless people have something urgent

mwagner (Mon, 08 Apr 2019 20:40:49 GMT):
call canceled for this week

houqinghui (Tue, 09 Apr 2019 09:46:35 GMT):
roger

rjones (Tue, 09 Apr 2019 16:46:09 GMT):
For additional information on this working group, see: https://wiki.hyperledger.org/display/PSWG

NicolasHuray (Wed, 10 Apr 2019 17:34:22 GMT):
Has joined the channel.

JeffreyDing (Thu, 11 Apr 2019 02:44:34 GMT):
Has joined the channel.

JeffreyDing (Thu, 11 Apr 2019 02:48:08 GMT):
Our company wanna test the whole Blockchains from different aspects. I am in charge of performance and scale test.

RameshT (Thu, 11 Apr 2019 07:03:00 GMT):
Can someone share me info as how to join the calls of pswg group?

bilalahmed (Thu, 11 Apr 2019 09:17:12 GMT):
Has joined the channel.

hssanbenrhouma (Thu, 11 Apr 2019 13:13:10 GMT):
Has joined the channel.

mauricio (Thu, 11 Apr 2019 15:10:02 GMT):
Has joined the channel.

tallharish (Sat, 13 Apr 2019 13:00:15 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=Xf4uTZKW6H39MiNdt) @RameshT https://wiki.hyperledger.org/display/HYP/Calendar+of+Public+Meetings

vamsiGaddipati (Sun, 14 Apr 2019 01:43:26 GMT):
Has joined the channel.

houqinghui (Mon, 15 Apr 2019 01:17:03 GMT):
@JeffreyDing You can use caliper to test your blockchain performance.

JeffreyDing (Mon, 15 Apr 2019 16:04:12 GMT):
I’d like to write a testing standardization. Do you have any advice?

Silona (Mon, 15 Apr 2019 18:48:04 GMT):
Just wanna say congrats to @mwagner as he is now a representative on the governing board for hyperledger!

houqinghui (Tue, 16 Apr 2019 01:14:10 GMT):
@JeffreyDing Can you explain your need in detail?

tallharish (Tue, 16 Apr 2019 14:08:18 GMT):
Thanks for participating everyone. I will send out the minutes in a few hours.

tallharish (Tue, 16 Apr 2019 16:53:24 GMT):
Meeting minutes for April 16. Please share your feedback with Mark. https://docs.google.com/document/d/1r6QKb323EFd--OarpnSy1rBZ5o_mpOhwr4rP0Tku3ec/edit

RameshT (Tue, 16 Apr 2019 17:47:36 GMT):
[ ](https://chat.hyperledger.org/channel/performance-and-scale-wg?msg=NdhjjnKde7Wbbz8jG) @tallharish Thank you!

mwagner (Tue, 16 Apr 2019 18:55:10 GMT):
Thanks @tallharish !

hnampk (Tue, 23 Apr 2019 03:07:42 GMT):
Has joined the channel.

bjwswang (Tue, 23 Apr 2019 07:28:57 GMT):
Has joined the channel.

RahulHundet (Mon, 29 Apr 2019 05:57:59 GMT):
Has joined the channel.

mwagner (Tue, 30 Apr 2019 12:52:09 GMT):
no meeting today

mwagner (Mon, 20 May 2019 20:37:13 GMT):
meeting tomorrow, 9AM EDT

mwagner (Tue, 21 May 2019 12:01:05 GMT):
pswg call starts in 1 hour

mwagner (Thu, 23 May 2019 11:36:37 GMT):
just wrapped up the quarterly report to the TSC. please give it a read https://wiki.hyperledger.org/display/HYP/2019+Q2+Performance+and+Scale+WG

houqinghui (Tue, 28 May 2019 08:22:11 GMT):
today''s meeting is canceled?

VipinB (Tue, 28 May 2019 15:08:12 GMT):
Mark sent out email

mwagner (Wed, 29 May 2019 21:32:41 GMT):
hi all, we will be discussing the PSWG on the TSC call Thurs at 10AM EDT. I would encourage all interested parties to attend. - note that you do not need to be on the TSC to participate

mwagner (Thu, 30 May 2019 14:06:18 GMT):
tsc call is starting

mwagner (Tue, 04 Jun 2019 03:05:39 GMT):
No PSWG call this week, 4-June

VipinB (Tue, 11 Jun 2019 12:59:31 GMT):
Provenance use case written up https://docs.google.com/document/d/1pARtxESnOqQViJabErC5hxFupyfZWCWtOnxsLVtHP4Y/edit?usp=sharing

tallharish (Wed, 19 Jun 2019 15:53:54 GMT):
Meeting minutes for June 18 https://docs.google.com/document/d/13nvnWIhd1HtJsiw3f4kZ3uptmddMrB4k6xs6RVCtznY/edit

HaricharanBole (Wed, 19 Jun 2019 16:18:16 GMT):
Has joined the channel.

VipinB (Mon, 24 Jun 2019 19:24:27 GMT):
Provenance use case received a lot of attention from @KellyCooper who has edited it for readability. By tomorrow's call I will use gs1 based standards to model a few items. Namely, identities of the various roles, tags, the snapshot data etc. gs1 is a huge standard since it has to cover both generic and specific description of all goods as well as docs .... Will attempt to consolidate.

KellyCooper (Mon, 24 Jun 2019 19:24:28 GMT):
Has joined the channel.

mwagner (Tue, 25 Jun 2019 13:03:37 GMT):
PSWG meeting starting now!

rjones (Thu, 27 Jun 2019 17:01:45 GMT):
Has joined the channel.

ChristianLF (Tue, 02 Jul 2019 20:54:28 GMT):
Has joined the channel.

ChristianLF (Tue, 02 Jul 2019 20:56:31 GMT):
Hi @mwagner would love to chat with you, I have a team in which we are planning to introduce a new project in collaboration with hyperledger, allowing for scaling while still obtaining security from the use of unlimited nodes in the validation of transactions.

ChristianLF (Tue, 02 Jul 2019 20:56:51 GMT):
Please let me know when we could chat

mwagner (Tue, 02 Jul 2019 21:15:54 GMT):
Hi @ChristianLF would love to hear about it. Would like to come to our meeting next Tues at 9 AM EDT to discuss ?

ChristianLF (Tue, 02 Jul 2019 21:23:14 GMT):
Sure, still would we be able to chat inbetween?

ChristianLF (Tue, 02 Jul 2019 21:23:22 GMT):
Should I PM you?

mwagner (Tue, 02 Jul 2019 21:23:54 GMT):
sure, I have a few minutes now

ChristianLF (Wed, 03 Jul 2019 13:58:57 GMT):
Hello, good morning to everyone.

LeonardoCarvalho (Fri, 05 Jul 2019 10:46:27 GMT):
Has joined the channel.

rjones (Mon, 08 Jul 2019 17:59:12 GMT):
Has left the channel.

mwagner (Mon, 08 Jul 2019 18:07:49 GMT):
no PSWG call this week

cgorenflo (Thu, 11 Jul 2019 16:13:46 GMT):
Has joined the channel.

invaliduser (Sat, 13 Jul 2019 10:40:35 GMT):
Has joined the channel.

ChristianLF (Mon, 15 Jul 2019 16:03:50 GMT):
Hey @mwagner have you been able to take a look at the article I sent you?

ChristianLF (Mon, 15 Jul 2019 16:04:05 GMT):
and doc I emailed you?

VipinB (Tue, 16 Jul 2019 13:02:21 GMT):
Hi guys I will not be able to join today. I fully support the hosting of the performance numbers on PSWG based website. There are even more options for exposure of website and associated resources to the wiki. Gitlab with its gitbooks can be used to host a static website

VipinB (Tue, 16 Jul 2019 13:02:43 GMT):
And the link can be in the PSWG wiki

ikocsis (Tue, 16 Jul 2019 13:03:16 GMT):
Is there a call this week? (I planned to join, but something came up...)

VipinB (Tue, 16 Jul 2019 13:03:20 GMT):
I will continue to plug away at the provenance use case mapping to several GS1 standards

VipinB (Tue, 16 Jul 2019 13:03:48 GMT):
@ikocsis Mark had announced a call, but I am unable to attend

mwagner (Tue, 16 Jul 2019 14:52:21 GMT):
@ChristianLF I did read it several weeks ago. been tied up with my day job. Are you comfortable sharing it with the PSWG mailing list and then discussing it in an upcomingg meeting ?

mwagner (Mon, 22 Jul 2019 13:14:05 GMT):
reminder - NO PSWG meeting this week

ChristianLF (Wed, 24 Jul 2019 07:08:12 GMT):
Hey @mwagner yes I can, we are working on releasing testnet this coming week or so, I am working on updating the documentation to make it more inclusive and updating some docs, after having done so and putting everything together I will very well be glad to present it in a meeting.

mwagner (Tue, 30 Jul 2019 05:24:59 GMT):
Reminder, no meeting this week. We will meet next week

mwagner (Tue, 06 Aug 2019 13:37:59 GMT):
Time for the PSWG Call anyone else joining

VipinB (Tue, 06 Aug 2019 13:44:08 GMT):
https://docs.google.com/document/d/1pARtxESnOqQViJabErC5hxFupyfZWCWtOnxsLVtHP4Y/edit?usp=sharing

VipinB (Tue, 06 Aug 2019 13:44:20 GMT):
Provenance use case

cgorenflo (Tue, 06 Aug 2019 15:45:55 GMT):
Hey @mwagner , could you share a link to the paper with the 10x improvements you mentioned? Thanks!

joe_k (Wed, 07 Aug 2019 18:14:03 GMT):
Has joined the channel.

mwagner (Tue, 13 Aug 2019 13:01:11 GMT):
running a few minutes late, will be there shortly

mwagner (Tue, 13 Aug 2019 13:06:03 GMT):
anyone else coming to pswg call ?

mwagner (Tue, 13 Aug 2019 13:14:12 GMT):
Samsung going through their Accelerator talk on pswg call now

VipinB (Tue, 13 Aug 2019 14:05:23 GMT):
Great meeting- with lots to chew on

sundarsuman (Sun, 18 Aug 2019 18:55:04 GMT):
Has joined the channel.

VipinB (Mon, 19 Aug 2019 20:08:53 GMT):
Xilinx paper https://arxiv.org/pdf/1907.08367.pdf to be discussed at PSWG tomorrow

VipinB (Mon, 19 Aug 2019 20:11:07 GMT):
Focusing on CC caching and speeding up the verifiers. 1.5x- looks like can be layered on top of FastFabric- along with last weeks SDS accelerator technology could achieve much grater throughput.

VipinB (Mon, 19 Aug 2019 20:11:17 GMT):
Cant wait...

VipinB (Tue, 20 Aug 2019 13:04:29 GMT):
The meeting started

bis2019 (Sat, 24 Aug 2019 12:19:03 GMT):
Has joined the channel.

mwagner (Tue, 27 Aug 2019 11:49:47 GMT):
No meeting today!

toddinpal (Fri, 30 Aug 2019 17:19:23 GMT):
Are we still shooting for a f2f in the bay area on Sept 20?

VipinB (Fri, 30 Aug 2019 18:07:39 GMT):
@toddinpal is that for Arch WG or PSWG?

toddinpal (Fri, 30 Aug 2019 18:40:30 GMT):
nuts, wrong chat... privacy and condidentiality

mwagner (Fri, 30 Aug 2019 18:49:55 GMT):
well you blew the confidentiality part, we all know about your private party now....

toddinpal (Fri, 30 Aug 2019 23:32:36 GMT):
:grimacing:

VipinB (Tue, 03 Sep 2019 16:14:15 GMT):
Posted the following to #Grid " #performance-and-scale-wg is in the process of creating a provenance use case to be the driver for objective metrics across dlts. The data model uses GS1 concepts. The preliminary writeup is in https://docs.google.com/document/d/1pARtxESnOqQViJabErC5hxFupyfZWCWtOnxsLVtHP4Y/edit?usp=sharing - Would like to find out what the level of GS1 support in Grid. I have been poking around the repo, any tips about layout or documentation of the repo will also be appreciated."

mwagner (Tue, 10 Sep 2019 11:50:52 GMT):
reminder: No PSWG call today

nkl199 (Mon, 16 Sep 2019 18:05:02 GMT):
apologies in advance - I will be unable to attend the call on the 17th

VipinB (Mon, 16 Sep 2019 21:04:21 GMT):
Started a conversation with grid folks about this, although they seem to be in the RFC phase (which is type and interface definitions) for the GS1 stuff, they have a product RFC as well as - I will take a look at GLN which seems to be their way of defining enterprises...

ChristianLF (Tue, 17 Sep 2019 20:44:07 GMT):
I have sent an email to the PSWG mailing list perf-and-scale-wg@lists.hyperledger.org as suggested by @mwagner can anyone confirm having received it

ChristianLF (Tue, 17 Sep 2019 20:52:26 GMT):
Ah ok it got in :)

VipinB (Tue, 17 Sep 2019 21:39:42 GMT):
Saw the one on HL Beam

VipinB (Tue, 17 Sep 2019 21:39:50 GMT):
@ChristianLF

ChristianLF (Tue, 17 Sep 2019 22:31:11 GMT):
Perfect, thanks for letting me know @VipinB

VipinB (Wed, 18 Sep 2019 12:06:21 GMT):
@ChristianLF is it similar to Cello? How is it different. I will also read it more carefully

ChristianLF (Wed, 18 Sep 2019 19:27:22 GMT):
Hey @VipinB thanks for the question, I will say no. The reason being is that Cello is more of a management tool for business who build on top of Hyperledger Projects. The proposed project Hyperledger Beam would allow for Businesses to build a blockchain("instance") on top of the Scroda Platform, in which they have complete control privacy control while still being able to utilize all of Scroda's Nodes thus allowing for Projects to have Privacy Control while still obtaining maximum security as a unlimited # of nodes are able to validate transactions all while still being scalable. You can think of it as Quorum but with the ability to obtain more security and scalability.

ChristianLF (Wed, 18 Sep 2019 19:27:22 GMT):
Hey @VipinB thanks for the question, I will say no. The reason being is that Cello is more of a management tool for businesses who build on top of Hyperledger Projects. The proposed project Hyperledger Beam would allow for Businesses to build a blockchain("instance") on top of the Scroda Platform, in which they have complete privacy control while still being able to utilize all of Scroda's Nodes thus allowing for Projects to have Privacy Control while still obtaining maximum security as a unlimited # of nodes are able to validate transactions all while still being scalable. You can think of it as Quorum but with the ability to obtain more security and scalability.

ChristianLF (Wed, 18 Sep 2019 19:27:22 GMT):
Hey @VipinB thanks for the question, I will say no. The reason being is that Cello is more of a management tool for businesses who build on top of Hyperledger Projects. The proposed project Hyperledger Beam would allow for Businesses to build a blockchain("instance") on top of the Scroda Platform, in which they have complete control privacy control while still being able to utilize all of Scroda's Nodes thus allowing for Projects to have Privacy Control while still obtaining maximum security as a unlimited # of nodes are able to validate transactions all while still being scalable. You can think of it as Quorum but with the ability to obtain more security and scalability.

dtomczyk (Sat, 21 Sep 2019 11:57:21 GMT):
Has joined the channel.

VipinB (Tue, 01 Oct 2019 14:27:44 GMT):
In light of today's discussion we see the following: https://gist.github.com/awemany/619a5722d129dec25abf5de211d971bd

VipinB (Tue, 01 Oct 2019 14:28:15 GMT):
The concept behind ZCF (Zero Confirmation Forfeits)

VipinB (Tue, 01 Oct 2019 14:28:52 GMT):
As a safety mechanism. ZC itself in BTC is transactions in mempool.

VipinB (Tue, 01 Oct 2019 14:31:30 GMT):
Essentially Beam proposes the idea of "Ordered ZC", by creating a blockchain (the Ying Chain) that proposes an order without confirmations, that is an ordered mempool if you will.

VipinB (Tue, 01 Oct 2019 14:34:16 GMT):
Also relies on Scroda DID for admission and DOS attacks by limiting entry

ChristianLF (Tue, 01 Oct 2019 14:49:01 GMT):
Thanks for allowing me to present today, to note the ZCF concept only protects against short-term attacks such as a double-spend attack used to redirect a payment that was sent to a merchant in order to spend the funds already used in the transaction before a blockchain confirmation. An unspent output is spent in two different transactions and a miner must choose between one of them. This does not protect against long-term attacks such as a 51% attack fork. While preventing double spending attack is also protects from 51% attacks by offering a fork-free environment. Also this relies on Scroda ID a decentralized identity system in order to identify all nodes participating in consensus, this does not limit entry, DOS attacks are prevented through the identification phase in use of Scroda ID.

ChristianLF (Tue, 01 Oct 2019 14:49:01 GMT):
Thanks for allowing me to present today, to note the ZCF concept only protects against short-term attacks such as "a double-spend attack used to redirect a payment that was sent to a merchant in order to spend the funds already used in the transaction before a blockchain confirmation. An unspent output is spent in two different transactions and a miner must choose between one of them." This does not protect against long-term attacks such as a 51% attack fork. While preventing double spending attack is also protects from 51% attacks by offering a fork-free environment. Also this relies on Scroda ID a decentralized identity system in order to identify all nodes participating in consensus, this does not limit entry, DOS attacks are prevented through the identification phase in use of Scroda ID.

ChristianLF (Tue, 01 Oct 2019 14:49:01 GMT):
Thanks for allowing me to present today, to note the ZCF concept only protects against short-term attacks such as "a double-spend attack used to redirect a payment that was sent to a merchant in order to spend the funds already used in the transaction before a blockchain confirmation. An unspent output is spent in two different transactions and a miner must choose between one of them." This does not protect against long-term attacks such as a 51% attack fork. While preventing double spending attack Beam also protects from 51% attacks by offering a fork-free environment. Also this relies on Scroda ID a decentralized identity system in order to identify all nodes participating in consensus, this does not limit entry, DOS attacks are prevented through the identification phase in use of Scroda ID.

ChristianLF (Tue, 01 Oct 2019 14:49:08 GMT):
Again glad to have been provided the opportunity to present the project today.

VipinB (Tue, 01 Oct 2019 15:29:49 GMT):
@ChristianLF Please direct us to the post where you distinguish between ZC and unconfirmed transactions in your context.

ChristianLF (Tue, 01 Oct 2019 17:38:04 GMT):
Wow it seems that I deleted the blog post differentiating it as I thought it had no use. Zero-Confirmation Transactions and Unconfirmed transactions are technically the same, these are transactions that have yet to validated by the network, in which consensus has not been reached on. All current blockchains reach consensus at some point in time since blockchain's are trust-less. In these situations users can be assured that even though the network has not reached consensus on a transactions that it will be included on the blockchain if true. Through this assurance they are able to safely accept a payment after having received it and solely verifying its validity. Now Instant Transactions are different than Zero-Confirmation Transactions, Instant Transactions are where consensus on a transaction is reached instantly, this is not recommended as such a system will be guaranteed to have security flaws. As we all know the more users we are communicating with the longer it takes for an agreement to be reached as a whole. Zero-Confirmation Transactions is the most viable route as consensus does not have to be speed up in order for payments to be accepted and considered safe once received.

ChristianLF (Tue, 01 Oct 2019 17:38:04 GMT):
Wow it seems that I deleted the blog post differentiating it as I thought it had no use. Zero-Confirmation Transactions and Unconfirmed transactions are technically the same, these are transactions that have yet to be validated by the network, in which consensus has not been reached on. All current blockchains reach consensus at some point in time since blockchain's are trust-less. In these situations users can be assured that even though the network has not reached consensus on a transactions that it will be included on the blockchain if true. Through this assurance they are able to safely accept a payment after having received it and solely verifying its validity. Now Instant Transactions are different than Zero-Confirmation Transactions, Instant Transactions are where consensus on a transaction is reached instantly, this is not recommended as such a system will be guaranteed to have security flaws. As we all know the more users we are communicating with the longer it takes for an agreement to be reached as a whole. Zero-Confirmation Transactions is the most viable route as consensus does not have to be speed up in order for payments to be accepted and considered safe once received.

VipinB (Tue, 01 Oct 2019 22:23:55 GMT):
Also to be clear ZCF is in the context of BTC which already has a consensus mechanism which is POW can result in problems due to lack of finality. I understand that your initial ordering uses one of the BFT variants which provide finality. In this context I can see the use for ZC before they join the second chain. We did not discuss Instant transactions on the call IIRC. I agree with your observations on Instant transactions. All in all, I hope that it was worthwhile for you to present on the call. Especially Imre's comments. @ChristianLF @ikocsis -

VipinB (Tue, 01 Oct 2019 22:23:55 GMT):
at here was locked out for general users due to abuse. @rjones should be able to grant it to @mwagner who should be a moderator on this channel. I have that privilege on #identity-wg and #capital-markets-sig

ikocsis (Thu, 03 Oct 2019 15:06:42 GMT):
Thanks, Vipin!

mwagner (Mon, 14 Oct 2019 12:03:00 GMT):
anyone have suggestions for an agenda this week ?

mwagner (Tue, 15 Oct 2019 12:58:28 GMT):
no call today

mwagner (Mon, 21 Oct 2019 20:10:54 GMT):
is there anyone out there ?

VipinB (Mon, 21 Oct 2019 20:23:43 GMT):
Try using "here" to get to eveyone

nkl199 (Tue, 22 Oct 2019 07:51:10 GMT):
I'm here, but in a very different time zone :joy: - i think the `at here` is locked out of this channel?

VipinB (Tue, 22 Oct 2019 15:52:50 GMT):
at here was locked out for general users due to abuse. rjones should be able to grant it to mwagner who should be a moderator on this channel. I have that privilege on #identity-wg and #capital-markets-sig

shemnon (Thu, 24 Oct 2019 02:05:32 GMT):
Has joined the channel.

nkl199 (Fri, 25 Oct 2019 13:02:14 GMT):
Related news from Caliper: the latest release (v0.2.0) now supports Hypereledger Besu, Ethereum, and FISCO BCOS

mwagner (Fri, 25 Oct 2019 13:34:13 GMT):
nice!

joe_k (Tue, 29 Oct 2019 19:54:56 GMT):
Has left the channel.

shemnon (Tue, 05 Nov 2019 20:50:46 GMT):
Regarding todays call, one thought that crossed my mind would be some sort of a measure of TPS and RPS under byzantine circumstances. For example, a 4 node system where 1 node is no longer responding to or participating in consensus. Or a 7 node with 2 out, or a system experienceing regular network splits. The most repetable one is for a network with nodes that drop out just prior to measurement.

VipinB (Wed, 06 Nov 2019 01:58:10 GMT):
Minutes of the meeting as far as I remember them: Mark Wagner introduced the theme of the meeting which was to reboot the PSWG under the new regime of the TSC, do away with WGs and come up with new names (either TIG or TSIG), there would be no work products. -We harked back to the work products, our initial paper on some common terms and current effort to develop common benchmarks looking at a provenance or supply chain use case -Nick felt that Caliper would need standard benchmarks -Vipin said that performance and scale were problems that have to be overcome to have widespread adoption of blockchains (even public Blockchains suffer from this) -Dano Ferrin said that we could look at the differences with permissionless blockchains and look at whether we need different metrics Todd said that he was heading up an ISO conference on DLTs, they did not have the concept of finality and they had lots of concepts that were slightly different from what we had in the paper. We all agreed: 1. change cadence to once fortnightly 2. Adopt what name the TSC comes up with 3. Take another look at the metrics paper to update it or make it a living document. 4. Continue having presentations. Vipin said that these presentations could yield greater truths applicable to all blockchains like work on microservices to scale blockchain nodes a la fastfabric, have aggregators or pre-processing to create more throughput (like accelerator) and have greater focus on datastore performance through caching to remove a bottleneck or all of the above to improve BC throughput. We also agreed to work more closely with caliper. TPS or RPS in a stressed DLT (Dano Ferrin suggests above)

CT123 (Wed, 06 Nov 2019 22:04:12 GMT):
Has joined the channel.

antoniovassell (Wed, 06 Nov 2019 22:20:05 GMT):
Hi all, I have 4 peers, each running on a t2.small instance (1 CPU, 2gb ram) in one org, there is also 5 orderers each in there own instance My issue is that i am seeing high memory usage, up to 70-80% on most of the peers, even though no transactions are being done. After a certain time, the peer containers will just stop running. I can easily reboot the peer node if memory is high (or restart the container), but the memory usage will just keep increasing until the container stops working again Before the container stops, some errors that I see in the peer logs are: [31m2019-11-05 23:58:38.599 UTC [core.comm] ServerHandshake -> ERRO 48c0[0m TLS handshake failed with error write tcp 172.1.1.1:7051->3.1.1.1:40936: i/o timeout server=PeerServer remoteaddress=3.1.1.1:40936 And errors from the chaincode instance: 2019-11-06T00:06:40.616Z [31mERROR[39m [31m[lib/handler.js][39m Chat stream with peer - on error: "Error: 14 UNAVAILABLE: keepalive watchdog timeout\n at Object.exports.createStatusError (/usr/local/src/node_modules/grpc/src/common.js:91:15)\n at ClientDuplexStream._emitStatusIfDone (/usr/local/src/node_modules/grpc/src/client.js:233:26)\n at ClientDuplexStream._receiveStatus (/usr/local/src/node_modules/grpc/src/client.js:211:8)\n at Object.onReceiveStatus (/usr/local/src/node_modules/grpc/src/client_interceptors.js:1306:15)\n at InterceptingListener._callNext (/usr/local/src/node_modules/grpc/src/client_interceptors.js:568:42)\n at InterceptingListener.onReceiveStatus (/usr/local/src/node_modules/grpc/src/client_interceptors.js:618:8)\n at /usr/local/src/node_modules/grpc/src/client_interceptors.js:1123:18" Questions are: - Where/how could I investigate the memory issues? I tried a few things but nothing I can see why the memory keeps increasing - Is the specs (1cpu, 2gb ram) too low? - Does the amount of peers (4 in this case) affects the total memory of each individual peer (probably because of gossip, and other communication, etc) ?

antoniovassell (Wed, 06 Nov 2019 22:20:05 GMT):
Hi all, I have 4 peers, each running on a t2.small instance (1 CPU, 2gb ram) in one org, there is also 5 orderers each in there own instance My issue is that i am seeing high memory usage, up to 70-80% on most of the peers, even though no transactions are being done. After a certain time, the peer containers will just stop running. I can easily reboot the peer node if memory is high (or restart the container), but the memory usage will just keep increasing until the container stops working again Before the container stops, some errors that I see in the peer logs are: ```[31m2019-11-05 23:58:38.599 UTC [core.comm] ServerHandshake -> ERRO 48c0[0m TLS handshake failed with error write tcp 172.1.1.1:7051->3.1.1.1:40936: i/o timeout server=PeerServer remoteaddress=3.1.1.1:40936`` And errors from the chaincode instance: ```2019-11-06T00:06:40.616Z [31mERROR[39m [31m[lib/handler.js][39m Chat stream with peer - on error: "Error: 14 UNAVAILABLE: keepalive watchdog timeout\n at Object.exports.createStatusError (/usr/local/src/node_modules/grpc/src/common.js:91:15)\n at ClientDuplexStream._emitStatusIfDone (/usr/local/src/node_modules/grpc/src/client.js:233:26)\n at ClientDuplexStream._receiveStatus (/usr/local/src/node_modules/grpc/src/client.js:211:8)\n at Object.onReceiveStatus (/usr/local/src/node_modules/grpc/src/client_interceptors.js:1306:15)\n at InterceptingListener._callNext (/usr/local/src/node_modules/grpc/src/client_interceptors.js:568:42)\n at InterceptingListener.onReceiveStatus (/usr/local/src/node_modules/grpc/src/client_interceptors.js:618:8)\n at /usr/local/src/node_modules/grpc/src/client_interceptors.js:1123:18"``` Questions are: - Where/how could I investigate the memory issues? I tried a few things but nothing I can see why the memory keeps increasing - Is the specs (1cpu, 2gb ram) too low? - Does the amount of peers (4 in this case) affects the total memory of each individual peer (probably because of gossip, and other communication, etc) ?

antoniovassell (Wed, 06 Nov 2019 22:20:05 GMT):
Hi all, I have 4 peers, each running on a t2.small instance (1 CPU, 2gb ram) in one org, there is also 5 orderers each in there own instance My issue is that i am seeing high memory usage, up to 70-80% on most of the peers, even though no transactions are being done. After a certain time, the peer containers will just stop running. I can easily reboot the peer node if memory is high (or restart the container), but the memory usage will just keep increasing until the container stops working again Before the container stops, some errors that I see in the peer logs are: ```[31m2019-11-05 23:58:38.599 UTC [core.comm] ServerHandshake -> ERRO 48c0[0m TLS handshake failed with error write tcp 172.1.1.1:7051->3.1.1.1:40936: i/o timeout server=PeerServer remoteaddress=3.1.1.1:40936``` And errors from the chaincode instance: ```2019-11-06T00:06:40.616Z [31mERROR[39m [31m[lib/handler.js][39m Chat stream with peer - on error: "Error: 14 UNAVAILABLE: keepalive watchdog timeout\n at Object.exports.createStatusError (/usr/local/src/node_modules/grpc/src/common.js:91:15)\n at ClientDuplexStream._emitStatusIfDone (/usr/local/src/node_modules/grpc/src/client.js:233:26)\n at ClientDuplexStream._receiveStatus (/usr/local/src/node_modules/grpc/src/client.js:211:8)\n at Object.onReceiveStatus (/usr/local/src/node_modules/grpc/src/client_interceptors.js:1306:15)\n at InterceptingListener._callNext (/usr/local/src/node_modules/grpc/src/client_interceptors.js:568:42)\n at InterceptingListener.onReceiveStatus (/usr/local/src/node_modules/grpc/src/client_interceptors.js:618:8)\n at /usr/local/src/node_modules/grpc/src/client_interceptors.js:1123:18"``` Questions are: - Where/how could I investigate the memory issues? I tried a few things but nothing I can see why the memory keeps increasing - Is the specs (1cpu, 2gb ram) too low? - Does the amount of peers (4 in this case) affects the total memory of each individual peer (probably because of gossip, and other communication, etc) ?

VipinB (Thu, 07 Nov 2019 15:24:31 GMT):
@antoniovassell please pose the question on #fabric

antoniovassell (Thu, 07 Nov 2019 15:27:51 GMT):
Hey @VipinB , Okay I will do so

SuperSeiyan (Mon, 11 Nov 2019 05:18:45 GMT):
Has joined the channel.

iampukar (Thu, 28 Nov 2019 06:17:04 GMT):
Has joined the channel.

marcus.mello (Thu, 05 Dec 2019 00:55:42 GMT):
Has joined the channel.

BranimirMalesevic (Thu, 12 Dec 2019 09:19:11 GMT):
Has joined the channel.

stone-ch (Sun, 15 Dec 2019 04:40:33 GMT):
Has left the channel.

konda.kalyan (Thu, 26 Dec 2019 06:03:44 GMT):
Has joined the channel.

Silona (Tue, 14 Jan 2020 16:50:45 GMT):
Help Us Help you! Attend the Developer Relationship Meeting with Myself and our Marketing Dept. tomorrow at 9:00am Pacific Time. For the agenda and Dial in info https://wiki.hyperledger.org/display/Marketing/2020-01-15+Meeting+notes

Silona (Tue, 14 Jan 2020 17:05:36 GMT):
Calling all Projects, SIG, and WG!!! We will have a Video recording Studio setup at HGF (Hyperledger Global Forum). We are asking that all projects and groups help us create a 5 minute video about your group so that we can promote it afterward. Sign up Here! https://wiki.hyperledger.org/display/HGF/Video+Recording+Schedule

parthibanselvaraj (Thu, 16 Jan 2020 06:06:35 GMT):
Has joined the channel.

Dan (Mon, 27 Jan 2020 17:14:34 GMT):
Hi Everyone, We are hoping to hear from everyone as we assess the health of our open source community. Please take 2 minutes to respond here: https://www.surveymonkey.com/r/DCIWGsurvey

Silona (Mon, 27 Jan 2020 22:27:17 GMT):
The Linux Foundation’s CommunityBridge engineers are working on a tool to measure the health of critical open source projects and one of the key areas identified is QA Testing. They request that our communities provide honest and detailed information on testing tools and methodologies you use in your projects for us to come up with a detailed analysis, which they will share with all respondents and projects. https://www.surveymonkey.com/r/9H5G2GV. It’s only 5 questions long.

Silona (Thu, 13 Feb 2020 18:25:58 GMT):
Howdy Contributors and Maintainers! Are you wondering about tapping into Developer marketing for your group or project? Do you have a blog post idea? An awesome announcement? Please attend our Contributor/marketing meeting! https://wiki.hyperledger.org/display/Marketing/2020-02-19+Meeting+notes

Silona (Mon, 17 Feb 2020 22:19:03 GMT):
Are you wondering about tapping into Developer marketing for your group or project? Do you have a blog post idea? An awesome announcement? Please attend TOMORROW! https://wiki.hyperledger.org/display/Marketing/2020-02-19+Meeting+notes

YokeshSankar (Fri, 06 Mar 2020 07:52:50 GMT):
Has joined the channel.

mwagner (Tue, 07 Apr 2020 11:36:26 GMT):
no PSWG call today

kumar89 (Tue, 07 Apr 2020 15:56:33 GMT):
Has joined the channel.

NehaGhogale-inn (Mon, 13 Apr 2020 09:51:43 GMT):
Has joined the channel.

SusheelDighade (Tue, 14 Apr 2020 14:42:00 GMT):
Has joined the channel.

cliveb (Thu, 16 Apr 2020 03:35:47 GMT):
Has left the channel.

mwagner (Tue, 21 Apr 2020 12:40:42 GMT):
PSWG call in 20 minutes

VipinB (Tue, 21 Apr 2020 19:36:09 GMT):
Great call y'all -

VipinB (Tue, 21 Apr 2020 19:37:43 GMT):
@mwagner - Will you make the recording available? Also @klenik @ikocsis are the slides freely available as well?

mwagner (Wed, 22 Apr 2020 00:52:36 GMT):
yes I will work on that tomorrow

SviatoslavButskyi (Sun, 26 Apr 2020 11:42:57 GMT):
Has joined the channel.

SviatoslavButskyi (Sun, 26 Apr 2020 12:29:39 GMT):
Hi all, I am looking how to work and contribute to several topics: 1. Deletion on Blockchain: are there any initiatives here? 2. Performance analysis among different implementations of HL 3. Network partitioning: Any initiatives, data, etc.? How do I look for the available work on the topics? Thanks!

knagware9 (Mon, 27 Apr 2020 06:23:29 GMT):
check here https://github.com/hyperledger/fabric-rfcs/pulls

SviatoslavButskyi (Mon, 27 Apr 2020 08:59:31 GMT):
Thank you!

VipinB (Tue, 28 Apr 2020 13:08:57 GMT):
Call today?

mwagner (Tue, 28 Apr 2020 19:03:42 GMT):
no call is every other week

VipinB (Tue, 28 Apr 2020 19:23:28 GMT):
OK... I was still going by our earlier schedule.

mwagner (Mon, 04 May 2020 20:21:38 GMT):
Does anyone have topics for this weeks call?

pvrbharg (Fri, 15 May 2020 22:15:14 GMT):
Hi team - Looking for some guidance - has any performance and scalability testing on PDC - in the context of HLF with volumes of 10-20 million records to 100-200 million records. PDC is in play due to regulations, compliance and need to know basis information sharing. The use case also needs long term retention of information. About 10% volume can be a target for queries. We are assuming couchdb or other supported persistent/durable versioned object stores. Please let us know. Thanks

mwagner (Mon, 01 Jun 2020 02:52:07 GMT):
Any topics for a call this week ?

mwagner (Tue, 02 Jun 2020 00:07:50 GMT):
no meeting this week

sillysachin (Fri, 12 Jun 2020 14:04:18 GMT):
A million records per day can easily add 10-15GB in couchdb and deteriorate the performance by 150-200%

VipinB (Fri, 12 Jun 2020 17:12:17 GMT):
Saw that some of the solutions for such huge amounts of data segregated on a separate DFS like IPFS (encrypted of course) or on a separate datalake with proofs etc. in PDC. Blockchain is not distributed db.

pvrbharg (Tue, 16 Jun 2020 16:06:27 GMT):
@sillysachin @VipinB Thank you to each for sharing your wisdom and this requires some thinking - in terms of scaling horizontally or using IPFS at PDC layer, per my read. Best wishes.

trbs (Wed, 01 Jul 2020 19:40:42 GMT):
Has left the channel.

assit (Sat, 04 Jul 2020 04:51:51 GMT):
Has joined the channel.

marcdk (Mon, 06 Jul 2020 05:31:01 GMT):
Has joined the channel.

ever-upwards (Tue, 07 Jul 2020 11:40:29 GMT):
Has joined the channel.

bobinson (Mon, 13 Jul 2020 21:14:58 GMT):
Has joined the channel.

bobinson (Mon, 13 Jul 2020 21:18:32 GMT):
Hi Channel - I am working on performance benchmark of a PoS chain with the Caliper Framework. I had attempted this an year ago or so but the priorities changed. I would love to contribute and also hear from others who might have done benchmarks for various chains.

mwagner (Tue, 28 Jul 2020 12:16:38 GMT):
no PSWG call today

bobinson (Tue, 04 Aug 2020 13:43:32 GMT):
ha! I didn't see this message and was there alone ;-)

dhawalthakker (Thu, 20 Aug 2020 20:02:43 GMT):
Has joined the channel.

mwagner (Mon, 24 Aug 2020 17:40:36 GMT):
no meeting this week (Aug 25). We will meet Sep 8th

davidwboswell (Wed, 26 Aug 2020 14:48:16 GMT):
Has joined the channel.

davidwboswell (Wed, 26 Aug 2020 20:19:23 GMT):
I'm helping organize a virtual Hyperledger meetup on Sep 14 that will be focused on performance. Xilinx will demo their hardware acceleration work and there is space in the agenda for others to demo other performance related efforts. Let me know if you'd like some space in the meetup. This could also be a good opportunity to feature the work of the PSWG and promote that to a wider audience. We were thinking of having a discussion around performance after the demos, so would someone here want to moderate that? You could introduce yourself and this group to the attendees when the discussion starts.

AbhinavMakker (Wed, 09 Sep 2020 18:49:03 GMT):
Has joined the channel.

davidwboswell (Mon, 14 Sep 2020 14:55:45 GMT):
Today, Sep 14, at 10AM pacific, join us for a virtual Hyperledger meetup focused on performance. Sundararajarao Mohan from Xilinx will share a demo of the work they've done with using hardware acceleration to increase blockchain performance. All are welcome. https://www.meetup.com/Hyperledger-SF/events/267518835/

VipinB (Mon, 14 Sep 2020 19:00:40 GMT):
Great call...

davidwboswell (Mon, 14 Sep 2020 21:29:38 GMT):
@VipinB -- yeah, i thought it went well. thanks for joining.

davidwboswell (Mon, 14 Sep 2020 21:30:03 GMT):
for anyone who missed today's meetup where Xilinx presented their hardware acceleration work and we had a good discussion about performance, the recording is at: https://www.youtube.com/watch?v=Nidw6zMR4hs

ashutosh_kumar (Sun, 20 Sep 2020 20:08:53 GMT):
Has joined the channel.

agiledeveloper (Sun, 27 Sep 2020 05:30:25 GMT):
Has joined the channel.

dgt1nsty (Fri, 02 Oct 2020 14:33:22 GMT):
Has joined the channel.

mwagner (Tue, 06 Oct 2020 12:16:30 GMT):
Reminder: meeting today in 45 minutes. new zoom number S WELL

mwagner (Tue, 06 Oct 2020 12:16:42 GMT):
as well

mwagner (Tue, 20 Oct 2020 12:58:45 GMT):
no meeting today

davidefreeman (Thu, 22 Oct 2020 16:27:53 GMT):
Has joined the channel.

xingyuan426 (Fri, 13 Nov 2020 01:56:14 GMT):
Has joined the channel.

adgupta011 (Thu, 19 Nov 2020 16:32:14 GMT):
Has joined the channel.

stone-ch (Tue, 08 Dec 2020 13:49:47 GMT):
Has joined the channel.

shemnon (Sun, 21 Mar 2021 05:01:00 GMT):
Has left the channel.

skymatrix (Sun, 25 Apr 2021 10:44:22 GMT):
Has joined the channel.

skymatrix (Sun, 25 Apr 2021 10:48:17 GMT):
Hello guys, please am very new to this block chain hyperleger, and am to use it to implement electronic voting system on it for nations election, but all my reviews the consensus have having trade off between scalability and performance, but with this my project the system should have good scalability and good performance. Help please

davidwboswell (Mon, 10 May 2021 21:48:50 GMT):
@skymatrix -- thanks for sharing about what you're looking at doing with blockchain. for your question, i'd suggest asking about it on the performance and scale group's mailing list. this chat channel doesn't have many people in it so you'd get a better response on the list. that is at: https://lists.hyperledger.org/g/perf-and-scale-wg/

davidwboswell (Mon, 10 May 2021 21:49:09 GMT):
and the group is having a meeting next week and you'd be welcome to join that as well. https://wiki.hyperledger.org/display/PSWG/PSWG+May+18%2C+2021

toddinpal (Tue, 15 Jun 2021 17:55:48 GMT):
Thanks for the presentation. I didn't quite follow the discussions/comments on the relationship between Tape and Caliper... can you elaborate on which one to use for which situation as well as any thoughts/plans to merge them?

Skyquek (Fri, 25 Jun 2021 16:06:25 GMT):
Has joined the channel.

pmn2090 (Sat, 03 Jul 2021 01:10:08 GMT):
Has joined the channel.

ArchitaDasgupta (Mon, 06 Sep 2021 12:52:33 GMT):
Has joined the channel.

klenik (Tue, 14 Dec 2021 15:52:58 GMT):
Hi All! By any chance, will you have a meeting minutes available somewhere about today's call? Or any quick recap about the key points would be greatly appreciated :)

SeanBohan (Fri, 17 Dec 2021 20:05:40 GMT):
Has joined the channel.

sbohanlf (Tue, 25 Jan 2022 15:25:15 GMT):
Has joined the channel.

CaixiangFan (Fri, 04 Feb 2022 20:21:39 GMT):
Hi team, I am using Caliper to test Besu which runs IBFT2.0 and has 4 validator nodes (all with ws-RPC enabled). I can successfully benchmark the Besu network by connecting one validator as the endpoint. But the high RPC request rate will saturate the connected validator node. I am wondering how I can set up the test with load balance so that all Besu validators can receive RPC requests. Any suggestions would be appreciated. Thank you.

davidkel (Mon, 07 Feb 2022 18:55:30 GMT):
Has joined the channel.

Param-S (Tue, 08 Feb 2022 07:51:42 GMT):
Has joined the channel.

davidkel (Mon, 14 Feb 2022 17:33:36 GMT):
Looking at the ethereum connector code it doesn't look like it supports that kind of capability

rjones (Wed, 23 Mar 2022 17:35:48 GMT):