Unlimited egress for beta test or limited=unlimited?

I have questions about payment.

  1. do traffic limits work?
  2. What happens if I continue to test downloads, will I have to pay for your accounting errors?
    Now the satellite is serving my downloads without any restrictions and messages about exceeding the limit.
    image

    @jocelyn, @Alexey, @littleskunk
4 Likes

Accounting and traffic limits are 2 different features. Yes you will have to pay for the traffic even if there is a bug in the traffic limitation.
In this example that would mean 90$ - 55$ coupon = at least a bill of 45$ that you will have to pay.

By the way, could you share you Billing page and Billing history?
I think you will not be charged for 2TB egress.

Your screenshot shows your stats for this month, this is not the page where you will see what you are getting billed. That information in on the Billing page. If you click on “Billing” you can see the current month (March) estimated charges under “Usage Charges” - and see the detailed charges broken down for your project by storage, egress and objects by clicking on the blue arrow to the left of “Usage Charges” and then again on the arrow next to your project (right now there is only one project you can have, but in the future you would be able to see billed charges for each project separately). You can also scroll down on the billing page to see the Deposit and Billing History for previous months. If you had been charged anything for February, you would see that there. This should only have happened if your billable usage went above the free limits in February. What you see on the Overview Details page screenshot as “Egress limits used” I think is the total egress that was actually used on the network, which is including the expansion factor, but as you can see the Report page shows a much lower number of the egress usage that you would get billed for.

Ok, let’s calculate!
Step 1: usage


Step 2: simple math
1.22TB * $30 = $36.6
Step 3: Billing

$54.7 WHAT?!
Step 4: stop using Tardigrade? :slight_smile:

Then as a user I will stay as far away from such a project as possible. And I will not recommend others to use Tardigrade. Nobody needs problems like “I’m ready to spend X and they told me that I will not spend more than this amount, but in the final report they ask for 3x”

2 Likes

Another incomprehensible moment in billing.


Does this mean that 1 TB of outgoing traffic is free? If so, then the first calculation message looks even weirder.

1 Like

Thanks for posting your billing details. I think there is a misunderstanding about how our coupons work. The coupon was for a total of $55 worth of charges, so this would cover 1 TB of storage and 1 TB of egress (assuming you did not upload a big number of very small files, in which case the object fee charges would not be neglegible). The total $55 credit from this coupon could be used for any usage charges spread out over the first 2 billing periods. You only used up 5.5633 TB-hours out of 720 TB-hours of storage in the first month, and only part of the 1 TB egress, so this was not billed to you for february (no charges appear for february in your Billing history). Please note that the price for egress is $45 per TB and not $30, as you can see on our tardigrade webpage so the estimated charges so far for march for egress are pretty close to what would be expected. However, please note that afaik the current month estimated usage charges do not yet take into account any credits you have still available from the 1 TB coupon for egress. You used about $0.08 for the 5.56 TBh of storage last month, about $0.19 for object fees and $21.51 for egress. So a total of about $21.78 you did not get charged for in February usage. That leaves still $55 - $21.78= $33.22 you can still use to cover any combination of storage, bandwidth and object fees incurred this month. So I expect that you should still could use the remaining balance of the coupon to pay for about 738 GB of your total egress this month. Which means that only 1.2206 TB - 738 GB = 482.6 GB of egress so far this month are billable, which would be about $21.72 for egress so far this month. This assuming that you will also pay full price of $10 per TB for storage this month, plus any object fee (should be small).

The pricing is wrong. Where did you see $30 per TB?

55$ are free. That would match 1 TB stored for a full month plus 1 TB download traffic. If you store less you can download it a few more times and the 55$ coupon would still cover it. (Note the wording “coupon” might change. I am using the wording of the implementation even if we call it different on the frontend later)

1 TB stored for a full month would be 720 TBh. On the screenshot I see only 5.5 TBh. If I did the math correct that would be about 8 cent.

2 Likes

I have corrected my estimates for storage charges in my previous post, thanks!

Thanks, I’m out. Extremely complicated and non-transparent billing.

  1. Bugs everywhere.
  2. Can’t upload files (Upload via uplink stuck)
  3. Bugs in billing
  4. Upload factor x3
  5. Price scaleway + one more DC will be a lot cheaper and more safe (https://www.scaleway.com/en/c14-cold-storage/)
1 Like

point 1: We are still in beta, so bugs should be expected and we are working on fixing all bugs asap.
point 2: I do not have enough details regarding the exact problems you are encountering with uploading files to be able to comment. However, it may be a rate limiting issue, and you could have filed a support ticket to request a limit increase in that case.
point 3: I just explained above how billing works. I don’t see any bugs. The calculations are working as intended. Please point out where you see a “bug”. I would agree that the UI could definitely be improved to make the billing easier to understand, and I have already sent suggested improvements to the billing team to allow customers to easier understand their bills. We are also going to soon publish documentation that will explain all aspects of billing in detail.
point 4: What is your issue with this? We use erasure coding so there is an expansion factor to assure that no files are lost. The customer should not get billed for 3x the size of the files they uploaded. Storj absorbs the cost of storing the additional data.
Point 5: I cannot comment on scaleway, but if you feel that this is a better option for your usecase, then by all means.

Thank you for testing our product and pointing out how we can improve it. We are sorry to see you leave so close to production release, by which time we expect to have the remaining issues resolved.

1 Like

point 1:

point 2: just READ my theme with FULL LOGS: Upload via uplink stuck
point 3: look at point 1
point 4: This should not be done by the client. Just look at Amazon, Google Cloud, Scaleway…

points 1 and 3: what you call bugs are mostly just UI issues. Like I mentioned before, I have already pointed this out to the billing team. Note that there are bandwidth rate limits in place already. If there is an issue with limits on amount of data you can upload, I am sure those will be also addressed.
Point 4: I am not sure what you are referring to by “This should be done by the client.” Please could you be more specific? Are you saying you would prefer us to just store a file in a single location without regards to ensuring that the file will not be lost? I don’t think that many customers would agree to accept a risk of losing their files.

I think point 4 is pointing that uplink shold give some message or error when limit reach, that clinet sholdnt monitor itself that limits.

If that is a feature customers are asking for, they should post their suggestions in our ideas portal and if enough people upvote it, it will be considered for development. Again, this is a UI improvement.

how much voices is enoth to implement feature, it always was not understandoble for me.
some have much more voices and marked as will be not implemented, other have some voices and planed to implement. so it not very transparent.

But it shold be other thread to speak about that.

1 Like

the number of upvotes is not the only deciding factor. The project manager periodically reviews and adds to upcoming sprints the features that are feasible for implementation in the short term (i.e. there is a cost/benefit evaluation - we cannot implement all features that are popular with users, as some of them could take many dev hours to implement or may not be deemed to be advantageous to Storj and its customers.

The client has to communicate directly with the nodes. If it had to go through some centralized server, Storj would probably be slower than conventional cloud storage. By directly communicating with many nodes in parallel it can achieve speeds way higher than conventional cloud storage (emphasis on ‘can’ because I am fairly certain this is not the case (yet) right now).

If you value low network usage over performance you indeed should not be using this.

1 Like

“In other words, our mistake, but you have to pay.”
How do you want to grow your customer base with this policy?

Again, please point out how do you think you are overpaying. Which part of the calculations I showed in my earlier post do you take issue with?