In future when reporting a problem please ensure you include the following information:
- Node hostname or IP - it's important that you know which node you're reporting a problem for so we can match logs up and find the issue. If you report a problem without knowing what node you're on (the above example says lag on NY01 but reports the NY02 IP, what?), your report cannot be followed up.
- Time and date including timezone - if we don't know when you're experiencing problems, we can't match logs up to work out and fix the problem. If there is a serious case of high latency and you don't think it's localised to you, it's important we find out times and routes so we can work with upstream providers to understand the issue.
- Server host - lag can sometimes be caused by high CPU usage, this needs to be checked in logs too
If you don't include that information, your report is 100% useless, will be considered as spam and reported accordingly. I'm happy to hear reports of problems so we can fix them and improve service quality, but if we're not receiving data, nothing can be done.
With regards to issues involving NY02, I admit, that server isn't as efficiently routed as NY01 and sometimes suffers from degraded network performance despite being in the same facility as NY01. Problems with quality of service aren't acceptable to me and we're working with our provider to resolve them. NY02 has been assigned a new IP address of
209.159.159.162 and the
ny02.returntoblockland.com record has been updated to point to this IP. Despite this, the primary IP assigned to NY02 is still the old, problematic IP as switching over requires configuration from us, and from our provider at the router level. As our provider is small, finding a mutually convenient time to alleviate the disruption is proving to be quite difficult, but I promise this will be sorted by this time next week at the latest.
Please don't ignore my request about information, it's not difficult to include it. Improving service quality is my primary concern and I don't really care who the reports come from, just that they include the required data for us to investigate. I'm currently adding more monitoring servers to our internal monitoring and will be looking to provide even more public reports in the future.
Thanks!
Do you think a "Force Autosave" button would be feasible? For instance, when you want to restart the server, but you don't want to hop on and save everything manually you could simply press that button and make the server save it for you.
Yep, no problem. This has been on the to-do list for a while we just haven't got round to it yet. We'll include it in the next major update, if not before.
Have just added more RTT checks to our munin monitoring installation using 3 strategic locations (Fremont, CA, Atlanta, GA and Manchester, UK), as you can see below. This should help us verify claims of networking issues and understand exactly what latency issues are caused by. I'm currently looking into making output from these graphs public, will update when I have that.
