| 00:36.41 | Noshei | ZorbaBeta: what are your thoughts on people claiming that TCP is to blame for a lot of the server lag surrounding CQ? |
| 00:36.58 | Imhothar | CQ? |
| 00:37.35 | Noshei | conquest |
| 00:38.33 | Imhothar | heh wonder what kind of arguments people came up with |
| 00:39.39 | Noshei | basically that TCP is not good at handling large amounts of traffic and resules in higher packet loss |
| 00:39.53 | Noshei | super over simplified |
| 00:40.12 | Noshei | http://forums.riftgame.com/game-discussions/dungeons-raids/410636-spine-shatter-volan-2.html#post4675787 |
| 00:41.24 | Imhothar | haha |
| 00:41.38 | Imhothar | lots of traffic = DDoS |
| 00:41.40 | Imhothar | love it |
| 00:42.13 | Noshei | if you read the paper they linked it does make a fairly decent arguement that UDP would be better |
| 00:42.28 | seebs | TCP is more vulnerable to buffer bloat. |
| 00:42.39 | seebs | Huh. |
| 00:42.41 | Noshei | at least from a congestion stand point, though there are downsides to UDP |
| 00:42.47 | seebs | I just thought of a lovely horrible thing for a TCP server to do. |
| 00:43.02 | Imhothar | I'm reading it right now, but the guy who posted it just tried to troll that congestion is the same as a DDoS attack |
| 00:43.03 | seebs | Which is to send spoofed naks to make things in the middle think they need fewer buffers. |
| 00:45.35 | Noshei | oh look, the spammers are back at it in the addon forum |
| 00:50.19 | Imhothar | well not sure how serious the paper can be taken though |
| 00:50.34 | Imhothar | even with their million lines of traces the sample size is still 1 |
| 00:50.42 | Imhothar | 1 implementation of a game |
| 00:50.59 | Noshei | yesh |
| 00:51.03 | Imhothar | if they had data for 10 games that's be different |
| 00:51.05 | Noshei | *yeah |
| 00:51.39 | Imhothar | showign that all major MMO suffer from their current usage and implementation of TCP would definitely mark a point |
| 00:52.02 | seebs | TCP does indeed cause all sorts of problems and add overhead, but it also offers a LOT of advantages. |
| 00:52.04 | Imhothar | but the way it is all they show is it's unsuited for *one* game |
| 00:52.12 | seebs | You can use UDP, but you end up recreating a lot of TCP in it. |
| 00:58.34 | Imhothar | anyway, some random dude on forum saying "CQ lags because of TCP" is as believable as if he said "CQ lags because the planets are misaligned" |
| 00:58.56 | Imhothar | he knows squat about how the stuff is implemented on both ends |
| 00:59.17 | Imhothar | and as the paper shows message size and frequency is quite relevant |
| 00:59.51 | Noshei | I would expect message size to be low and frequency to be high for pretty much any mmo |
| 01:02.44 | Imhothar | depends on the definition of low and high |
| 01:03.43 | Imhothar | other thing is, they looked only at a single game whose playerbase is mostly concentrated in the same area, i.e. Taiwan |
| 01:04.02 | Imhothar | would be interesting to see whether a global playerbase changes things |
| 01:04.31 | Imhothar | e.g. EVE where people from all timezones play at once |
| 01:34.21 | Imhothar | half the papers they use as reference are by themselves |
| 01:37.29 | Imhothar | ok this si funny |
| 01:37.43 | Imhothar | "I've pointed this out before, but TCP is not a good protocol for this kind of traffic for many reasons, and this has been researched time and time again" |
| 01:37.52 | Imhothar | But even the paper states it has not been done before |
| 01:37.57 | Imhothar | people... |
| 01:38.17 | Imhothar | when will they grow brains |
| 02:31.35 | Noshei | yeah their arguement is pretty bad, but it does bring up a good discussion of if the protocol might be a contributing factor |
| 03:05.35 | ZorbaBeta | it isn't, honestly. if we switched to UDP we'd just have to reimplement TCP on top of it. out-of-order arrival is a royal pain and is used only when it's worth the trouble |
| 03:06.16 | ZorbaBeta | UDP made a lot of sense when people had 14.4 modems with 2-3% packetloss, and you were trying to jam 20kbit of data through it somehow. in terms of game protocols, it's pretty much irrelevant today. |
| 03:07.15 | Imhothar | well their argument don't come out of thin air entirely |
| 03:08.07 | ZorbaBeta | it doesn't come out of thin air but it's grounded in a lot of misconceptions. here, lemme just go down the major bullet points real fast: |
| 03:09.08 | ZorbaBeta | "Game packets are small" - if the amount of data being sent is small, then doubling bandwidth is irrelevant. If the amount of data being sent is large, then game packets aren't small anymore, and the overhead ends up being minimal. Servers aren't bottlenecked on bandwidth, they're bottlenecked on CPU, and the same is true of clients today - we mostly don't care about bandwidth. |
| 03:09.36 | ZorbaBeta | "TCP ensures in-order delivery at the byte level" - Yes. That's why we like it. We *like* having our job not a nightmare :V |
| 03:10.10 | Noshei | yeah I figured that the delivery guarentee was a big + to tcp |
| 03:10.51 | Noshei | so would you guess that the conquest lag issue is more of a cpu issue then? |
| 03:10.52 | Imhothar | the argument about packet size isn't becasue of bandwidth, it's implications on how TCP behaves with retransmit, loss detection and window size |
| 03:10.53 | ZorbaBeta | "Congestion control mechanism doesn't work well" - this is true, but it's not true enough to be an issue. Games already lag by 1-2 frames just for rendering purposes, monitors lag by 1-2 frames because monitor developers are cheap. Lagging network data by 1-2 frames isn't a big problem unless you're doing a super-fast action game, which is basically "FPS or fighting game". |
| 03:11.23 | ZorbaBeta | "Fast re-transmit doesn't work" - yeah, but packetloss also largely doesn't exist anymore. |
| 03:11.42 | ZorbaBeta | noshei, almost certainly |
| 03:11.43 | Imhothar | depends on where you are |
| 03:11.47 | Imhothar | or, how far away |
| 03:12.13 | ZorbaBeta | to the best of my knowledge we've had three real networking problems in rift ever. two of them were bugs sending *way* too much data from the client, one was a faulty network card :V |
| 03:12.44 | Imhothar | I wonder how CCP is handling their network code in those 4000 player battles |
| 03:13.08 | Noshei | they slow down time a shit ton, but that is to help cpu load |
| 03:13.10 | Imhothar | they had a blog some time back explaining how their servers are connected to the ISP |
| 03:13.38 | Imhothar | pretty hardcode |
| 03:14.04 | Imhothar | yeah EVE server bottleneck is and always was the GIL |
| 03:14.41 | ZorbaBeta | it's pretty much all server now, honestly - server bandwidth and client bandwidth is enormous, but it's tough to jam that many clients into a single server |
| 03:16.46 | Imhothar | I'd say in a case like EVE bandwidth still is a concern. That game still has unmatched amount of clients in a single datacenter doig realtime stuff |
| 03:19.11 | ZorbaBeta | it's still a concern, but it's not a big concern - I'd bet they spend a lot more time trying to make their server cluster better |
| 03:19.48 | Imhothar | heh, R&D top priority is making stackless lockless |
| 03:20.01 | seebs | Oddly, my cheaper monitor lags a frame less than my expensive monitors. |
| 03:20.09 | seebs | Or rather, the one which omits a feature. |
| 03:20.43 | seebs | It has no hardware scaling for intermediate resolutions, it can basically do 640x400 and 2560x1440, and I think 1280x720, and that's it. No other scaling. So it saves a valuable frame or two of lag. |
| 03:21.50 | ZorbaBeta | yeah, my monitor's the same way, though I haven't done any lag testing on it |
| 03:28.48 | Noshei | yay for no guarentee on event order! |
| 03:29.20 | Imhothar | there are probably quite a number of messages for which order of delivery doesn't necessarily matter |
| 03:29.42 | Noshei | mouse in one frame, before mouse out on another |
| 03:30.02 | Imhothar | oh we left the network topic |
| 03:30.05 | Imhothar | aye |
| 03:30.18 | Noshei | oh yeah I did at least |
| 03:31.09 | ZorbaBeta | yeah I've meant to fix that |
| 03:31.16 | Noshei | Imhothar: I vaguely remember you mentioning that you exposed your events for right/left click, that still true? |
| 03:32.24 | Noshei | I figured out a simple enough way around it. On mouse move I'm inspecting the tooltip and if it isn't there I send the command again |
| 03:33.22 | Imhothar | yes |
| 03:34.09 | Imhothar | http://rift.curseforge.com/addons/imhobags/pages/public-api/ |
| 03:34.18 | Noshei | I've got someone asking to be able to right click from imhobags to attach an item in easymail. So I was thinking I might make that work |
| 03:35.53 | Noshei | do drag and drop only work within imhobags? |
| 03:36.00 | Imhothar | no |
| 03:36.50 | Imhothar | but the events tell you when someone drags/drops items from/to an imhobags window |
| 03:37.06 | Imhothar | no idea if its of any use, but its there |
| 03:37.17 | Noshei | I guess I would just need drag then, since drop would be within my addon |
| 03:37.31 | Noshei | when you drag does it place the item on the cursor? |
| 03:37.36 | Imhothar | and .Right probably |
| 03:37.41 | Imhothar | of course |
| 03:38.02 | Imhothar | how dare you think otherwise! |
| 03:38.22 | Noshei | well just making sure you weren't just doing it internally |
| 03:38.55 | Noshei | shouldn't need drag at all actually, since I capture the drop |
| 03:39.23 | Imhothar | the only thing you probably need is .Right to catch when someone uses their item in imhobags |
| 03:39.28 | Noshei | yeah |
| 03:39.30 | Imhothar | BananAH uses it for posting |
| 03:39.42 | Noshei | ok, I'll take a look at how he did it |
| 03:47.56 | Noshei | should any information be passed when I right click in ImhoBags? |
| 03:48.27 | Imhothar | you did go to the link I posted, right? |
| 03:49.07 | Noshei | yes, but when I just setup a function and did a dump on params I get an empty table |
| 03:49.28 | Imhothar | that's probably the event handle then |
| 03:49.40 | Noshei | bah, yeah |
| 03:50.35 | Noshei | interesting, id seems to be slot specifier |
| 03:50.54 | Imhothar | shouldn't matter |
| 03:51.08 | Noshei | yeah, I can work with that |
| 03:51.18 | Imhothar | it can be an itemid though |
| 03:51.28 | Imhothar | just pass it to IID and be safe |
| 03:51.53 | Noshei | any way I could dim the item in ImhoBags? |
| 03:52.08 | Imhothar | no |
| 03:52.19 | Imhothar | can't do that myself |
| 03:52.34 | Noshei | why not? |
| 03:52.51 | Imhothar | there's no event telling you that an item is locked or in use in another window |
| 03:53.05 | Imhothar | so it would be inconsistent with the native UI |
| 03:53.15 | Noshei | ah fair enough |
| 03:53.52 | Imhothar | good news is people who already use IB probably don't even notice |
| 03:54.50 | Noshei | you would if you had to attach 60 items to a mail message |
| 03:55.19 | Imhothar | how convenient that I never have to do such a thing |
| 03:55.40 | Noshei | completely possible with EasyMail |
| 03:56.38 | Imhothar | job hazard |
| 04:16.38 | Noshei | ok well, that is added then |
| 04:17.08 | Noshei | didn't realise how much crap I did when an item is right clicked, may need to clean that up a bit at some point |
| 04:17.11 | Imhothar | a wave of joy is spreading amongst all EasyMail users |
| 04:17.13 | Imhothar | I'm sure of that |
| 04:17.29 | Imhothar | like? |
| 04:18.00 | Noshei | just crap within my oen addon |
| 04:18.36 | Noshei | the way it was it was just within the function that gets called by the event, but since I had that on a frame event I just copied pasted it to the function for your event. |
| 04:18.58 | Noshei | I could probably move most if not all of it to its own function instead of having the same code twice. |
| 04:21.25 | Noshei | now I just need to finish rewriting about half of the addon |
| 04:21.33 | Imhothar | peanuts |
| 04:21.42 | Imhothar | did that every other day at some point |
| 04:22.13 | Imhothar | https://xkcd.com/1319/ |
| 04:22.19 | Imhothar | happens so often |
| 04:23.16 | Noshei | lol |
| 04:24.18 | Noshei | well I'm still very dependant on the now rather old NKGenie and SimpleWidgets libs |
| 04:24.45 | Noshei | so I'm basically rewriting everything that I used them for so it is up to date with the new event system |
| 04:26.00 | Noshei | and the one thing that I'm using NKGenie for is rather complicated (the grid) |
| 04:32.29 | Ivnedar | oh wow, that cq lag is crazy |
| 04:50.09 | Noshei | yeah it is bad today |
| 05:24.23 | Ivnedar | I wonder what cq is doing to cause it |
| 05:25.23 | Noshei | network congestion due to rift using tcp |
| 05:34.23 | Ivnedar | lol, of coruse |
| 05:46.18 | *** join/#riftuidev Imhothar_ (~Imhothar@ppp-93-104-173-166.dynamic.mnet-online.de) |
| 05:59.23 | Amadeus- | ZorbaBeta, in Rift, what's the best value to use, when checking the watchdog, before yielding in a subroutine? |
| 05:59.44 | Amadeus- | you know, when doing something like: |
| 05:59.44 | Amadeus- | if Inspect.System.Watchdog() < 0.02 then |
| 05:59.44 | Amadeus- | coroutine.yield() |
| 05:59.44 | Amadeus- | end |
| 06:00.21 | Amadeus- | ... the /dump command in TrionDevelopmentUtilities uses 0.02 (which is where I got that value) ..but I wasn't sure if that was the BEST one to use for standard addons that might hit the watchdog occassionally. |
| 06:07.17 | ZorbaBeta | I don't know about "best". 0.02 is small enough that you're not wasting much time, and large enough that it's extremely unlikely you generate a warning anyway. It's also going to depend on how much work you do if that check passes - obviously if the next iteration is 0.05 seconds of work, 0.02 isn't gonna be enough |
| 06:07.39 | *** join/#riftuidev seebs (~seebs@home.seebs.net) |
| 06:07.42 | *** mode/#riftuidev [+o seebs] by ChanServ |
| 06:07.43 | Amadeus- | cool |
| 06:07.53 | ZorbaBeta | 0.02 feels like a good starter number to me, though :) |
| 06:07.56 | Amadeus- | okie, I'll start with that and see if it removes the performance warnings that I'm getting in the daily report |
| 06:08.01 | ZorbaBeta | sounds good :) |
| 06:08.17 | Amadeus- | I'm happy with my final version |
| 06:08.29 | Amadeus- | https://dl.dropboxusercontent.com/u/19522021/Capture.JPG |
| 06:08.49 | Amadeus- | (a lot of copying of logic/code from that /dump command ..hehe) |
| 06:09.30 | Amadeus- | although ..I never quite got coroutine.wrap() to work as it should the .create seemed easier to work with and understand, even though from the DESCRIPTION .wrap seems easier to use. ....but whatever :) |
| 06:10.16 | Amadeus- | ..anyway ...that code works pretty well ..I changed the value to 0.11 and could see it processing one item a frame ..hehe |
| 06:10.24 | Amadeus- | was like slow motion |
| 06:12.35 | *** join/#riftuidev seebs (~seebs@home.seebs.net) |
| 06:12.38 | *** mode/#riftuidev [+o seebs] by ChanServ |
| 06:29.37 | Repo | imhobags: Amaedeus master * 0.18beta2-20-g90bd2d5 / (2 files in 2 directories): [+2 commits] |
| 06:29.37 | Repo | 90bd2d5: Fix for "performance warning In ImhoBags / Item.Dispatcher.eventItemSlot" |
| 06:29.37 | Repo | 360ca25: The SetCategorySortWindow will now allow (order) values to be 'blank' while editing (however, having a blank value will still result in an error message when the "apply" button is pressed.) |
| 06:31.02 | Repo | imhobags: Amaedeus master * 0.18beta2-21-g45f7f51 RiftAddon.toc: [+1 commit] Tagging 0.18beta4 (alpha) |
| 08:48.31 | *** join/#riftuidev Repo (~repo@76.164.170.2) |
| 10:44.55 | Repo | gadgets-buffs: Lifeismystery master * v0.1.10-3-g76a23b0 (6 files in 1 directory): [+1 commit] 1. Add option to setup prioritise buffs by soursy (Thanks Whitenight88 for doing this) 2. Add text outline to buff bar 3. Add border to buff bar |
| 11:02.09 | Repo | gadgets-buffs: Lifeismystery v0.5.0 * 7587b7e /: [new tag] |
| 15:11.02 | *** join/#riftuidev Noshei (~quassel@c-24-9-171-99.hsd1.co.comcast.net) |
| 15:21.40 | Ivnedar | someone didn't feed the hampsters I guess |
| 15:21.56 | Ivnedar | explains why none of the mobs I've killed were skinnable :) |
| 15:41.05 | Noshei | this is odd |
| 15:41.09 | Ivnedar | hrrm? |
| 15:41.14 | Noshei | just logged in and my daily patron gift isn't there |
| 15:41.41 | Ivnedar | servers crashed pretty badly |
| 15:41.44 | Ivnedar | lots of lag now |
| 15:41.50 | Ivnedar | so maybe they're not showing up yet |
| 15:41.53 | Noshei | yeah |
| 15:42.27 | Ivnedar | ooh, mobile client server is back too, nice |
| 15:49.52 | *** join/#riftuidev Imhothar__ (~Imhothar@ppp-93-104-176-184.dynamic.mnet-online.de) |
| 16:13.51 | *** join/#riftuidev Imhothar___ (~Imhothar@ppp-188-174-97-129.dynamic.mnet-online.de) |
| 16:53.34 | *** join/#riftuidev Imhothar (~Imhothar@ppp-93-104-181-192.dynamic.mnet-online.de) |
| 18:15.16 | *** join/#riftuidev Imhothar_ (~Imhothar@ppp-188-174-7-104.dynamic.mnet-online.de) |
| 18:36.30 | *** join/#riftuidev zz_Cidan (~cidan@2605:e000:9fc0:2b:545b:aa75:bce7:5c69) |
| 18:36.55 | *** join/#riftuidev Cidan (~cidan@conspiracy/developer/Cidan) |
| 20:54.35 | *** join/#riftuidev Imhothar__ (~Imhothar@ppp-93-104-169-127.dynamic.mnet-online.de) |
| 21:05.14 | *** join/#riftuidev Imhothar___ (~Imhothar@ppp-188-174-4-64.dynamic.mnet-online.de) |
| 23:11.47 | Repo | king-molinator: kekoas * r762 (12 files in 3 directories): (762) Templates and Mechanics for Intrepid Drowned Halls. |
