Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Digitalocean New Plan Pricing - Page 5
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Digitalocean New Plan Pricing

123578

Comments

  • @jarland said:

    sarah said: Anyone know if the IP changes on a resize or rebuild?

    No IP change unless you destroy the droplet and create a new one.

    IAlwaysBeCoding said: However, one question still remains, how are the vcpus being throttled on DigitalOcean?

    This is actually a question in which my answer may be accused of continually frustrating a small number of people. The reason being that I intentionally won't give a straight answer to it, and I honestly believe that to be the right call. I am firmly of the opinion that excessively defining the limits of shared CPU cores creates problems for many, and only solves a burning question for a select few.

    When answering this question, I believe that a provider has three options:

    1. Never sell shared resources, halt doing so when the question is asked because there can be no answer that does not instantly reduce the quality of service for everyone.
    2. Limit people strictly according to perfect math of the division of resources. So if you sell 4 people 1 CPU core, cut anyone off the moment they exceed 0.25. In doing so, create a limit that never would have had to be defined before, because no one using 0.5 has ever caused a problem (theoretical, but closer to reality than you'd think).
    3. Intelligent administration. Balance based on statistical probabilities of usage, learned over time from a large data source (like deploying millions of servers over years), tell people not to be a jerk with shared resources, and the chances of any issue arising so incredibly small that they're not of statistical value.

    I prefer #3 because it uses the human element. We're human, you're human, you know that "be respectful to your neighbors" is loaded with nearly infinite possibilities that cannot all be listed, it's a philosophy that translates into a filter for your actions. So when you want to excessively loud music at 2AM you ask yourself "Is this respectful to my neighbors?" You know it's not. But when you want to take a shower at 3AM and you ask yourself "Is this respectful to my neighbors?" then it might be perfectly reasonable to conclude "If it is, we've all made a poor choice in where to live, because it's unreasonable to ask that I not do this if this is what I need to fit my schedule."

    In that way you begin to see it flesh itself out as a filter, not a list of rules. I can't tell you what is reasonable for shared CPU usage because it's based on the unpredictable actions of other humans. It might actually be totally okay (as in off the radar, no one cares) for you to mine cryptocoin on one server for a year without issue, and then one of your neighbors decides to do the same and suddenly it's a crisis and you're both shut down because you collectively caused a problem for a greater number of people. Realistically, maxing out that shared CPU for a year was a jerk move, you knew it was shared, but it's not a problem until it causes a problem, and that is relative.

    On the other side of it, if 15 customers cause a server crisis because they got a spike in web traffic, shutting down those 15 customers is not logical. It means the admin has failed to balance the server. That's when you should theoretically learn from the issue, adjust provisioning logic to compensate where reasonable, and re-balance. You can reasonably assume the 15 customers who just had a CPU spike and haven't been maxing out the CPU to 100% for a year are not equivalent to people who have been maxing out a CPU for a year, you don't have to actually know the in depth details to determine the likely difference of intent there.

    So in this my answer generally boils down to: If you have to ask where to draw the line with shared CPU, you need to be using dedicated.

    Edit: I just realized none of this relates to the "optimized droplets" and my apologies, it's been a rough day. My brain is just a tad slow. For those, do what you need to do. Have fun. If there's a problem, we'll let you know :)

    Well, I don't plan on doing cpu mining at all. In fact, I plan on launching a few droplets as a test for no more than say 3-4 hours , ingest data and process it, then push it to Spaces or on the Block storage.

    If I were to use 8 x 1gb 3vcpu flexible droplets instead of the cpu optimized droplets for a few hours, would my stuff get shut down. But based from your reply, you are more worry about people burning the cpu 24/7 for a whole year or months, instead of the people using the droplets for temporary batch processing workload that won't take more than a few hours.

  • jarjar Patron Provider, Top Host, Veteran
    edited January 2018

    My honest feeling here is that you would be perfectly fine with any droplet in that case. If reality proves differently, let me know and I'll make it up to you, we'll both learn from it, and I'll adjust how myself and my team answer that question moving forward as a result :)

    Thanked by 1IAlwaysBeCoding
  • My philosophy on this sort of stuff is that if you are doing things that require specific CPU constraints and resources you'll know about it and should choose a service which offers you those. If you aren't then generally you aren't that special and don't have to worry about it.

    Thanked by 2WSS jar
  • WSSWSS Member

    Most providers are quite accomidating for the occasional IOPS/CPU burnage, if you're not doing it for more than a specified amount of time.

    Even @VirMach has loosened up on this. When I first beat my VPS by doing an apt-get dist-upgrade, I got a nastygram. They're much more accomidating, but if you do more than an occasional use, everyone is going to tell you to get your own box, unless you're @willie.

  • SplitIceSplitIce Member, Host Rep

    I've never had any complaints from them about my Elasticsearch cluster... and that's 16 $5 data nodes that peak up to 100% IOPS and CPU at the exact same time (for minutes).

    I'd say go for it.

    Thanked by 1vimalware
  • jarjar Patron Provider, Top Host, Veteran

    @SplitIce said:
    I've never had any complaints from them about my Elasticsearch cluster... and that's 16 $5 data nodes that peak up to 100% IOPS and CPU at the exact same time (for minutes).

    I'd say go for it.

    Hold my beer.

    Just kidding.

  • WSS said: everyone is going to tell you to get your own box, unless you're @willie.

    Nah, I also suggest getting your own box (or one with no-fooling dedicated resources). Once you do that though (contra @WSS), you are allowed to use it as if you owned it.

  • WSSWSS Member

    @willie said:
    you are allowed to use it as if you owned it.

    You seemed to have a different stance when I took your daughter out for prom.

  • WSS said: You seemed to have a different stance when I took your daughter out for prom.

    You only paid for the shared hosting plan, not the dedi.

    Thanked by 1szarka
  • jarjar Patron Provider, Top Host, Veteran

    @willie said:

    WSS said: You seemed to have a different stance when I took your daughter out for prom.

    You only paid for the shared hosting plan, not the dedi.

    I think the question on everyone's mind is: how much for the dedi?

  • WSSWSS Member

    @jarland said:

    @willie said:

    WSS said: You seemed to have a different stance when I took your daughter out for prom.

    You only paid for the shared hosting plan, not the dedi.

    I think the question on everyone's mind is: how much for the dedi?

    From what I recall, something like commitment is 600 months+. Anything less, and there are penalties.

  • jarjar Patron Provider, Top Host, Veteran

    @WSS said:

    @jarland said:

    @willie said:

    WSS said: You seemed to have a different stance when I took your daughter out for prom.

    You only paid for the shared hosting plan, not the dedi.

    I think the question on everyone's mind is: how much for the dedi?

    From what I recall, something like commitment is 600 months+. Anything less, and there are penalties.

    Too rich for my blood, I fold.

  • WSSWSS Member

    @jarland said:
    Too rich for my blood, I fold.

    ..not to mention she's got a big problem with accepting patches for Meltdown. :(

    Thanked by 1IAlwaysBeCoding
  • jarjar Patron Provider, Top Host, Veteran

    @WSS said:

    @jarland said:
    Too rich for my blood, I fold.

    ..not to mention she's got a big problem with accepting patches for Meltdown. :(

    If he actually has a daughter these jokes are suddenly mean and uncalled for.

    Sincerely,.
    Over protective father

    Thanked by 2Lee WSS
  • WSSWSS Member
    edited January 2018

    @jarland said:

    @WSS said:

    @jarland said:
    Too rich for my blood, I fold.

    ..not to mention she's got a big problem with accepting patches for Meltdown. :(

    If he actually has a daughter these jokes are suddenly mean and uncalled for.

    Sincerely,.
    Over protective father

    I honestly have no idea; I figured the 50 year commitment was enough to cover bases in the event of being slightly-applicable.

    Besides, since he houses the LET $7 Pentabyte gay porn server, why'd he have one? ;)

  • SplitIceSplitIce Member, Host Rep
    edited January 2018

    Hello,

    Following the launch of our new pricing plans, we have seen a significant uptick of usage in our AMS2 region and we have currently reached maximum capacity at the datacenter. As a result, we have disabled new Droplet creation in the region.

    Though we are making efforts to free up space on our servers, we are unable to add more capacity as we remain restricted by the size of the facility. We anticipate that some users will destroy their AMS2 Droplets, freeing up space in the region, but we are unable to predict how much space that will create, and how quickly that might happen. We encourage you to consider migrating your data to our AMS3 region - which houses newer hardware and more features, like Block Storage - or to one of our other nearby regions like LON1 or FRA1.

    For more information about migrating your Droplets to a new region, you can refer to this tutorial on our Community site.

    Thank you,
    Team DigitalOcean

    Just when I was starting to do some resizes. <_<

  • jarjar Patron Provider, Top Host, Veteran
    edited January 2018

    SplitIce said: Just when I was starting to do some resizes.

    Oh good, I was about to ask if that went out today. We really should have sent it earlier (like anticipating the event rather than reacting to it), something to do better and learn from.

  • XeiXei Member

    Is there any network performance difference between AMS2 and AMS3? Both would route/peer similarly wouldn't they?

  • SplitIceSplitIce Member, Host Rep
    edited January 2018

    @Xei My testing earlier last year showed them to be basically the same.

    I don't see why you would go AMS2 unless you are already deployed there (as is the case with us, and many others).

    I'm actually surprised there has been no attempt at bridging, migrating or otherwise merging the datacenters (as occurred with AMS1).

    Thanked by 1Xei
  • WSSWSS Member

    @SplitIce said:
    I'm actually surprised there has been no attempt at bridging, migrating or otherwise merging the datacenters (as occurred with AMS1).

    ..have you ever tried to get @jarland on a plane with only those wimpy little shot-sized bottles at $5/pop? They'd be broke before it even left DFW!

    Thanked by 1SplitIce
  • jarjar Patron Provider, Top Host, Veteran

    SplitIce said: I'm actually surprised there has been no attempt at bridging, migrating or otherwise merging the datacenters

    I'm not sure what the future holds, but I wouldn't rule anything out.

  • jon617jon617 Veteran
    edited January 2018

    sarah said: Anyone know if the IP changes on a resize or rebuild?

    I also confirm no IP changes occurred when I resized 3 Droplets to the new pricing (IPv4 & IPv6). Everything on the servers came back fine after reboot, just with more RAM and disk available to the OS. I'm using CentOS 6 and 7, though I would bet all other modern Linux OSs will also handle the resize.

  • XeiXei Member

    @SplitIce said:
    @Xei My testing earlier last year showed them to be basically the same.

    I don't see why you would go AMS2 unless you are already deployed there (as is the case with us, and many others).

    I'm actually surprised there has been no attempt at bridging, migrating or otherwise merging the datacenters (as occurred with AMS1).

    Thanks. What would be the purpose or benefit in bridging, migrating and merging? Just noticed AMS3 has block will check it out.

  • SplitIceSplitIce Member, Host Rep

    @xei So that those in AMS2 can move without IP renumbering :)

  • Hey @Jarland, do you know when are you guys going to have proper billing for your droplets. I really don't like the fact that launching a $5 droplet is not .007 but always .01 for 1 hour. You guys round everything to the nearest cent on every individual launch instead of the final bill.

    It makes it counter productive launching 10-100 small $5 droplets for 1 hour since it will be 30% more expensive than what 42% more expensive than what is listed there.

    Thanked by 1Xei
  • I'd expect since they plan on doing per second billing making it more granular would be part of that.

    Thanked by 1Aidan
  • jarjar Patron Provider, Top Host, Veteran
    edited January 2018

    @IAlwaysBeCoding said:
    Hey @Jarland, do you know when are you guys going to have proper billing for your droplets. I really don't like the fact that launching a $5 droplet is not .007 but always .01 for 1 hour. You guys round everything to the nearest cent on every individual launch instead of the final bill.

    It makes it counter productive launching 10-100 small $5 droplets for 1 hour since it will be 30% more expensive than what 42% more expensive than what is listed there.

    You can't actually charge fractions of a cent though so that's kind of the thought process there as I understand it. It's either rounded to that or every droplet is free for X hours (with how we currently calculate), which kind of adds a new abuse angle or the removal of further function on accounts for abuse prevention. I get the annoyance though, I would like to see a better balance to this as well.

    I can tell you that billing improvements are on the table, and I do not currently know just what all that means. For what that's worth :)

  • I think per minute billing is more rational.

  • @budi1413 said:
    I think per minute billing is more rational.

    Their most expensive plan is 960 usd/month, or 2.2 cents per minute. I pressume they want to get to something like "per cent billing" instead of "per second billing". That would mean that the most expensive plan would be billed a cent every 27 seconds, excluding tax. Less if tax is included.

    Cheapest (5 usd/month) plan would be billed a cent every 5184 seconds, or just over 86 minutes.

    That's at least how I'd set up something like this (per-cent billing instead of per-second), to avoid billing fractions of cents.

    Thanked by 2Shazan uptime
  • jarland said: You can't actually charge fractions of a cent though so that's kind of the thought process there as I understand it. It's either rounded to that or every droplet is free for X hours (with how we currently calculate), which kind of adds a new abuse angle or the removal of further function on accounts for abuse prevention. I get the annoyance though, I would like to see a better balance to this as well.

    maybe tally the differences for end of month billing adjustments ?

    so if person uses droplet for 1hr per day for 30 days

    • expected billing = 30x 0.007 = 0.21
    • actual billing = 30x 0.01 = 0.30
    • end of month adjustment difference = 0.21 - 0.30 = -0.09
    Thanked by 1Xei
Sign In or Register to comment.