Howdy, Stranger!

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


KVM VPS | 8 Locations | From £16 Per Year | DDOS Protected. - 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.

KVM VPS | 8 Locations | From £16 Per Year | DDOS Protected.

1235718

Comments

  • @Neoon said:
    Sadly, the FIN box seems to have a overloaded uplink, which makes it not really usable with smokeping. Even over hours.

    I get to many false reports the recent days, so another 25EUR burned, sad.

    Finland is far from overloaded, I'b be quite happy to admit if it was. We have 19IPs with the opportunity of having 30 max.
    You could have reached out to us to troubleshoot your issue together rather than immediately assuming your 25EUR is down the drain.
    False report for days? I am pretty sure the plan was just purchased this morning.

    In any case, do send us a ticket or come to live chat and we'd be happy to look into this with you.

    Thanked by 1dahartigan
  • NeoonNeoon Community Contributor, Veteran

    @HostDoc said:
    Finland is far from overloaded, I'b be quite happy to admit if it was. We have 19IPs with the opportunity of having 30 max.

    Well, the Smokeping lighted up like a christmas tree on the FIN node.
    From Russia, Ukraine, Austria, Canada, France everything detected Packetloss.
    Including ping increase, which is a typical pattern if a uplink is overloaded.

    Other external smokeping instances, confirmed the packetloss just in FIN, and that over hours, multiple times.

    You could have reached out to us to troubleshoot your issue together rather than immediately assuming your 25EUR is down the drain.

    I can post my experience, when I desire it.
    Not again, that "open a ticket muzzle", if needed, I open a ticket.

    Just to let people know, that the network on the FIN node is wavering.
    Which is not optimal for low latency applications.

    False report for days? I am pretty sure the plan was just purchased this morning.

    No, it was purchased earlier.

  • @Neoon said:

    @HostDoc said:
    Finland is far from overloaded, I'b be quite happy to admit if it was. We have 19IPs with the opportunity of having 30 max.

    Well, the Smokeping lighted up like a christmas tree on the FIN node.
    From Russia, Ukraine, Austria, Canada, France everything detected Packetloss.
    Including ping increase, which is a typical pattern if a uplink is overloaded.

    Other external smokeping instances, confirmed the packetloss just in FIN, and that over hours, multiple times.

    You could have reached out to us to troubleshoot your issue together rather than immediately assuming your 25EUR is down the drain.

    I can post my experience, when I desire it.
    Not again, that "open a ticket muzzle", if needed, I open a ticket.

    Just to let people know, that the network on the FIN node is wavering.
    Which is not optimal for low latency applications.

    False report for days? I am pretty sure the plan was just purchased this morning.

    No, it was purchased earlier.

    This seems more like an angry complaint with no intent to try and possibly look into your issue.
    I did not mention anything about your comment here or that it should only be in a ticket. I simply stated you could have reached out to us rather than assuming you have lost money. It is seeming you would rather lose it and have something to complain about than trying to address the issue, if there is one.
    Yes, it was purchased earlier today.

    In any case, I decided to run some speedtest and pings for you until you want to contact us to try and troubleshoot or you want to paste your results here and we can work through them together. Right here.

    @helsinki ~]# ping google.com
    PING google.com (216.58.212.238) 56(84) bytes of data.
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=1 ttl=49 time=44.1 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=2 ttl=49 time=44.1 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=3 ttl=49 time=43.1 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=4 ttl=49 time=43.1 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=5 ttl=49 time=43.1 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=6 ttl=49 time=43.1 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=7 ttl=49 time=48.5 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=8 ttl=49 time=49.5 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=9 ttl=49 time=44.1 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=10 ttl=49 time=47.7 ms
    64 bytes from ams16s22-in-f238.1e100.net (216.58.212.238): icmp_seq=11 ttl=49 time=50.2 ms
    ^C
    --- google.com ping statistics ---
    11 packets transmitted, 11 received, 0% packet loss, time 10011ms
    rtt min/avg/max/mdev = 43.119/45.561/50.281/2.733 ms
    @helsinki ~]# ping clientsarea.hostdoc.co.uk
    PING clientsarea.hostdoc.co.uk (107.155.79.82) 56(84) bytes of data.
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=1 ttl=50 time=150 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=2 ttl=50 time=154 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=3 ttl=50 time=148 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=4 ttl=50 time=154 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=5 ttl=50 time=151 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=6 ttl=50 time=146 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=7 ttl=50 time=145 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=8 ttl=50 time=146 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=9 ttl=50 time=141 ms
    ^C64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=10 ttl=50 time=141 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=11 ttl=50 time=143 ms
    64 bytes from clientsarea.hostdoc.co.uk (107.155.79.82): icmp_seq=12 ttl=50 time=141 ms
    ^C
    --- clientsarea.hostdoc.co.uk ping statistics ---
    12 packets transmitted, 12 received, 0% packet loss, time 10998ms
    rtt min/avg/max/mdev = 141.339/147.210/154.885/4.806 ms
    @helsinki ~]# ping au-cp.hostdoc.co.uk
    PING au-cp.hostdoc.co.uk (139.99.131.44) 56(84) bytes of data.
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=1 ttl=46 time=422 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=2 ttl=46 time=419 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=3 ttl=46 time=417 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=4 ttl=46 time=409 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=5 ttl=46 time=409 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=6 ttl=46 time=413 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=7 ttl=46 time=412 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=8 ttl=46 time=409 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=9 ttl=46 time=409 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=10 ttl=46 time=409 ms
    64 bytes from au-cp.hostdoc.co.uk (139.99.131.44): icmp_seq=11 ttl=46 time=409 ms
    ^C
    --- au-cp.hostdoc.co.uk ping statistics ---
    11 packets transmitted, 11 received, 0% packet loss, time 10008ms
    rtt min/avg/max/mdev = 409.465/412.956/422.135/4.435 ms
    @helsinki ~]# ./speedtest-cli
    Retrieving speedtest.net configuration...
    Testing from Hetzner Online GmbH (95.216.7.91)...
    Retrieving speedtest.net server list...
    Selecting best server based on ping...
    Hosted by Nebula Oy (Helsinki) [0.00 km]: 2.251 ms
    Testing download speed................................................................................
    Download: 869.37 Mbit/s
    Testing upload speed................................................................................................
    Upload: 403.04 Mbit/s

    @helsinki ~]# ping smokeping.org
    PING smokeping.org (46.140.183.210) 56(84) bytes of data.
    64 bytes from 46-140-183-210.static.cablecom.ch (46.140.183.210): icmp_seq=1 ttl=243 time=39.4 ms
    64 bytes from 46-140-183-210.static.cablecom.ch (46.140.183.210): icmp_seq=2 ttl=243 time=39.2 ms
    64 bytes from 46-140-183-210.static.cablecom.ch (46.140.183.210): icmp_seq=3 ttl=243 time=39.2 ms
    64 bytes from 46-140-183-210.static.cablecom.ch (46.140.183.210): icmp_seq=4 ttl=243 time=39.0 ms
    64 bytes from 46-140-183-210.static.cablecom.ch (46.140.183.210): icmp_seq=5 ttl=243 time=39.3 ms
    64 bytes from 46-140-183-210.static.cablecom.ch (46.140.183.210): icmp_seq=6 ttl=243 time=39.3 ms
    64 bytes from 46-140-183-210.static.cablecom.ch (46.140.183.210): icmp_seq=7 ttl=243 time=39.3 ms
    ^C
    --- smokeping.org ping statistics ---
    7 packets transmitted, 7 received, 0% packet loss, time 6006ms
    rtt min/avg/max/mdev = 39.048/39.275/39.407/0.238 ms

    Thanked by 1dahartigan
  • There's always one in every crowd lol

  • NeoonNeoon Community Contributor, Veteran

    @HostDoc said:
    This seems more like an angry complaint with no intent to try and possibly look into your issue.

    No, from my perspective, you seem not to care or/and not monitoring your nodes properly. Not the first provider who was unable to detect packetloss, until I told him to for example to setup several smokeping instances.

    That was a bit Aggressive.

    I did not mention anything about your comment here or that it should only be in a ticket. I simply stated you could have reached out to us rather than assuming you have lost money. It is seeming you would rather lose it and have something to complain about than trying to address the issue, if there is one.
    Yes, it was purchased earlier today.

    You do have a non refund policy, ergo, my money is gone, if for example the network is unstable at certain times for the desired use case.

    There is no bandwidth or latency guarantee anywhere in the offer, so chances are low, for success.

    In any case, I decided to run some speedtest and pings for you until you want to contact us to try and troubleshoot or you want to paste your results here and we can work through them together. Right here.

    Well, the packetloss is gone for now, so nothing on your results either.
    Setup a few smokeping instances, and you see the same stuff, I see, easy.

    Thanked by 1amsaal
  • @Neoon said:

    @HostDoc said:
    This seems more like an angry complaint with no intent to try and possibly look into your issue.

    No, from my perspective, you seem not to care or/and not monitoring your nodes properly. Not the first provider who was unable to detect packetloss, until I told him to for example to setup several smokeping instances.

    That was a bit Aggressive.

    I did not mention anything about your comment here or that it should only be in a ticket. I simply stated you could have reached out to us rather than assuming you have lost money. It is seeming you would rather lose it and have something to complain about than trying to address the issue, if there is one.
    Yes, it was purchased earlier today.

    You do have a non refund policy, ergo, my money is gone, if for example the network is unstable at certain times for the desired use case.

    There is no bandwidth or latency guarantee anywhere in the offer, so chances are low, for success.

    In any case, I decided to run some speedtest and pings for you until you want to contact us to try and troubleshoot or you want to paste your results here and we can work through them together. Right here.

    Well, the packetloss is gone for now, so nothing on your results either.
    Setup a few smokeping instances, and you see the same stuff, I see, easy.

    Yes, no refund policy does not mean we do not want satisfied clients.
    If you are not happy for whatever reason, even if you went outside and wet your toes and it annoyed you so much you decided to blame HostDoc, we would do what we can to make you happy again.
    That includes the option of being moved to another node in another location or requesting a refund to your account to be used towards a future payment as mentioned earlier in this very thread. We do not lock you to a machine that is useless for your use case.
    Like I said, you could have reached out rather than assuming it is lost.

    Once again, this seems like an excuse to complain and to make a meal out of from what has been presented so far, nothing.

    Thanked by 2dahartigan banxix
  • hey @HostDoc if you don't know @Neoon then this is his style. Its late and I think you two go sleep it over and solve it over tickets tomorrow.

    I just finished nftables-docker-rancher between two nodes and its 02:09 here in Finland and time to sleep....

    9'th all.

    Thanked by 3dahartigan HostDoc eol
  • @ehab said:
    hey @HostDoc if you don't know @Neoon then this is his style. Its late and I think you two go sleep it over and solve it over tickets tomorrow.

  • iHavenoNameiHavenoName Member
    edited February 2019

    edit order finally went through.

    Thanked by 1HostDoc
  • uptimeuptime Member
    edited February 2019

    @HostDoc beware the "incero effect" - it's great to take care of business on the technical side, but a (studied and sympathetic) diplomatic response can go a long way when handling criticism in public.

    Especially in a troll-rich environment such as LET.

    (To be clear I don't think @Neoon is trolling. If you can work with him in a less confrontational / defensive way - even though "he started it" - it could help find and fix the tricky details that make for a superior service. I'm usually reluctant to spend much effort to open tickets for network quirks beyond perhaps an occasional "fyi, and by the way here's an MTR" if I really care - it's a bit of a chore when I can just move on to use another provider who has already somehow managed to take their network to a level that doesn't depend on my own dilligence to fix.)

    That said I'm certainly no fan of the canned and glib (and seemingly endless) "very sorry you've had a problem" response mill that some LEB-type hosts seem to specialize in.

    Let us consult @cociu and his sisters for best advice on bedside manner most suitable for making sales and keeping customers happy on LET.

    EDIT2:

    fartmother walks on thin eggs.

  • How many caffeine pills do you need to add stocks for the 600 Cores, 20MB ram, 500 IPv4, 90TB HDD for total £5/y?
    I'm willing to send you some caffeine pills.

  • @Chuck said:
    How many caffeine pills do you need to add stocks for the 600 Cores, 20MB ram, 500 IPv4, 90TB HDD for total £5/y?
    I'm willing to send you some caffeine pills.

    I think you're going to need something significantly more potent than caffeine for that lol

    Thanked by 1eol
  • Doc's been freebasing no-doz for a hot minute already is my best guess.

    Thanked by 2dahartigan eol
  • does anyone recall how much transfer the 4core, 4GB Germany VPS came with?

  • @cybertech said:
    does anyone recall how much transfer the 4core, 4GB Germany VPS came with?

    Unlimited :)

    Thanked by 3cybertech eol HostDoc
  • @dahartigan said:

    @cybertech said:
    does anyone recall how much transfer the 4core, 4GB Germany VPS came with?

    Unlimited :)

    thanks mate :)

  • @cybertech said:

    @dahartigan said:

    @cybertech said:
    does anyone recall how much transfer the 4core, 4GB Germany VPS came with?

    Unlimited :)

    thanks mate :)

    No worries mate :) I just checked over the "follow that page" email, it's a pretty cool service for things like this

    Thanked by 1Chuck
  • dahartigandahartigan Member
    edited February 2019

    @AlwaysSkint said:
    Reducing swappiness can lead to better performance - less I/O. I usually set 1 or 5, depending on my mood/weather/moon cycle/HostDoc crazy Flash deals. For SSD in particular, you do want it low, from a drive wear perspective, if nothing else.

    Oh no! It's swap shop again! :-o

    I just reduced my swappiness to 1 and then swapoff -a && swapon -a and now I'm using 0 swap and it's all in RAM now. Thanks to you and @teamacc for showing me the light lol

    For extra points I've also changed the CPU limit and CPU units on my containers/VMs to keep it from using too much of the node's CPU.

    And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount:

    ----------------------------------------------------------------------
    CPU model            : Intel(R) Xeon(R) Gold 6128 CPU @ 3.40GHz
    Number of cores      : 3
    CPU frequency        : 3392.026 MHz
    Total size of Disk   : 98.0 GB (12.8 GB Used)
    Total amount of Mem  : 5960 MB (4530 MB Used)
    Total amount of Swap : 1022 MB (0 MB Used)
    System uptime        : 7 days, 9 hour 26 min
    Load average         : 2.11, 2.13, 1.55
    OS                   : Debian GNU/Linux 9
    Arch                 : x86_64 (64 Bit)
    Kernel               : 4.15.18-11-pve
    ----------------------------------------------------------------------
    I/O speed(1st run)   : 774 MB/s
    I/O speed(2nd run)   : 907 MB/s
    I/O speed(3rd run)   : 1.0 GB/s
    Average I/O speed    : 901.7 MB/s
    ----------------------------------------------------------------------
    
    Thanked by 1AlwaysSkint
  • @dahartigan said:
    swapoff -a

    Exemplary.

    Thanked by 1dahartigan
  • v3ngv3ng Member, Patron Provider

    Any plans for IPv6 support in the other locations?

    Thanked by 1uptime
  • dahartigan said: And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount

    You really know how to treat a shared environment.

    Thanked by 1TimboJones
  • @dahartigan said:

    @AlwaysSkint said:
    Reducing swappiness can lead to better performance - less I/O. I usually set 1 or 5, depending on my mood/weather/moon cycle/HostDoc crazy Flash deals. For SSD in particular, you do want it low, from a drive wear perspective, if nothing else.

    Oh no! It's swap shop again! :-o

    I just reduced my swappiness to 1 and then swapoff -a && swapon -a and now I'm using 0 swap and it's all in RAM now. Thanks to you and @teamacc for showing me the light lol

    For extra points I've also changed the CPU limit and CPU units on my containers/VMs to keep it from using too much of the node's CPU.

    And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount:

    ----------------------------------------------------------------------
    CPU model            : Intel(R) Xeon(R) Gold 6128 CPU @ 3.40GHz
    Number of cores      : 3
    CPU frequency        : 3392.026 MHz
    Total size of Disk   : 98.0 GB (12.8 GB Used)
    Total amount of Mem  : 5960 MB (4530 MB Used)
    Total amount of Swap : 1022 MB (0 MB Used)
    System uptime        : 7 days, 9 hour 26 min
    Load average         : 2.11, 2.13, 1.55
    OS                   : Debian GNU/Linux 9
    Arch                 : x86_64 (64 Bit)
    Kernel               : 4.15.18-11-pve
    ----------------------------------------------------------------------
    I/O speed(1st run)   : 774 MB/s
    I/O speed(2nd run)   : 907 MB/s
    I/O speed(3rd run)   : 1.0 GB/s
    Average I/O speed    : 901.7 MB/s
    ----------------------------------------------------------------------
    

    @dahartigan said:

    @AlwaysSkint said:
    Reducing swappiness can lead to better performance - less I/O. I usually set 1 or 5, depending on my mood/weather/moon cycle/HostDoc crazy Flash deals. For SSD in particular, you do want it low, from a drive wear perspective, if nothing else.

    Oh no! It's swap shop again! :-o

    I just reduced my swappiness to 1 and then swapoff -a && swapon -a and now I'm using 0 swap and it's all in RAM now. Thanks to you and @teamacc for showing me the light lol

    For extra points I've also changed the CPU limit and CPU units on my containers/VMs to keep it from using too much of the node's CPU.

    And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount:

    ----------------------------------------------------------------------
    CPU model            : Intel(R) Xeon(R) Gold 6128 CPU @ 3.40GHz
    Number of cores      : 3
    CPU frequency        : 3392.026 MHz
    Total size of Disk   : 98.0 GB (12.8 GB Used)
    Total amount of Mem  : 5960 MB (4530 MB Used)
    Total amount of Swap : 1022 MB (0 MB Used)
    System uptime        : 7 days, 9 hour 26 min
    Load average         : 2.11, 2.13, 1.55
    OS                   : Debian GNU/Linux 9
    Arch                 : x86_64 (64 Bit)
    Kernel               : 4.15.18-11-pve
    ----------------------------------------------------------------------
    I/O speed(1st run)   : 774 MB/s
    I/O speed(2nd run)   : 907 MB/s
    I/O speed(3rd run)   : 1.0 GB/s
    Average I/O speed    : 901.7 MB/s
    ----------------------------------------------------------------------
    

    Mind sharing how u set up Plex?

  • @uptime said:
    @HostDoc beware the "incero effect" - it's great to take care of business on the technical side, but a (studied and sympathetic) diplomatic response can go a long way when handling criticism in public.

    Especially in a troll-rich environment such as LET.

    (To be clear I don't think @Neoon is trolling. If you can work with him in a less confrontational / defensive way - even though "he started it" - it could help find and fix the tricky details that make for a superior service. I'm usually reluctant to spend much effort to open tickets for network quirks beyond perhaps an occasional "fyi, and by the way here's an MTR" if I really care - it's a bit of a chore when I can just move on to use another provider who has already somehow managed to take their network to a level that doesn't depend on my own dilligence to fix.)

    That said I'm certainly no fan of the canned and glib (and seemingly endless) "very sorry you've had a problem" response mill that some LEB-type hosts seem to specialize in.

    Let us consult @cociu and his sisters for best advice on bedside manner most suitable for making sales and keeping customers happy on LET.

    EDIT2:

    fartmother walks on thin eggs.

    Thanks for that and I totally agree.
    Apologies if it came across as the Incero effect, I never meant to present my take in such a manner

    Looking back, my first response took into consideration his request and I invited him to troubleshoot with us.
    The days comment made it seem as though it was ignored for days which had to be cleared up immediately.

    @Neoon You are more than welcome to present your findings with me so I can look into it further with you.
    As mentioned yesterday, if Finland is not suitable, let me know, we will work something out.
    I apologise for not handling this situation in a more professional manner and would like the opportunity to rectify it if you allow me to do so.

    @v3ng said:
    Any plans for IPv6 support in the other locations?

    Not a this time unfortunately as it seems to be a problem for OVH to give /48 allocations (they totally refuse to do so even for a fee) and the demand in Finland for v6 does not warrant the cost from Hetzner at this time.

    Thanked by 2uptime eol
  • edited February 2019

    First, let me apologize in advance if this is not allowed, but because Germany it's currently out of stock, I would like to know if there's anyone willing to sell the 4 Core VPS.
    Thanks in advance.

  • There is no Game Firewall Panel like in other vps providers. Like suppose in OVH Game all knows inbound UDP ports are defaulted we need explicit allowed but in here we cannot do ourself.

  • @imok said:

    dahartigan said: And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount

    You really know how to treat a shared environment.

    Heh, that was for all of 10 mins :)

    @cybertech said:

    @dahartigan said:

    @AlwaysSkint said:
    Reducing swappiness can lead to better performance - less I/O. I usually set 1 or 5, depending on my mood/weather/moon cycle/HostDoc crazy Flash deals. For SSD in particular, you do want it low, from a drive wear perspective, if nothing else.

    Oh no! It's swap shop again! :-o

    I just reduced my swappiness to 1 and then swapoff -a && swapon -a and now I'm using 0 swap and it's all in RAM now. Thanks to you and @teamacc for showing me the light lol

    For extra points I've also changed the CPU limit and CPU units on my containers/VMs to keep it from using too much of the node's CPU.

    And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount:

    ----------------------------------------------------------------------
    CPU model            : Intel(R) Xeon(R) Gold 6128 CPU @ 3.40GHz
    Number of cores      : 3
    CPU frequency        : 3392.026 MHz
    Total size of Disk   : 98.0 GB (12.8 GB Used)
    Total amount of Mem  : 5960 MB (4530 MB Used)
    Total amount of Swap : 1022 MB (0 MB Used)
    System uptime        : 7 days, 9 hour 26 min
    Load average         : 2.11, 2.13, 1.55
    OS                   : Debian GNU/Linux 9
    Arch                 : x86_64 (64 Bit)
    Kernel               : 4.15.18-11-pve
    ----------------------------------------------------------------------
    I/O speed(1st run)   : 774 MB/s
    I/O speed(2nd run)   : 907 MB/s
    I/O speed(3rd run)   : 1.0 GB/s
    Average I/O speed    : 901.7 MB/s
    ----------------------------------------------------------------------
    

    @dahartigan said:

    @AlwaysSkint said:
    Reducing swappiness can lead to better performance - less I/O. I usually set 1 or 5, depending on my mood/weather/moon cycle/HostDoc crazy Flash deals. For SSD in particular, you do want it low, from a drive wear perspective, if nothing else.

    Oh no! It's swap shop again! :-o

    I just reduced my swappiness to 1 and then swapoff -a && swapon -a and now I'm using 0 swap and it's all in RAM now. Thanks to you and @teamacc for showing me the light lol

    For extra points I've also changed the CPU limit and CPU units on my containers/VMs to keep it from using too much of the node's CPU.

    And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount:

    ----------------------------------------------------------------------
    CPU model            : Intel(R) Xeon(R) Gold 6128 CPU @ 3.40GHz
    Number of cores      : 3
    CPU frequency        : 3392.026 MHz
    Total size of Disk   : 98.0 GB (12.8 GB Used)
    Total amount of Mem  : 5960 MB (4530 MB Used)
    Total amount of Swap : 1022 MB (0 MB Used)
    System uptime        : 7 days, 9 hour 26 min
    Load average         : 2.11, 2.13, 1.55
    OS                   : Debian GNU/Linux 9
    Arch                 : x86_64 (64 Bit)
    Kernel               : 4.15.18-11-pve
    ----------------------------------------------------------------------
    I/O speed(1st run)   : 774 MB/s
    I/O speed(2nd run)   : 907 MB/s
    I/O speed(3rd run)   : 1.0 GB/s
    Average I/O speed    : 901.7 MB/s
    ----------------------------------------------------------------------
    

    Mind sharing how u set up Plex?

    I'm planning to write a guide soon, I'll let you know when it's ready. I've had a lot of people ask me, so there seems to be interest.

  • @dahartigan said:

    @imok said:

    dahartigan said: And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount

    You really know how to treat a shared environment.

    Heh, that was for all of 10 mins :)

    @cybertech said:

    @dahartigan said:

    @AlwaysSkint said:
    Reducing swappiness can lead to better performance - less I/O. I usually set 1 or 5, depending on my mood/weather/moon cycle/HostDoc crazy Flash deals. For SSD in particular, you do want it low, from a drive wear perspective, if nothing else.

    Oh no! It's swap shop again! :-o

    I just reduced my swappiness to 1 and then swapoff -a && swapon -a and now I'm using 0 swap and it's all in RAM now. Thanks to you and @teamacc for showing me the light lol

    For extra points I've also changed the CPU limit and CPU units on my containers/VMs to keep it from using too much of the node's CPU.

    And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount:

    ----------------------------------------------------------------------
    CPU model            : Intel(R) Xeon(R) Gold 6128 CPU @ 3.40GHz
    Number of cores      : 3
    CPU frequency        : 3392.026 MHz
    Total size of Disk   : 98.0 GB (12.8 GB Used)
    Total amount of Mem  : 5960 MB (4530 MB Used)
    Total amount of Swap : 1022 MB (0 MB Used)
    System uptime        : 7 days, 9 hour 26 min
    Load average         : 2.11, 2.13, 1.55
    OS                   : Debian GNU/Linux 9
    Arch                 : x86_64 (64 Bit)
    Kernel               : 4.15.18-11-pve
    ----------------------------------------------------------------------
    I/O speed(1st run)   : 774 MB/s
    I/O speed(2nd run)   : 907 MB/s
    I/O speed(3rd run)   : 1.0 GB/s
    Average I/O speed    : 901.7 MB/s
    ----------------------------------------------------------------------
    

    @dahartigan said:

    @AlwaysSkint said:
    Reducing swappiness can lead to better performance - less I/O. I usually set 1 or 5, depending on my mood/weather/moon cycle/HostDoc crazy Flash deals. For SSD in particular, you do want it low, from a drive wear perspective, if nothing else.

    Oh no! It's swap shop again! :-o

    I just reduced my swappiness to 1 and then swapoff -a && swapon -a and now I'm using 0 swap and it's all in RAM now. Thanks to you and @teamacc for showing me the light lol

    For extra points I've also changed the CPU limit and CPU units on my containers/VMs to keep it from using too much of the node's CPU.

    And I just did another bench.sh while pushing the system by transcoding a 1080 video with plex off an sshfs mount:

    ----------------------------------------------------------------------
    CPU model            : Intel(R) Xeon(R) Gold 6128 CPU @ 3.40GHz
    Number of cores      : 3
    CPU frequency        : 3392.026 MHz
    Total size of Disk   : 98.0 GB (12.8 GB Used)
    Total amount of Mem  : 5960 MB (4530 MB Used)
    Total amount of Swap : 1022 MB (0 MB Used)
    System uptime        : 7 days, 9 hour 26 min
    Load average         : 2.11, 2.13, 1.55
    OS                   : Debian GNU/Linux 9
    Arch                 : x86_64 (64 Bit)
    Kernel               : 4.15.18-11-pve
    ----------------------------------------------------------------------
    I/O speed(1st run)   : 774 MB/s
    I/O speed(2nd run)   : 907 MB/s
    I/O speed(3rd run)   : 1.0 GB/s
    Average I/O speed    : 901.7 MB/s
    ----------------------------------------------------------------------
    

    Mind sharing how u set up Plex?

    I'm planning to write a guide soon, I'll let you know when it's ready. I've had a lot of people ask me, so there seems to be interest.

    Thanks mate, I'm very interested in that guide :)

    Thanked by 1dahartigan
  • Refresh the deal page Singapore fans, there's a 4 cores beast in there.. snap it up before I impulse buy it haha

    Thanked by 3eol LeonDynamic HostDoc
  • LeonDynamicLeonDynamic Member
    edited February 2019

    Have a look at the beast in Dallas 3 core 10 gb ram and 10TB bandwidth

  • @dahartigan @hostdoc how does the dual disk work. Does it show as separate drives?

Sign In or Register to comment.