Forums » General
News post / GAME MAINTENANCE
The game will be down on Thurs 01/04/07 from 11PM to 1AM CST:
http://www.vendetta-online.com/h/news.html
[Edit] I also welcome comments for this:
http://www.vendetta-online.com/x/msgboard/3/15706
http://www.vendetta-online.com/h/news.html
[Edit] I also welcome comments for this:
http://www.vendetta-online.com/x/msgboard/3/15706
Actually I have been very impressed by the overall reliabilty and lack of downtime of VO. Hope all the new bits fit first time.
Ecka
Ecka
Yes. The lack of regularily scheduled downtime a la EVE is awesomeness.
...and we're back?
I just noticed the webserver suddenly responded again :D
That usually means the game server is close behind. This I base on my experience with all downtimes since I joined in 2003. All five of them!
:D
I just noticed the webserver suddenly responded again :D
That usually means the game server is close behind. This I base on my experience with all downtimes since I joined in 2003. All five of them!
:D
We're back. We've actually been back for an hour or so, but Andy forgot to run the update server. So.. we're all the way back now. Woo. Sorry for the inconvenience.
Well, next time I'll try bypassing the updater :)
Did it all go as expected?
Did it all go as expected?
Actually, the core game server update went really smoothly. Which is what we were expecting might be more problematic. Then I tried to do some "minor" kernel updates to the webserver machine and all hell broke loose. Murphy's law of server administration, things go ill only when you least expect it.
Anyway, everything's back now, although we still have more maintenance to do (over the coming couple of months, I expect) until the server cluster is better implemented.
Anyway, everything's back now, although we still have more maintenance to do (over the coming couple of months, I expect) until the server cluster is better implemented.
Hopefully future updates will go as smooth as this one. Thank you for the excellent availability :)
When do we know if Deliverator performs better in it's final days?
When do we know if Deliverator performs better in it's final days?
We have to wait and see how it goes over the next few days. We don't expect it to really perform much differently, but the new machine has more total memory, so the Common Lisp platform will take longer to run out of gas and die. But, it is a slightly newer version on a different platform, so we'll just have to see.
On the upside, the deliverator-replacement is still in the works and moving along well. Hopefully we'll be starting to roll that into production within a couple of weeks, fingers crossed.
On the upside, the deliverator-replacement is still in the works and moving along well. Hopefully we'll be starting to roll that into production within a couple of weeks, fingers crossed.
would these change affect lag issues?
Which lag issues? "Lag" is generally used to describe at least 3 different common problems.
well, one example is in deneb b12. whenever a hac jumps in the entire sector freezes for a second.
at other times, half the shots dont register because of ship movement lags (aka, local things it has hit but actual ship is no longer there and thus server doesn't send back an actual hit).
those are the kind of lags i'm inquiring about.
at other times, half the shots dont register because of ship movement lags (aka, local things it has hit but actual ship is no longer there and thus server doesn't send back an actual hit).
those are the kind of lags i'm inquiring about.
Well, that's a good example of how varied "lag" causes can be.
The HAC, for instance, is caused by your machine having to load the rather-large textures for the HAC all of a sudden (1024x1024 at 24bpp, is 3.1megabytes). We'd like to do more advanced texture precaching (like starting to load it when the capship is in an adjacent sector) and also split off a separate thread for I/O, but those are both non-trivial undertakings and would take awhile to do. We could add an option to let people just precache everything, but you'd only want to do that if you had a lot of ram.
The hit-movement "lag" can be based on a couple of factors. 1) it could be the network connection between you and our server cluster isn't working well.. this can happen at any point along the path, and in either direction (send or receive). Asymmetric routing is a condition where the path the packets traverse while being *sent* is not the same as when they're *received* from a given host.. and unfortunately it's not an uncommon condition on the internet, due to various providers padding out routes to make the most of their available bandwidth. 2) It could also be that the SD (the process which "is" the sector) is getting overloaded.. some conditions, like a whole LOT of bots colliding with one another, or complex capships running into things, can cause excessive load on the SD. For that we plan to improve the way we handle collisions, but it's also a non-trivial fix. On the upside, that doesn't happen that often (statistically); on the downside.. it only happens during more "interesting" gameplay (tons of ships/caps flying around, big battle, Border Skirmish and the like), so it's more common during stuff that, well.. people actually want to do. If there aren't a whole lot of bots in a sector having a battle and running into each other or complex asteroids, it's probably 1).
Most people don't like to be told that the "general internet" is at fault, but that is the most common problem, by far. Those of us who've worked as engineers at large ISPs are continually amazed that the internet works at all.
As a final note, or 3) based on the upper two possibilities. It's also possible for someone on a limited-bandwidth connection to have their connectivity saturated by incoming data. On a modem, for instance, or some other kind of rate-limited connection, you might exceed your available bandwidth in a really, really chaotic battle. Our compression is pretty good, and the protocol pretty efficient, so this is rare, but it can happen.. and if it did, the result would be the same as for 1) and 2). Namely, your view of the battle would become time-lagged, and when you shot at the enemy and hit him on your local client, the packets would get verified by the SD who would then say "no, he isn't there anymore" and the hits would be rejected. We keep prioritization queues for every connected user, and prioritize by in-sector "distance" (and other factors), plus there's a lot of client interpolation.. so this is pretty uncommon, but it is possible. There's really nothing we can do about this at all.. you can't have a lot of stuff flying around and being cool and interesting, without sending the packets required to update those positions. Anyone on a modern "broadband" connection should not experience this.
The HAC, for instance, is caused by your machine having to load the rather-large textures for the HAC all of a sudden (1024x1024 at 24bpp, is 3.1megabytes). We'd like to do more advanced texture precaching (like starting to load it when the capship is in an adjacent sector) and also split off a separate thread for I/O, but those are both non-trivial undertakings and would take awhile to do. We could add an option to let people just precache everything, but you'd only want to do that if you had a lot of ram.
The hit-movement "lag" can be based on a couple of factors. 1) it could be the network connection between you and our server cluster isn't working well.. this can happen at any point along the path, and in either direction (send or receive). Asymmetric routing is a condition where the path the packets traverse while being *sent* is not the same as when they're *received* from a given host.. and unfortunately it's not an uncommon condition on the internet, due to various providers padding out routes to make the most of their available bandwidth. 2) It could also be that the SD (the process which "is" the sector) is getting overloaded.. some conditions, like a whole LOT of bots colliding with one another, or complex capships running into things, can cause excessive load on the SD. For that we plan to improve the way we handle collisions, but it's also a non-trivial fix. On the upside, that doesn't happen that often (statistically); on the downside.. it only happens during more "interesting" gameplay (tons of ships/caps flying around, big battle, Border Skirmish and the like), so it's more common during stuff that, well.. people actually want to do. If there aren't a whole lot of bots in a sector having a battle and running into each other or complex asteroids, it's probably 1).
Most people don't like to be told that the "general internet" is at fault, but that is the most common problem, by far. Those of us who've worked as engineers at large ISPs are continually amazed that the internet works at all.
As a final note, or 3) based on the upper two possibilities. It's also possible for someone on a limited-bandwidth connection to have their connectivity saturated by incoming data. On a modem, for instance, or some other kind of rate-limited connection, you might exceed your available bandwidth in a really, really chaotic battle. Our compression is pretty good, and the protocol pretty efficient, so this is rare, but it can happen.. and if it did, the result would be the same as for 1) and 2). Namely, your view of the battle would become time-lagged, and when you shot at the enemy and hit him on your local client, the packets would get verified by the SD who would then say "no, he isn't there anymore" and the hits would be rejected. We keep prioritization queues for every connected user, and prioritize by in-sector "distance" (and other factors), plus there's a lot of client interpolation.. so this is pretty uncommon, but it is possible. There's really nothing we can do about this at all.. you can't have a lot of stuff flying around and being cool and interesting, without sending the packets required to update those positions. Anyone on a modern "broadband" connection should not experience this.
suggestion added.
my connection has an average 30 ping time, on a cable modem.
i've not had the audacity to run a packet sniffer on vo to see if (/what) might be causing "missed targets" mostly because others seem to have reported the same at most times it happen to me.
those have mostly been in border skirmish & border patrol but i've also seen it at other occasions. eg: that camillia/lexicon event we had last weekend: many shots i fired (as lebermac) onto lexicon fired blanks. there were a good number npcs and players in there though.
of course, bs and bp is not much of a concern until deliverator gets phased out and the missions return to their normal states.
my connection has an average 30 ping time, on a cable modem.
i've not had the audacity to run a packet sniffer on vo to see if (/what) might be causing "missed targets" mostly because others seem to have reported the same at most times it happen to me.
those have mostly been in border skirmish & border patrol but i've also seen it at other occasions. eg: that camillia/lexicon event we had last weekend: many shots i fired (as lebermac) onto lexicon fired blanks. there were a good number npcs and players in there though.
of course, bs and bp is not much of a concern until deliverator gets phased out and the missions return to their normal states.