totemo

Yep. You're unbanned.

You're banned for one month. Your inventory has been cleared and all your edits have been wiped from the map. OPEN A NEW APPEAL HERE ON THE 24TH OF FEBRUARY. You will then be unbanned. You mined 13 diamond ore deposits: 9 on the 13th of January (server time zone) and 4 on the 24th. All of them look like some kind of x-ray or x-ray like cheating. Images of your edits, as stored in the server logs, follow.

It's late where I am, so I'll process your appeal in full in about 9 hours. But in a word: 'no'. You are responsible for the actions performed by your account, and we never accept the brother/cousin/best friend defence. Also, it seems like all of your diamond edits, today and 11 days ago, used cheats. So, I believe you were probably in control of the account on both occasions, but as noted above, that doesn't matter either way.

/me deals with a bunch of S ban appeals.

I think that you probably sent me that inappropriate (racist) message by accident, with /r. However, I'm told by other staff that you have recently gotten away with the occasional bit of racism along similar lines in global chat. I also said here, just a week ago, that your next ban would be a week minimum. I'm going to give you the benefit of the doubt on this one. But the next ban really will be a week, whether it's accidental or not. Pull your head in. Unbanned.

All of my wat.

I'm addressing IKAKATORR's appeal here only. McKnightly should appeal to geb_ and the alt ban can be addressed there. Your grief would have been unpleasant for the builder of the house to find in the map download. Please be considerate of other players in the future. You seem to take up a disproportionate amount of staff time trolling. We're sick of it. Please stop that. For now you are banned until Monday the 11th. Subsequent bans will be a week minimum.

Mumberthrax is no longer on staff and in any case, this ban is 14 months old and I doubt he would retain screenshots (for proof) from that long ago, though I am certain he would have taken them at the time. So I will handle your appeal. You were banned when your name was XXXwanerbrosXXX, which also happens to be your profile name on a well known grief team web site. That, together with your attitude in this appeal is proof enough for me, though I have every confidence in the procedural integrity of Mumberthrax's ban on your account. Even if you weren't in charge of the account (as in, it was compromised) the account is held liable for all actions performed by it, irrespective of who is in control. In the event that you suspect that your account was compromised, change the password now. All that said, it's been 14 months. You're unbanned.

What a time to be alive. \o/

Although the specific mechanism that you used to xray has no effect on our handling of it, I will simply note, for future reference, that you were using an xray mod, in addition to, or instead of a texture pack. The first diamond edit proves it, since it was not adjacent to transparent blocks. You're banned from the servers for one month. All of your edits have been wiped from the map and your inventory and chests cleared. Please open a new appeal on the 29th of December and you will be unbanned. Some of your edits are depicted below:

Hi, random guy on the internet. Unfortunately you used the Xray hacks on PvE (p.nerd.nu) where it's a problem. The grief was exceedingly minor and can be discounted. You're banned from nerd.nu game servers for 1 month from the date of the ban (Nov 19th), your inventory has been wiped and all your edits undone. Please make another appeal in a month as a reminder to us and we'll unban you. Screenshots of the xray edits follow:

Yup. Thanks for the reminder. You are now unbanned.

Ha ha ha. Somehow, I knew you were going to be one of those guys that denies xraying. :) All the diamond edits were off the sides of pre-existing excavations. You also xrayed iron and a dungeon. You're banned for one month, as is standard practice in dealing with xray on this server. Your inventory was cleared and all your edits have been wiped from the map. The ores you took are permanently removed. Here are your edits, as logged by the server. The stone edits are shown in full; there is nothing more to your tunnels.

Everything.

Sure thing.

X-ray is regarded as a serious infraction of the rules and attracts a one month ban. All of your edits have been removed from the map and your inventory has been cleared. Please open a new appeal on the 12th of November, as a reminder to us, and you will then be unbanned. A few screenshots of your mining (as logged by the server) follow:

The reason I asked, of course, was in case the CobraCorral fix was going to take a long time. Or if we run the new version and things turn out to be not as simple as was thought. I had a chat to TheAcademician today, in game, and she said that new locked horses wouldn't get registered with the DB if we disabled CobraCorral. So GPS data would be off. However she also said that it would eventually resolve itself and otherwise shouldn't be an issue. So given that there is a new version in the works, I look forward to seeing what it does for the lag. And I'm still mystified by these 1000ms pauses.

Thanks, C45Y. Those are some very interesting numbers. The measurements for "Horse found, checking for lock and updating; duration=" are all 1001, 1002, 2001 or 2002 ms. Is something sleeping for precisely one second? It seems to me that we could simply disable CobraCorral and re-enable the lock-horses setting in KitchenSink. Everybody's horse would then be locked to the person who tamed it, right? We would lose the ability to share horses, except by the temporary sharing feature built into KitchenSink, and we would lose fancy stuff like GPS. But the server would be playable. Perhaps we could get TheAcademician to comment on how well CobraCorral would cope with being disabled for a while until the database issue is fixed?

That's the same timing Redwall. I assume you meant to link a different one. Can we see the one that shows the problem? I'm confused about the TPS drops. Last I heard, TPS was weirdly rock solid:

Just to deepen the mystery even further, C45Y: CobraCorral v1.2.2 Total: 0.006 s Pct: 0.01% Pct Total Pct Tick Total Avg PerTick Count Event 0.01% 0.01% 0.00 s 0.01 ms 0.5 0.6k CorralListener::onChunkUnload(ChunkUnloadEvent) 0.00% 2.52% 0.00 s 1.26 ms 0.0 0.0k CorralListener::onPlayerJoin(PlayerJoinEvent) 0.00% 0.00% 0.00 s 0.00 ms 0.2 0.3k CorralListener::onEntityDamage(EntityDamageEvent) 0.00% 0.02% 0.00 s 0.01 ms 0.0 0.0k CorralListener::onInventoryClose(InventoryCloseEvent) 0.00% 0.42% 0.00 s 0.21 ms 0.0 0.0k CorralListener::onPlayerInteractEntity(PlayerInteractEntityEvent) 0.00% 0.01% 0.00 s 0.00 ms 0.0 0.1k CorralListener::onInventoryClick(InventoryClickEvent) 0.00% 0.00% 0.00 s 0.00 ms 0.0 0.0k CorralListener::onEntityDamageByEntity(EntityDamageByEntityEvent) 0.00% 0.00% 0.00 s 0.00 ms 0.0 0.0k CorralListener::onInventoryOpen(InventoryOpenEvent) 0.00% 0.00% 0.00 s 0.00 ms 0.0 0.0k CorralListener::onEntityDeath(EntityDeathEvent) 0.00% 0.01% 0.00 s 0.00 ms 0.0 0.0k CorralListener::onInventoryDrag(InventoryDragEvent) 0.00% 0.00% 0.00 s 0.00 ms 0.0 0.0k CorralListener::onVehicleExit(VehicleExitEvent) onChunkUnload() was called about 600 times, averaging 0.01ms per call in one of the more recent timings that you guys linked: http://timings.aikar.co/?url=12629871. You were saying that you saw an 11,000ms chunk unload event. It's really strange that this doesn't show up on the timings. 11000ms/600 = 18.3 ms. A single bad event should have a noticeable effect on the average.

Next thing to try, if relevant: -XX:+PerfDisableSharedMem From TL;DR: http://www.evanjones.ca/jvm-mmap-pause.html

I'm not sure what triggers that particular message or where they learned to spell "amount" but can we run for a while without DynMap to see what effect that has. That latest GC graph for BungeeCord shows memory usage spikes of about 175 MB, e.g. at about 12:08, 12:18, 12:23, 12:28. Do they correlate with saves? Where do the lag spikes happen on that time scale? What would be causing bungee to suddenly buffer so much stuff? It seems to be instantaneous, rather than following the preceding slope of the graph. Makes me wonder about TCP receive buffer tuning: http://www.cyberciti.biz/faq/linux-tcp-tuning/. I'm not sure that the graph really points to that. Just throwing it in there in case it triggers any thoughts.

It seemed like the changed JVM flags for BungeeCord had a pronounced negative effect on latency. There was a considerable increase in in the amount of NCP spam about "too many packets". Although the effect was detrimental, it's interesting that there was an effect. It will be interesting to see what the heap is doing. One interesting fact that's apparent from the graph you posted: we're churning through about 80MB of young generation heap every minute. And then after 45 minutes or so, we run out of headroom and the GC clears up the old generation. I'm not sure if those are the old GC settings or the new. But I do wonder, how long is that young generation GC taking, in particular: in comparison to a tick (50ms). According to this article G1 will give us lower latency collections than CMS which is what we would want, I guess. Looking through Oracle's docs, I notice that the default goal for a GC pause with G1 is 200ms. That's 4 ticks. Could we reduce that somewhat drastically: -XX:MaxGCPauseMillis=25? The third heading at that page, "The G1 Garbage Collector", goes into detail on how G1 operates and differs from CMS. According to this, we should be able to achieve 10ms collections for BungeeCord. We might need to run with a fair bit more headroom though. The G1 command line options are summarised rather well here, bottom of the page.

Also, C45Y, can you indicate which plugins specifically you have previously disabled in testing. Mark with a starr or something like that. Curious about Multiverse. And further questions: * NerdList is in the changed list. Can we get a source code link?

Get rid of SureLog. It was just experimental stuff and absolultely doesn't need to be there. I doubt (hope) it's not having any effect. :)