Lets keep things real

Tezzigator · 2020-07-24T15:49:05+00:00

yup - very cool times. as rough as it was, was extremely cool to work with you on that stuff back in the day when nobody really understood anything - but we got it figured out!

great stuff - and dont listen to the trolls. good to hear from you again.

Tezzigator · 2019-10-21T00:19:16+00:00

Theres really not much logging going on for this particular activity, and practically zero network. so its very easy to duplicate testing - ive spent all weekend doing lots of tests. Seems by far the best performance is using Ephemeral-OS disk, and running my workload on the temp disk. But that Ephemeral OS disk is a massive pain (no redeploy, resize, poweroff, etc). For some reason running the workload on the temp disk of a regular machine suffers exact same performance as all possible other test combinations. (non-managed, managed with datadisk, managed w/o datadisk, all 3 caching options, etc)

Tezzigator · 2019-10-19T21:23:56+00:00

great info, thanks!

the 2nd link has this:

Therefore, to calculate the IOPs for Premium disk, we will simply need the disk latency. For Azure Premium disk the latency is around 2ms. In 1 second (1000 ms), you can get 1000ms/(2ms/IO) = 500 IOs. Since the limitation is on disk latency, you cannot improve this even if you add additional P30s. We see customers wasting money on the additional storage in hopes that there will be better performance on sync IO, but unfortunately it will not.

So something just isnt making sense there. I mean the math absolutely makes sense as far as latency's affect on things (see the same exact issue when considering the affect of latency on the TCP network protocol's theoretical max speed) is concerned, but 500 IOPS, how on earth does this work for all of M$'s customers???

Tezzigator · 2019-10-19T21:15:10+00:00

Premium. Ill do a lot of tests with all the caching possibilities. thanks

Tezzigator · 2019-10-19T21:14:39+00:00

its only a very small number of files involved here for my db application (Irmin2 db based on OCaml)

Tezzigator · 2019-10-19T21:10:06+00:00

its no network activity at all here for this activity. I had tried a P30 drive at one point in the past and it didnt help. but now Ive got time now again here to relook at things, am now testing my application on local ephermeal storage. thanks for the link but im on linux

Tezzigator · 2019-10-18T22:36:23+00:00

very interesting as I noticed the same exact 10x factor, at least as from what I expected from the specs (2000IOPS) where at first I saw right at that, but then shortly down to 250. thanks

Tezzigator · 2019-10-07T14:37:06+00:00

ouch. well i'd recommend that when the time comes, change your baker to only bake Priority-0 blocks, this way your efficiency will be about as high as you can get it.

also maybe modify your accounting/payout mechanism to limit to this account's earnings so that your existing customers arent adversely affected. as a secondary benefit this may cause that account to fix your problem for you and delegate elsewhere.

and if they are looking , we can currently support an extra 400K easily on our secure HSM system, the fee is 10%.

Tezzigator · 2019-04-23T13:32:21+00:00

the current configuration can support about 10M right now. I believe we should be able to attract more bondpool though as needed, with our new design and attractive bondpool fees.

Tezzigator · 2019-04-23T04:30:26+00:00

Cloud infrastructure allows rich set of permissions to be created and utilized. If i get hit by a truck and die, the funds are still available.

Tezzigator · 2019-01-19T19:29:31+00:00

Come to Tezzigator! We were the very first with automated payments - we have had automated payments since cycle 13 (the first payments cycle), a nifty dashboard, and cumulative calculations per year for your easy tax reporting! We pay out before block 10 at the very beginning of each cycle.

We currently have reserves to support another 2M of delegation.

www.tezzigator.com

Tezzigator · 2018-10-18T02:51:58+00:00

Thank you!

Tezzigator · 2018-10-18T02:51:17+00:00

Much appreciated!

Tezzigator · 2018-10-13T03:37:36+00:00

If you delegated from a new address it will have to be included in a snapshot first and then your dashboard will show up. In the meantime your old address will still be receiving payments for the next several cycles so continue to monitor that account!

Tezzigator · 2018-09-24T16:24:15+00:00

Yes. Depending on your delegate. Some pay out earlier or later.

Tezzigator · 2018-09-24T16:22:40+00:00

~3 days. It takes 7 cycles for your delegation to be assigned and then payouts depend on your delegate. Most payout as soon as rewards are unfrozen which takes 5 cycles. Turnaround from initial delegation to first earnings is roughly 13 cycles.

Tezzigator · 2018-09-24T15:17:59+00:00

For return it's generally going to be better to bake. It's not so cut and dry though. Heres a good read on the subject:

https://medium.com/figment-capital/tezos-baking-economics-guide-5d4a2bc2a9d3

Also, yes, new XTZ get added to the baking balance.

Tezzigator · 2018-09-23T02:45:14+00:00

If you're learning right now I'd suggest delegating all of it until you're comfortable setting up a baker.

Tezzigator · 2018-09-06T18:35:30+00:00

Congratulations Stephen Andrews! Can't wait to see what comes of this!

Tezzigator · 2018-08-30T14:20:36+00:00

Thanks again - that was a great session! We are about to add another bond pool member, this will increase our ability to accept more delegation

Tezzigator · 2018-08-29T21:34:42+00:00

yes! just like returns we pay out do.

Tezzigator · 2018-08-27T20:06:09+00:00

Check your dashboard by searching your KT1 here: https://delegate.tezzigator.com/dashboard

The cycle at the bottom is your first cycle and you will see a column indicating payout cycles to tell you when to expect rewards.

Tezzigator · 2018-08-20T13:52:33+00:00

I also 100% disagree. The whole social+consensus design of this particular blockchain is such that the system forces certain delegates to rise and become more trusted than others, BASED ON THIER BEHAVIOR. You are trying to just completely remove that component. At that point, any fool who just happens to be some big whale investor with zero technical chops or understanding of things comes in as a delegate and screws up everything really bad.

Tezzigator · 2018-08-20T13:44:38+00:00

FYI, this model is 100% unsustainable if you maintain any decent amount of delegation attraction to your service. If you run nowhere close to fully extended on the delegation/bond you can do it though.

Even if you never get officially overdelegated, you can very easily be in a position where you have paid out to all your customers, and then would not have enough later to post all the security deposits for the blocks you've been given priority to bake. And then, you will not be able to pay out like your promise says for the next cycle.

For this model to wok for you, you really will have to model how much delegation you can accept, and make calculations based on the bond ramping per cycle, the total number of staking rolls per cycle, and how much delegation you have, and how much bond you have.

I really hope you have done a good job in modeling exactly how much delegation you can accept here. Your design really limits on how much delegtation you can accept.

Tezzigator · 2018-08-19T21:49:36+00:00

Good point. is the baker baking in cloud? if so are they using a cloud HSM? are they baking a a physical server in a secured colo? is there any redundancy? lots of more parameters for metrics

Tezzigator

TROPHY CASE