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
For those who are interested, nench and cryptsetup benchmark on that old Opteron 1385.
Network looks pretty decent and support was great during initial setup. Good deal for a cheap storage box. Thanks for sharing!
nench:
cryptsetup:
Dacentec network is good till you get nullrouted cause you went over 400 Mbps. It happened to me on those old opterons, I'm willing to bet it will happen to you.
Also, this was just with me downloading stuff to the server, I wasn't been attacked.
I want to know how the hell you managed this on one of their 138x shitboxes. Those can barely even software RAID1 without shitting themselves.
David how you got IPv6 for operton?
I just see " /30 of IPv4 Addresses " in panel...
You write to support to enable ipv6?
ZFS stripe with the 4 1 TB drives and dedupe off
Yep. As their network supports native IPv6, I just asked them friendly. Sometimes that helps.
A few minutes later they sent me my IPv6 data.
At least those CPUs should be more capable than those Kimsufi Atoms.
My intention was to create a ZFS RAIDz1 on LUKS over 6x 1 TB for cold backup storage.
I do not expect any performance wonders but I'd say >10 MiB/s should be realistic.
I am currently wiping the disks, can post some results tomorrow.
I already have enough idling servers. I wanna see those old rusty transistors burn.
They have a DDoS protection option for $10 now I believe.
And here is a short 'dd' test after setting up ZFS RAIDz1 over 6x 1 TB partitions which are encrypted with LUKS (twofish-xts-plain64). ZFS caching has been disabled to ensure data is bypassing memory. All four CPU cores are maxed out during test. Numbers are stable during multiple runs.
write (200 MB/s)
read (180 MB/s)
As expected the old CPU is the bottleneck, but I do not need to saturate >100 MB/s.
Network seems to be throttled somewhere at
~250 Mbit/s.
=> 4.2 TiB usable RAIDz1 storage plus anoher mirrored TB for OS, with 100+ MB/s local I/O and 30+ MB/s network throughput at $25. That's about 5 EUR/TiB (after redundancy) on a dedicated server.
I can't complain.
I refuse to reset my Paypal password. Repeat.I refuse to reset my Paypal password. Repeat. I refuse to reset my Paypal password.
It really is an awful shitbox that under performs most OVZ based storage nodes. Go buy @KuJoe's not-OVZ OpenVZ7.
When I had dacentec;
I'd always get nullrouted and all I was doing on the server was streaming childhood home videos via Plex.
I got tired of getting nullrouted and having to ticket support every SINGLE day.
Not worth it.
I feel most comfortable when I can use LUKS encryption and zfs send/receive over SSH to transfer incremental filesystem backups. I doubt this will work with OVZ, thus I prefer KVM or bare metal.
Let's see whether I will run into similiar issue which of course would be a show stopper. The server was ordered with 1 Gbps port and 10 TB traffic included. Optionally it was possibe to upgrade traffic or go for an unmetered 100 Mbps port. So as long as staying within monthly 10 TB traffic budget, I do not see a reason why they should nullroute customers. There is nothing mentioned about getting nullrouted when going over a certain network throughput level in their ToS either. That's a bit weird.
I may be able to shed more light on the nullrouting issue.
I had a server at Dacentec for a couple of years, and the only issue I had was getting nullrouted when using rclone to transfer files to various cloud storage providers. Apparently, the trouble was not with the bandwidth used, but with the packet rate. Dacentec has rather low tolerance for transfers that use a high packet rate, and their systems will block you for abuse if you hit their limit.
I asked their support people how I can avoid this, but they told me that it's a software issue, so they can't help. My theory is that the onboard network hardware on their older motherboards, or perhaps the corresponding drivers, may not support the use of jumbo packets. For this reason, they create what looks like a network flood when dealing with high bandwidth transfers. When I've tested similar transfers on newer hardware at other datacenters, I see just a fraction of the packet rate for the same transfer speed.
Anyway, I have no idea how to fix this, and I'm certainly not willing to play around with network drivers on otherwise stable Linux distros like CentOS 7, so I never did any further troubleshooting.
^ Yup this is similar to what happened to me except I was downloading, not uploading. I had to rate limit my download to 300 Mbps which is of course ridiculous for a 1 Gbps port, even with the lowly 10 TB max transfer per month.
Also, the hardware was quite old. I believe most disks had like 50000 hours on them. I also had issues with one of the drives in what turned out to be a faulty SATA cable. Support was top notch however, I can't fault that at all. For everything else my opinion is there's better providers our there (unless like I said before this is mostly a cold storage box in which case it should be fine).
Ah, I think I got your server.
ata4: EH in SWNCQ mode,QC:qc_active 0xFC sactive 0xFC ata4: SWNCQ:qc_active 0x4 defer_bits 0xF8 last_issue_tag 0x2 dhfis 0x4 dmafis 0x4 sdbfis 0x0 ata4: ATA_REG 0x41 ERR_REG 0x84 ata4: tag : dhfis dmafis sdbfis sactive ata4: tag 0x2: 1 1 0 1 ata4.00: exception Emask 0x1 SAct 0xfc SErr 0x400000 action 0x6 frozen ata4.00: Ata error. fis:0x21 ata4: SError: { Handshk } ata4.00: failed command: WRITE FPDMA QUEUED ata4.00: cmd 61/00:10:80:bb:6f/04:00:77:00:00/40 tag 2 ncq 524288 out res 41/84:10:80:bb:6f/84:00:77:00:00/40 Emask 0x10 (ATA bus error) ata4.00: status: { DRDY ERR } ata4.00: error: { ICRC ABRT } ata4.00: failed command: WRITE FPDMA QUEUED ata4.00: cmd 61/00:18:80:bf:6f/01:00:77:00:00/40 tag 3 ncq 131072 out res 41/84:10:80:bb:6f/84:00:77:00:00/40 Emask 0x10 (ATA bus error) ata4.00: status: { DRDY ERR } ata4.00: error: { ICRC ABRT } ata4.00: failed command: WRITE FPDMA QUEUED ata4.00: cmd 61/00:20:80:c0:6f/02:00:77:00:00/40 tag 4 ncq 262144 out res 41/84:10:80:bb:6f/84:00:77:00:00/40 Emask 0x10 (ATA bus error) ata4.00: status: { DRDY ERR } ata4.00: error: { ICRC ABRT } ata4.00: failed command: WRITE FPDMA QUEUED ata4.00: cmd 61/00:28:80:c2:6f/03:00:77:00:00/40 tag 5 ncq 393216 out res 41/84:10:80:bb:6f/84:00:77:00:00/40 Emask 0x10 (ATA bus error) ata4.00: status: { DRDY ERR } ata4.00: error: { ICRC ABRT } ata4.00: failed command: WRITE FPDMA QUEUED ata4.00: cmd 61/00:30:80:c5:6f/04:00:77:00:00/40 tag 6 ncq 524288 out res 41/84:10:80:bb:6f/84:00:77:00:00/40 Emask 0x10 (ATA bus error) ata4.00: status: { DRDY ERR } ata4.00: error: { ICRC ABRT } ata4.00: failed command: WRITE FPDMA QUEUED ata4.00: cmd 61/80:38:80:c9:6f/01:00:77:00:00/40 tag 7 ncq 196608 out res 41/84:10:80:bb:6f/84:00:77:00:00/40 Emask 0x10 (ATA bus error) ata4.00: status: { DRDY ERR } ata4.00: error: { ICRC ABRT } ata4: hard resetting link ata4: nv: skipping hardreset on occupied port ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.00: configured for UDMA/133 ata4: EH completesmartctl show disk is good.
Not my server cause they fixed it but they might have reused the cable LOL
I need to correct my network benchmark which I posted here recently and where I assumed a bandwidth limitation at about 285 Mbps.
It turned out that this limited throughput was caused by to small TCP window size in Debian defaults which couldn't max out 'long fat links'.
I now tweaked the TCP window like this:
Afterwards iperf shows up to 900 Mbps to Europe which is really great.
I have also asked their support about their null routing policy. They confirmed that they automatically place null routes when DDoS is detected. They didn't tell more details about how they define 'DDoS attack' but mentioned that null routing shouldn't occur for regular legit traffic even at 1 Gbps.
So let's see how this story will continue, however my first impression is better than expected.
my yesterday problem was solved (changed sata cable) by support yesterday for 15 mins after ticket.
If to be honest I think that at least support stuff costs more then that $25. They just great
I was null routed while restoring a backup from google drive via rclone. I had to use the bandwidth limit switch and set it to something like 900Mbps. They said I was downloading at around 1.4Gbps when the null route kicked in.
Hm, weird. How could you achieve 1.4 Gbps inbound traffic on a 1 Gbps port with L4 flow-controlled TCP traffic?! Would be interesting if some MRTG graphs existed.
That's how they trip you, null route you, annoy the client, and so they idle the server, rinse and repeat for profit. /s
Yes, you actually are on the right track here, it does have to do with these settings.
You can actually use the settings listed in this post, if you like: https://www.lowendtalk.com/discussion/25317/fixing-network-speed-in-kvm
I use a variation of this on all my virtual and dedicated servers. For Dacentec it helps a lot with the issues people have reported. The default sysctl settings in their images are not very good for their network.
Cheers!
Hm. That might work at least until a certain point and for a short time if you have some cheap outsourced supporters idling around. But remember it is a monthly contract. If you permanently annoy your clients, they will simply cancel the contract and move to another provider next month, resulting in zero profit. I don't want to take a specific position here. It just doesn't make sense to me. And yes, I know that not everything necessarily has to make sense.
^ Exactly this. I was fine with the performance of the box overall for what I was using it for but getting null routed like 3 times within 2 days and then having to artificially limit my throughput just rubbed me the wrong way. Blessing in disguise though, I got a much better deal elsewhere.
Dacetec request any KYC?
Not possible to edit previous message, but some other (maybe stupid) questions.
1) /30 IPv4 is it 4 ip? And what does it mean on this page https://billing.dacentec.com/hostbill/index.php?/cart/extras/ "Only 1 usable"? How it's possible that they give range of ips, but you can use only one?
2) "Rent-to-own" how exactly it works? Please, explain or where can I read about this/
network gateway broadcast etc
if you are suspicious yes
After 12 months you can switch to colocation pricing and for a small fee they can unrack, box, and ship you the server (you provide the shipping label and coordinate pickup of the server).
Switch to colo as option or is possible to continue with the service?
How much colo?
Not exactly understand this, but why they wrote /30 if it's really 1 ip available at server?
And other question:
Dacetec servers come with KVM? It's it possible to manage it at boot process?
Thanks.
Seems colo month cost is much more then dedi server cost