Hi GreenReaper, thanks for your questions. I'm happy to answer as best we can. However I'd like to make very clear at the start:
We currently don't even monitor this! We have some internal tools that monitor our overall connection usage and if this suddenly jumps we'll likely start manually having a look at those customers, but unless that is triggered, it really is a soft limit.
That said, we do have a specification for how this will work (and it was due to be being started this week, up until another priority bumped it down the list again), so I can answer from the point of view of that specification.
GreenReaper wrote on 9 May 2019 at 14:48:52
Actual bandwidth does not appear to be specified..., so presumably the badwidth available to an instance of this type is at least 200Mbps.
We currently have a 1Gbps uplink to the internet, this is currently being upgraded to a 10Gbps connection to some parts of the internet (some exchanges aren't running 10Gb yet, so it won't be entirely 10Gbp everywhere).
The bandwidth available to all instances is the same, larger instances don't get a higher throughput connection.
What is the definition of "transfer"? Bytes in, out (like AWS/Azure/Google), the max of in and out (Vultr), or the sum of in and out (LeaseWeb)? If it is credit-based, do you get credits for each direction that only apply in that direction; or do they apply to both?
The way it will work is based on the total transmitted and received bytes on the pseudo-public interface within a month.
On what period does the pooling operate? If I start a Large instance early in a month, then convert to Extra Small, is the Large transfer allocation added on a per-minute basis as "credit" available for use by Extra Small later in the month; or does pooling only operate across instances active during the same minute? (Or hour? The billing is listed per hour, but I saw that instance creation and termination is recorded to the minute.)
The pooling operates effectively using credits for the time those instances are running. Let's say you launch a Large instance with 8TB of transfer. You keep it running for 14 days (so half of a paid month) so you have 4TB in the bank, you only used 1TB on that instance so you have 3TB remaining in the bank for that month to be used by your other instances if they go over their allocation. This is on an hourly basis. We record based on the minute, but charge by the hour.
Does transfer between instances count? If not, over which interfaces must transfer take place for it to be "free"?
As per the blog post above about our network configuration, if you connect to another instance on the private network (10.x.x.x) then it won't be counted. If you connect to another of your instances over the 172.16.x.x network then that will be charged because OpenStack doesn't give us separate states per source, only for the network it comes over.
So if you launch a DB server and have it listening on 10.0.0.1 (for example), and your webserver uses that IP instead of it's public IP (or pseudo-public IP), then communication between them will not take up any of the allocation.
If you upgrade an instance during a month, does it gain credits such that it could potentially reduce or eliminate the cost of a surplus incurred earlier in the month?
As a weird quirk, the way upgrades work is that it effectively is seen from a billing point of view as one instance stopped and another of the new size started (the fact that in reality it's the same instance with the same files on disk doesn't matter, we're talking from a billing point of view). Therefore the regular situation applies, the smaller instance will contribute it's pro-rata'd per hour amount of transfer to the bank and when it's upgraded it will from that moment start contributing it's larger pro-rata transfer amount.
Greater clarity here would be helpful for planning purposes, as it could be the difference between the standard charge of $5 or a surcharge of $10 (1000 * $0.01/GB) -> $15 for an Extra Small instance using 1TB both in and out.
An XS, on its own, using 1TB in and 1TB out on the pseudo-public/public interface would be liable to an overage charge of $10.
Hope this helps make things clearer, if you have any more questions - please comment back and I'll try to answer them as best as I can.
Last edited May, 9th at 16:03