scaw

Sorry to double post; I was able to get things working using the container at https://hub.docker.com/r/azinchen/nordvpn. I just set up a new container in docker and added the required keys, and it's chugging along nicely (using openvpn). Hopefully the bubuntux container gets fixed soon and I can go back to the much faster NordLynx!

FWIW my logs look identical to @MrCTS. I haven't seen the "account subscription expired" message though. I also tried resetting my password as suggested in the thread at https://github.com/bubuntux/nordvpn/issues/227 but no dice. After the logs posted above happen, a bunch of stuff gets spit out at once and the docker instance closes; the most relevant seeming part of that dump seems to be 2021/09/06 16:33:18 Get "https://os4work.com/v1/users/services": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) 2021/09/06 16:33:18 [Error] listing services: rotating domain: ptr timer is locked

I got this all set up 3 days ago, including changing the subnet. It was all working until last night it suddenly stopped with nothing able to fix it. Turning the docker on leads to a long wait where it tries to talk to NordVPN and ends with the message "Unable to connect." in the logs before closing the docker instance. I've tried changing the country, switching from NordLynx to OpenVPN, and totally reinstalling the docker, but nothing is working. I have no clue why it set up just fine originally and then suddenly crashed hard. It seems like a lot of people are having trouble connecting. Did anyone manage to figure out a solution to this?

Yeah, I'm aware of that which is why I did most of my testing with sequences of 2-4 GB files to minimize that issue. Right, I understand that much, so does that mean that 5 MB/s is just what can be expected from a dual parity setup? That seems too slow based on the other things I've read.

Hi all, I hate to make a post about write speeds because I know there have been a million of them, but I can't figure out why my performance is so bad/inconsistent. I'm running a Dell R710 with a H200, unRAID version 6.3.5. Full specs are My problem is that since I set up the entire array (6x8tb WD Reds, 4 data 2 parity) my write speeds have been bad and inconsistent. I get between 6 and 12 MB/s writes most of the time, sometimes going up to 40 or 50 for a few seconds and then back down. I don't have a cache drive right now and I assume that parity is slowing this down, but from all I've read it shouldn't be this slow! I would be happy with a consistent 25-35 MB/s, which seems like a reasonable expectation based on what I've read. All six drives check out and precleared beautifully with speeds between 150 MB/s and 190 MB/s with no errors, so I don't think it's a bad drive. I'm hard wired via a gigabit ethernet switch. I've done iperf tests to the server, and I get full gigabit speeds, so I don't think it's the network either. Here's a screenshot of a transfer with some dynamix stats up if it helps. I'm not running a lot of stuff yet -- binhex's deluge docker and a plex server which was siting idle during the transfers. I've run Fix Common Problems and there's no warnings or errors. I've read the tips and tricks page too, and the page on performance. Please let me know if I'm missing something, or if I should upload logs. The one thing I haven't done yet is enable turbo write, but I would rather not have my drives spinning 24/7 if I can avoid it so I'd like to first see if there's anything I can do. Edit: Well, I tried enabling turbo write and the difference is staggering. For one thing, my RAM seems to flush its cache far more regularly now, which helps with the writes. Additionally, the disk write speed reported on dynamix (the bottom right) is around 300-400 MB/s (I'm assuming that's ~130 each on the data drive and the two parity drives. And the real difference -- I just copied 30 GB in about 5 minutes, with an average transfer speed (as given by Windows) of between 80 and 110 MB/s (the latter of which saturated my gigabit network). So the questions are now: a) What is it about turbo write that causes the RAM cache to behave so differently, and can I replicate it without turbo write? I assumed that if I had extra RAM floating around, unRAID would use it as a cache which would alleviate the need for a cache drive since I have plenty of extra RAM, but until I enabled turbo write the behavior was instead System boots --> First few transfers are fairly fast --> RAM fills w/ cache --> RAM never empties more than a couple gigabytes of cache over several hours and everything slows to a crawl. b) Does this prove that my slow transfers before were due to parity issues in some way? I don't 100% understand how turbo write works, but I just saw a 2000% increase in my write speeds and I'm baffled. Again, I'd take half the performance most of the time if I didn't have to leave turbo write always enabled, but if it's 5 MB/s or 100, I'd have to keep the latter, drive wear be damned. Any insight would be appreciated...