-
Posts
604 -
Joined
-
Last visited
-
Days Won
4
Content Type
Profiles
Forums
Downloads
Events
Store
Blogs
Gallery
Raffles
Everything posted by codeYeTi
-
Server #2 once again running with the new I/O backend today (it's been on the S1 code yesterday). Pipe up if you think something that's working properly on S1 is not on S2 today.
Thanks again for the patience, this new system should significantly improve things for us once it's stabilized and mature.
-
Update on the Server 2 situation since yesterday:
S2 yesterday saw some sync's frequently not happening. Luckily, the root cause of this was not the new I/O plugin, and instead a completely separate bug. This was fixed late in the night.
S2 will still be rockin' the new plugin, but after observing it after the fix, I'm quite hopeful for a lack of issues.
Hopping on and giving her a bit more stress today really helps us out in maturing this faster, so have at 'er!
-
Hello! When Server 2 opens today (8pm EDT), it will be running a very new experimental I/O backend we've written from scratch over the past couple of months. We've done this as an attempt to improve the less-than-desireable server performance we've been seeing at high population levels over the past while.
While we're not expecting any issues, due to this being quite the experiment, with changes to database interaction/logging, and other core components, YMMV with respect to receiving comp if things are just completely crashing. Obviously, admin staff may pity you if it's something huge, but please understand that comp is not guaranteed, and avoid submitting requests, especially for small stuff like losing a loadout to a server crash (if it happens, that is *fingers crossed*).If you want to help, play a bit of S2 tonight to help give 'er a decent day 1 stress test!
I've spent an insane amount of time on this system over the past 4 months or so to try and get our server performance up to a livable level, so thank you for pardoning my dust as we work on rolling this out to production workloads!
-
DevOps team often never see the appreciation from the client side stakeholders.
Thank you for working on this as performance has been a pain point of playing on Olympus since I've been here. Optimizing backend architecture (More so that you likely didn't write and probably wasn't commented) is a bitch.
Congrats on reaching your beta deployment and to a hopeful successful go live!
-
-
Hello, if you are on the Profiling branch of ArmA, they released a broken version of it this morning, and you will see no map markers, and vehicles pulled from most garages will not properly spawn. To prevent this for now, please just downgrade to the 2.08.v00 version of the profiling/performance branch via the official Bohemia google drive for it here.
https://drive.google.com/file/d/1OzpCCp0vKQT201PeVvLM9figGdjfe2nq/view?usp=sharing -
If your ISP is CenturyLink, and you're having issues connecting to the Teamspeak or the Olympus servers, please complain to CenturyLink. This is a failure somewhere in their routing right now, and there's little we can do about it from our side.
This is affecting me too and I've love for them to get off their bums
EDIT - This has somewhat been resolved. CenturyLink's routing has been repaired to a pre-outage state, but is still abismal for latency performance. Using a VPN in my area that was connected to the comcast backbone resulted in a 30% drop in ping, meaning that while the routing they're doing is now working, it is still very sub-par for midwest centurylink customers trying to reach OVH servers. If you experience similar symptoms, please still reach out to them, as multiple complaints is the only way this likely-easily-resolvable issue will get enough traction to be looked at on their end.
- Show previous comments 7 more
-
Just use the google DNS server should fix the issue
-
@ buckie @ MAV DNS server swap will not resolve this one. The issue (now was) since it's somewhat resolved, an actual problem with the routing of traffic to those given ranges of IP addresses. The IPs were being resolved correctly by the DNS servers, but the traffic could not get to the actual IP addresses that the domain names resolved to.
Side note - do not use Google public DNS if you can avoid it. Letting an advertising firm know every domain name that you resolve is giving up a good amount of data to a company that really just doesn't need more. Companies like cloudflare (operating free DNS servers on 1.0.0.1, 2606:4700:4700::1001, and similar pairing for 1.1.1.1) would be a better choice simply due to the fact that their business proposition lies at least moreso outside of the realm of exploiting the collection of personal data. Your DNS provider is always going to be getting a good amount of information about your browsing habits, so might as well choose a company that is more focused on other aspects of it's business than selling your data.
To each their own in that regard, but that's my 2c on using Google as a DNS provider. (Goes for using them as your ISP as well, though if they're the best offering in your area then I guess there's no way around that one).
-
-
2
-
- Report
-
That's odd that a single ISP would have routing issues that didn't cause mass outages, but
-
Why do we play this crap game v2.0
https://streamable.com/nwgv6p- Show previous comments 1 more
-
Im with skys seems like you got outgamed by weed field
-
Tempest didn't even explode. 3/10
-
Ooops sorry what I meant was
https://streamable.com/t26b1ewhy do we do this. everyone playing is a masochist, including me
-
Sometimes I don't even know why we play this PoS game
https://streamable.com/1f36uh