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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
How do we know it's Heather? It could be Nugget's sister!
There is no proof this is coming from Heather! No proof == SCAM!
Who's Heather, by the way?
Been using DigitalOcean's NYC1 datacenter for about a year, never had any IPv6 issues (I monitor it every 5 minutes).
They're referring to the fact that we don't assign a /64, which in turn also means that we need to block SMTP (because IPv6 RBLs list /64s at once, you can't trace some spam complaints). It's a fair complaint.
We adopted IPv6 earlier than most, and quite frankly weren't convinced that the "every device should have a /64" thing would actually stick in implementation. We all know that accepted standard and accepted implementation are not always the same thing. Well it became an accepted implementation to enough degree that universally blocking SMTP on it makes sense, since we're not following that standard right now.
I don't know when that changes or what it looks like, but I feel confident in saying that it has to at some point. Fortunately we haven't run out of IPv4, there is no such thing as an actual mail service that uses IPv6 only, and by all of my tests Google leans more toward email being spam when coming from IPv6, so at least there's that. So at least in the meantime, valid workarounds do exist.
That last bit there was actually a slight amount of trolling because I can't help myself. You might see how, if it lands :P
Been using servers from many providers for years and never bothered with IPv6, and never had any issues.
FYI to those with existing DigitalOcean virtual servers (Droplets).
They say "resizing" an existing virtual server will automatically convert existing Droplets into the new (better) pricing. I'll try it later tonight.
yes, this owrked perfectly for me
Gotto shut them down to do this though.
The performance is usually much better than that for I/O and network. Not sure what's going on. Maybe everyone is benchmarking today. :P
Can I get that account credit as an existing customer :P
@Jarland assisted with my ticket and he moved me to a new node. ^_^
New result: Disk Read 1368 MB/s Disk Write 852 MB/s Bandwidth 1158.75 Mbit/s Speedtest 98.55 Mbit/s
Yeah I'm still trying to get to the bottom of that one. There was an obvious problem at first glance but I'm not 100% convinced it was the complete underlying cause.
No issues resizing my virtual servers. Doing this doubled their RAM and added more disk space at the same prices.
Steps taken were: 1) fully backing up the Droplets, 2) shutting them down, 3) doing the "resize", and 4) powering back up.
Just so that I understand correctly, do you mean that Google is more likely to mark an email as spam if the sending server has an IPv6 address than if the sending server does not have an IPv6 address, other things being equal? (Assume that an PTR record is set for the IPv6 address in question.)
In my tests, if the IPv6 address is the IP connecting to their server to make the transaction, this has been the case. There is a solid gap of time between my tests and now, for what it's worth
(Yes, I meant that the IPv6 address would the IP connecting to Google's server.)
It's possible, but unfortunately, it's hard to find a statement about this from Google themselves.
guys and guygirls. google has always have problems with ipv6 from massive abuse due to the size of ipv6 space. without a valid ptr you can't even send mail so with a valid ptr; i'm sure their filtering is a bit more strict.
Insofar as Google really is stricter with an IPv6 address than with an IPv4 address, it may be because the notion "IP reputation" is less applicable in practice to IPv6 than it is to IPv4.
I think my point is there's no need to do tests for this unless you are developer that wants to waste your time and want important mail entering spam folders. Unless ipv6 is fully adopted which could take decades since even residental residences in the us is only ipv4 capable... Any speculation is really just a waste of your time but entertaining to read.
If you look up a few posts, I was just reacting to a comment that @jarland made. I hadn't reflected on this until his comment.
In any case, I haven't experienced a problem of this kind.
Me either but who knows. I'm incline to remain routing email via ipv4 only to gmail but filtering will always been "secret" so you never know when ipv6 will be affected if not periodically for short periods of time.
None of the major email providers publish the logic for their spam filters
Okay, I guess that I should stop looking. :-)
Anyone know if the IP changes on a resize or rebuild?
Six, unless twelve.
Is there news on block storage at NL location?
@jarland I have a question for a certain workload I'm planning on doing on digitalocean.
So, I'm thinking of doing a simple test batch processing workload that includes downloading 100-150gb of data with kafka.
Now that you guys have the flexible plans, I'm really thinking of using the 1gb 3vcpu plan since they have more storage and a little bit more cpus(although shared).
The price for the 3 droplets of the dedicated 4gb 2vCPU vs 8 droplets 1gb 3vcpu is the same. However, one question still remains, how are the vcpus being throttled on DigitalOcean? Would my droplet get suspended if I use over the limit, or do you guys just throttle my droplet so I don't have to worry about my droplets going down?
This matters, because from the looks of it, I get basically 6 dedicated cpus vs 24 shared cpus.
Oh by the way, do you know when DigitalOcean will finally bring in true private networking. This would be a freaking killer feature. And one last question, the second billing that you guys have on the roadmap. What would be the minimum minutes/seconds billed, or would it be literally per second billing even if it's one second?
No IP change unless you destroy the droplet and create a new one.
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:
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
I would have thought optimized droplets had dedicated or almost-dedicated cores, like OVH public cloud supposedly does. But I haven't compared instance specs and prices between them yet.
Regarding shared CPU usage: I'd always heard that nobody gets cut off, but on shared servers, persistent high-cpu droplets and maybe persistent users get throttled after a while. I'd like to think that with millions of droplets the entire process is automated rather than relying on human intervention. But I can understand DO wanting to keep quiet about the specifics, to make it harder to game.
I wasn't thinking about the optimised droplets when I wrote that, so I added what I should have as a tiny edit at the bottom of a book lol. The rest was totally valid for the other droplets though so I liked having written it out.
Automation is ideal at scale @willie you're right, but also right in that if you publish hard numbers you task yourself with providing those numbers. Those numbers are either mathematically sustainable if all hit them at once, meaning you decrease provisioned CPU or stop selling shared CPU, or you've committed on paper to providing something (by policy) that is mathematically unsustainable in a theoretical scenario (that never occurs), and you've just told everyone specifically how to create a problem.
Better in reality, and in my opinion, to have monitoring alerts and human review.
Nobody is willing to tell you specifically what that do, even under an NDA, because then it'd be a bit easier for nefarious fuckers to circumvent it. It's also hardly likely to only use different variables for the beancounter data/vCPU/et al. If it isn't due to that, then they're afraid you might lift whatever they spent X amount of time on, and gives them a slight advantage over JoeShmoesWHMCSOVZ SummerPavillion.