EVE Search - Fix your netcode to be better than that of a pregnant yak's please

All Channels

Test Server Feedback

Fix your netcode to be better than that of a pregnant yak's please

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: [1] 2 :: one page
Author	Thread Statistics \| Show CCP posts - 0 post(s)
xDaKewlGuyx Pator Tech School	Posted - 2008.01.06 02:27:00 - [1] Edited by: xDaKewlGuyx on 06/01/2008 02:28:06 http://www.eve-img.com/aaaaccp.png hurf a durf durf let's send megabyte+ sized packets to update state data, which have to be broken up and reassembled, then wonder why we get node crashes and crippling lag in big fleet battles
Westly Synpa GoonFleet GoonSwarm	Posted - 2008.01.06 02:31:00 - [2] Edited by: Westly Synpa on 06/01/2008 02:31:41 Originally by: xDaKewlGuyx Edited by: xDaKewlGuyx on 06/01/2008 02:28:06 http://www.eve-img.com/aaaaccp.png hurf a durf durf let's send megabyte+ sized packets to update state data, which have to be broken up and reassembled, then wonder why we get node crashes and crippling lag in big fleet battles you should have gotten a proper image host i'll just post it again. http://img526.imageshack.us/img526/1293/aaaaccphh6.png
xDaKewlGuyx Pator Tech School	Posted - 2008.01.07 04:15:00 - [3] bump truck go 4eva
Smakko Ad Astra Vexillum Brutally Clever Empire	Posted - 2008.01.07 04:44:00 - [4] oh god that's pretty horrible. Has the netcode even been updated since beta? I was in beta briefly but horrified by the state of the game. I remember back then the netcode was all redone. But netstat doesn't lie... Yikes. Proposal to Address Node Death
Westly Synpa GoonFleet GoonSwarm	Posted - 2008.01.07 16:31:00 - [5] Originally by: Smakko Edited by: Smakko on 07/01/2008 05:46:11 Has the netcode even been updated since beta? I was in beta briefly but horrified by the state of the game. I remember back then the netcode was all redone. The screenshot used above was Ethereal (linux version I think). There is a windows version as well. The name of the project was changed recently, here's the sourceforge page: http://sourceforge.net/projects/wireshark/ Anyone who's interested can download wireshark and capture some packets and see for themselves. I just ran some initial tests and it looks terrible. I didn't realize I was having so many problems talking with EvE. Gonna have to run some more tests and see if it's something in my setup or something specific to EvE but yikes. What it looks like is there are some big packets being sent back and forth with many slices getting garbled and resent. Lots of TCP errors. All of the large packet stuff is on the eve server side. I dont understand why its so hard to fix this.
Virtuozzo IRON Tech Imperial Republic Of the North	Posted - 2008.01.07 17:09:00 - [6] Explain it to a non-expert for a moment? CAOD FTW.
Alexander Knott Ars ex Discordia GoonSwarm	Posted - 2008.01.07 17:59:00 - [7] Edited by: Alexander Knott on 07/01/2008 18:04:22 Edited by: Alexander Knott on 07/01/2008 18:03:25 Every type of network (such as Ethernet, Sonet, ATM) has what is known as an Maximum Transmission Unit (MTU). For Ethernet, this value is 1500 bytes. When a router receives a packet larger than the MTU of the length it is to be transmitted on, it has to break the packet up into smaller packets to transmit. This is known as fragmentation. Fragmented packets travel through the network and are reassembled at the destination host. However, if any of the fragments are lost in flight (like when there's a congested router along the way), the sending computer has no choice but to re-transmit the ENTIRE original packet. So, if a 1MB packet is sent, it is broken up into 700 1500byte packets and transmitted. If any of those packets don't make it to the destination host, all 1MB of data again. Because of this, standard industry practice is to just not send packets larger than 1500 bytes (there are also ways to discover the minimum MTU between two hosts in case you really want to send larger packets). Edit: Also, looking at the screenshot and not being 100% familiar with Ethereal output, I'm not sure if it's talking about IP fragments or if this is just the normal packetization of a TCP stream. Looks like the former, but guess it could be the later. Edit again: Damn you Virt for editting out your question! ----- "I like to loot, especially going to the can of the battleship, sometimes there is a surprise inside, sometimes there is only carp..."
Adunh Slavy Ammatar Trade Syndicate	Posted - 2008.01.07 18:09:00 - [8] Virtuozzo, A Crash course in Transport. When you send data over a network, the data has to be sent in manageable sizes. Think of it as a radio signal. Two people can't speak on the same frequency at the same time, the end result will be garbled noise. So the data is split up into tiny little parts so everyone has their chance to speak on the radio frequency. So, if you have a large data chunk, that large chunk has to be broken up into lots of little parts, sent over the network and then reassembled at the destination. The way IP works, one can never say for sure which route the data will take to get to get from one place to another. As such one can never be sure in which order all the little parts will arrive at the destination. What this means is that the destination has to wait for all the little parts before it can reassemble the message. If any of the little parts is delayed or lost, then the entire message is useless and/or can not be acted upon until it is assembled correctly. Going back to the radio analogy, suppose you have a message and you want to send it to someone else, but there are also 200 other people on the same frequency. To send your message, you're only allowed to send one letter at a time and a number to say in which order the individual letters should be assembled, so that everyone gets a chance to use the radio frequency. Now imagine if you have to relay that message through a number of other radio operators to get the message to the final location. What happens if one of those letters is lost, the destination radio operator has to let you know to resend that part or perhaps the entire message again. The longer your original message is, the more time it takes to do all of this. What happens if you have to send me and 800 other people that large message. Now imagine you have to send lots of large messages to lots of people. Imagine if one or more of those people report back to you that they need one of those earlier messages again or just one letter, you have to back and retransmit that message or part of it again and continue sending the current messages as well. If you could send smaller messages, then you can be more efficient and the destination will be able to assemble your smaller messages more quickly and act upon them instead of sitting there waiting for one large message before it can do anything. The Real Space Initiative - V5 (Forum Link)
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.01.07 23:30:00 - [9] Edited by: Draygo Korvan on 07/01/2008 23:30:43 Originally by: Smakko I just ran some initial tests and it looks terrible. ... Lots of TCP errors. Careful when reading data from programs like that one it might mark checksum errors on all outgoing TCP packets. This is not the fault of Eve or your hardware. Its simply because the program sees the packet before the network card handles it, and the checksum is an operation of the network card so the CPU doesn't have to spend any processing power on it (you can disable this functionality of the card by disabling Hardware Checksumming (or TCP Checksum Offload) in the Advanced tab under your ethernet controller properties [the properties window with the driver/resources tab not the lan connection properties]). --
Smakko Ad Astra Vexillum Brutally Clever Empire	Posted - 2008.01.07 23:35:00 - [10] Originally by: Draygo Korvan Careful when reading data from programs like that one it might mark checksum errors on all outgoing TCP packets. This is not the fault of Eve or your hardware. Its simply because the program sees the packet before the network card handles it, and the checksum is an operation of the network card so the CPU doesn't have to spend any processing power on it (you can disable this functionality of the card by disabling Hardware Checksumming (or TCP Checksum Offload) in the Advanced tab under your ethernet controller properties [the properties window with the driver/resources tab not the lan connection properties]). Ah, I was able to disable something in the wireshark prefs and it looks a lot less scary now. Gonna run a capture during a big fleet op and see what I get, but this is a fun project anyways, whether or not it turns up some big eve bug. Proposal to Address Node Death
Xeliya Eternity INC. Mercenary Coalition	Posted - 2008.01.08 07:37:00 - [11] Edited by: Xeliya on 08/01/2008 07:39:34 I don't know much about networking but I do know big packets = bad idea, especially in a game over TCP. Also wouldn't using UDP solve 90% of the major lag issues in the game? Yes you will still have lag but having to resend probably every other packet (as the system is overloaded) isn't really the best thing. I would also think it would fix the mysterious desync as it would just make their ship stutter instead of being behind due to packets needing to be resent. Feel free to correct me if I am wrong as I am not a network geek
Gaogan Gallente Solar Storm Sev3rance	Posted - 2008.01.08 18:35:00 - [12] There are no big packets, there is no IP fragmentation ( the do not fragment bit is set ), there's nothing to see here, move along. But yes, games SHOULD be using UDP, possibly with an additional TCP session to carry things that need to be reliably delivered, like chat text.
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.01.08 21:04:00 - [13] MTU determines maximum fragment size, not some TCP flag. TCP can set the MSS (maximum segment size) its willing to transmit but that won't prevent fragmentation if the MSS is bigger than the path MTU. Any packet bigger than the path MTU (any hops MTU size between the server and the client) will be fragmented, or denied with a Destination unreachable (datagram too big). What happens when the do not fragment bit is set is that when a packet too large is attempted to be transmitted instead of fragmenting the packet it will be dropped or 'stuck' and the sender will recieve a Destination unreachable (datagram too big). Setting that bit is a way to try to discover the path MTU, but is generally left at 0 during regular data transfer. (And EVE generally has that set to 0, which it should be). And a [TCP segment of a reassembled PDU] is a fragment of a packet. I do agree with your assertion that Eve should be using UDP instead of TCP, I know that changing eve's netcode will take a lot of time as well. --
Arcadia1701 Gallente The Scope	Posted - 2008.01.09 02:34:00 - [14] Well. Wont all this be solved with the incomming * infinband* servers in march? Since they will no longer be TCP linked? OR do i have it all totaly wrong? My sig> Post with your main, or don't post at all. My Skills
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.01.09 03:38:00 - [15] No, this can only be changed at the software level. --
K'reemy G'udness The Greater Goon GoonSwarm	Posted - 2008.01.09 11:24:00 - [16] HURFITY BLURFITY BOO, please fix this CCP. You know why. ---
Dr Slaughter Rabies Inc.	Posted - 2008.01.09 11:35:00 - [17] Originally by: Arcadia1701 Well. Wont all this be solved with the incomming * infinband* servers in march? Since they will no longer be TCP linked? OR do i have it all totaly wrong? somewhat wrong. It's pretty unlikely there is a 'real' issue with the networking code, as seen in the capture above, but someone needs to do more analysis to be sure. Infiniband is likely to be used to shunt state data between hosts using RDMA rather than wrapping the connections up with TCP/IP but who knows what CCP will do until they announce it.. CCP this is not the nerf you are looking for...
Will Hunter GoonFleet GoonSwarm	Posted - 2008.01.09 14:41:00 - [18] to the top
RaTTuS BIG Ka-Tet	Posted - 2008.01.09 15:14:00 - [19] why? the infiband is just for server use it will not affect client software udp is not guaranteed delivery - you'll get many more desyncs that way they should try and make packets smaller - though it still works down a 56k modem so it cannot all be bad [though dont do fleet battels or jita there] -- BIG Lottery, BIG Deal, InEve [Now Verified] & Recruiting
Draygo Korvan Merch Industrial GoonSwarm	Posted - 2008.01.09 22:06:00 - [20] Edited by: Draygo Korvan on 09/01/2008 22:07:12 Originally by: RaTTuS why? the infiband is just for server use it will not affect client software udp is not guaranteed delivery - you'll get many more desyncs that way they should try and make packets smaller - though it still works down a 56k modem so it cannot all be bad [though dont do fleet battels or jita there] UDP isn't guarenteed delivery, not that you need guarenteed delivery to keep a simulation in sync. Most recent state data is all you need, lost packets dont have to be retransmitted (thus wasting bandwidth). --
Anaalys Fluuterby Caldari	Posted - 2008.01.09 22:19:00 - [21] Originally by: Draygo Korvan UDP isn't guarenteed delivery, not that you need guarenteed delivery to keep a simulation in sync. Most recent state data is all you need, lost packets dont have to be retransmitted (thus wasting bandwidth). True, but UPD also does not gracefully run through firewalls as well and can cause major issues with multiple clients behind one. All in all, TCP is a lot more stable accommodating such even if it has to deal with lost packets. Originally by: Audri Fisher On the other, the emo tears being cryed in this thread tell me that just because you shoot somebody for a living, does not mean you aren't a carebear
Dr Slaughter Rabies Inc.	Posted - 2008.01.10 00:00:00 - [22] Any protocol geeks care to comment on how using SCTP between the proxy and the client might effect things? CCP this is not the nerf you are looking for...
Trishan Green Men Incorporated	Posted - 2008.01.10 16:51:00 - [23] Originally by: Gaogan But yes, games SHOULD be using UDP, possibly with an additional TCP session to carry things that need to be reliably delivered, like chat text. No, that's a very wild generalization. Nowadays TCP is reliable enough, and it depends on whether the particular game can still work fine if it misses packets.
Danzir Kasnov Gallente GoonFleet GoonSwarm	Posted - 2008.01.10 17:10:00 - [24] Regarding using UDP. As I understand CCP's policy with eve is to keep state information 100% accurate. Using UDP as has been mentioned means not all packets will end up necessarily being transmitted so the state information could become inaccurate. This is the main reason CCP have stuck with the more robust TCP protocol. I'd be interested to hear a network dev comment on this topic and specifically about 1mg packets. Surely the main state information can be condensed better than that. You need a fair few coordinates, and a fair few variables associated with yourself and your targets, but your not talking megabytes here...
Isayo Arkindra Mercurialis Inc. Interstellar Alcohol Conglomerate	Posted - 2008.01.13 01:17:00 - [25] This deserves to be on first page untill CCP responds. __________
Dahin Maza Nostra oooh Shiny	Posted - 2008.01.13 11:17:00 - [26] Edited by: Dahin on 13/01/2008 11:20:14 ummm, use UDP make no sense? All you manage by using udp is move the error detection, correction and packet ordering to your application. Unless you don't really need one, like vent/ts (oh well, 1/10'th of someones voice got lost, who cares?). Would you care if your "scramble target" command got lost in the way? I bet you would :P Packet ordering: "we're sorry your shoot-target packet arrived before the new lock target, as such you are now shooting your alliance mate in empire while repairing him. Please bend over for concord". Well, I bet eve doesn't work that way but you get the idea Why fly covops? http://www.youtube.com/watch?v=u0WOIwlXE9g
Isayo Arkindra Mercurialis Inc. Interstellar Alcohol Conglomerate	Posted - 2008.01.15 00:28:00 - [27] Back to the first page we go! __________
Jimbob McKracken Caldari The Tidemark Interstellar Alcohol Conglomerate	Posted - 2008.01.15 01:03:00 - [28] As far as I was aware the eve server doesn't check every client to see if it is in sync, it just blindly shoves data to the clients. So the radio operator arguement, while having merit is slightly flawed in that the server doesn't wait for a response from the client, which is why the desync's occur, although I'm no expert. Any commands sent from your client to the server will be waiting on a response from the server, but the server does not care in the slightest if your client thinks you in Jita or still stuck at the gate with the "jumping in" message.... etc... It's very difficult to say if the netcode in eve is broken I haven't seen another game with 400 people on the same shard, which has every other shard in the world connected to it also. I do feel that the way large numbers of people inhabiting the same system is not handled very gracefully and that it is quite random, sometimes handling 200 - 300 people without much hassle and in other situations being monumentally bad. Maybe the netcode does need an update, the need for speed intiative hasn't in my opinion had any major effect on fleet battle lag, but I have seen a greater peak server population. The largest change I've seen to the performance of the client during fleet ops was the lag introduced with the Dragon code base, the unicode client. I noticed an immediate effect, jumping through gates while in large gangs and warping away involved the client pausing on every ship decloaking around the gate. This is still the same. This isn't a whine, more of a "throw it out there and see what comes back" poast. hopefully if the client is sending oversized packets then we it can be traced and fixed.
xDaKewlGuyx Pator Tech School	Posted - 2008.01.16 23:52:00 - [29] ~bump~
Washell Olivaw	Posted - 2008.01.17 06:20:00 - [30] Originally by: xDaKewlGuyx ~bump~ You know what would have helped getting an answer? Not insulting their work in the subject line and taking a more civil tone in reporting what you noticed. Quote: Everybody has a photographic memory, some people just don't have film.

Pages: [1] 2 :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.