SDL_UDP_Send very slow |
Meldryt
|
|
|||||||||||||
|
Meldryt
|
i read that the winsock functions such as recvfrom() and sendto() could be a problem. When i look into the SDLNet_UDP_Send code, there is nothing that could cause such a huge delay than the sendto() function.
|
|||||||||||
|
SDL_UDP_Send very slow |
MrOzBarry
|
I think you're going to get much response from the SDL community until you provide a small code example of what you're doing. Also, some operating systems smallest grandularity for milliseconds is 10ms, so your ops may be taking less.
Also, 10ms is extremely reasonable for a game, and your slow down is probably waiting for a response over UDP. From here, I'd really recommend trying to understand the type of prioritization you want your game to use to get the performance you think you should be getting. Think of it this way: What type of data needs to:
SDL provides very low level network access where writing a network engine around it to prioritize packets may not be efficient (it can be done, but it's really a separate project altogether). There are libraries that handle this, or some work arounds. For libraries, enet may be an excellent choice to light weight, fast and prioritized messages. If you want to go the SDL route, there is the easy way or the hard way. The easy way is to just use a secondary socket connection over TCP. TCP is very slow in comparison to UDP, but can provide you with a stable for data that you don't care about the speed (like text chat in game, initialization/deinitialization, etc.), and leaving UDP for things you want to be done faster (like updating a player position, physics information, etc.). This is like a poor man's two channel system, but it works, and can guarantee if a client is connected (where UDP may not be able to give this to you). Going the hard way means implementing what some would call and networking kernel, which may or may not run in a separate thread, and when you push data through it to the server, you would want to mark the channel you want it to go through, or some sort of priority marker. To be honest, the hard SDL way is really not necessary when there are other libraries that do the same job that have been tried and tested, which gives you one less thing to deal with. I'm hoping that helps you out a bit, -Alex On Sun, Feb 22, 2015 at 10:50 AM, Meldryt wrote:
|
|||||||||||||
|
SDL_UDP_Send very slow |
john skaller
Guest
|
On 23/02/2015, at 4:05 AM, Alex Barry wrote:
Or perhaps consider 0MQ. TCP and UDP are generally both entirely incapable of ANY application level communication: neither protocol can handle the concept of messages. -- john skaller http://felix-lang.org _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL_UDP_Send very slow |
MrOzBarry
|
Well, zeromq is great (I've used it a pile of times myself), but I can't attest to it's use in games, but it is a reasonable option. I don't, however, believe 0mq supports UDP, which is what Meldryt is using at least now. If he's struggling with 10ms delays (again, it's probably slightly less, but not measurable on his/her system), TCP may not be the route to take.
Also, I'm not sure what you mean by TCP and UDP being incapable, since those are the two main basic lowest level sockets available to any system (TCP is even used in 0mq). On Sun, Feb 22, 2015 at 5:08 PM, john skaller wrote:
|
|||||||||||||||
|
SDL_UDP_Send very slow |
Jonas Kulla
Guest
|
2015-02-21 19:25 GMT+01:00 Meldryt:
You might want to try using SDL_GetPerformanceCounter() to get more accurate results, although it shouldn't differ greatly from what SDL_GetTicks() is telling you. |
|||||||||||||
|
Meldryt
|
What i trying to do is called Sync Sim.
All players of the network synchronize the game over the frame. That means they have 32 ms (for a 30 fps games) to do there work (receiving, sending packets, simulation). After lot of testing yesterday i can say that the linux and mac version run much better than the windows version. On windows i have that peaks in SDLNet_UDP_Recv and SDLNet_UDP_Send. |
|||||||||||
|
SDL_UDP_Send very slow |
john skaller
Guest
|
On 23/02/2015, at 3:01 PM, Alex Barry wrote:
Oh, I thought it does .. could be wrong though. It supports operations on a lot of different transports. Some of the operations are available on UDP and others not. But I could be wrong..
Sure, however it could depend on what operations are being used. My system (I don't use SDL networking) uses a separate p-thread which uses the OS specific notification system (kqueue, epoll, etc etc) and asynchronous sockets, so there's no delay to the application at all unless it becomes starved.
What I mean is that stream protocols are of no use to most applications. Applications, generally, require sending messages, not byte streams. So generally one has to provide a higher level messaging protocol on top of a stream protocol for it to be useful to an application. Although it may seem this is easy .. the reality is that this is a "bleeding edge" research topic. -- john skaller http://felix-lang.org _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
SDL_UDP_Send very slow |
ludi
Guest
|
Hi,all
I have a blog about messaging using tcp in chinese: http://blog.csdn.net/deyangliu/article/details/42927997†------------------ Original ------------------ From: "john skaller";; Date: Mon, Feb 23, 2015 06:08 AM To: "SDL Development List"; Subject: Re: [SDL] SDL_UDP_Send very slow On 23/02/2015, at 4:05 AM, Alex Barry wrote:
Or perhaps consider 0MQ. TCP and UDP are generally both entirely incapable of ANY application level communication: neither protocol can handle the concept of messages. -- john skaller http://felix-lang.org _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Meldryt
|
I will give SDL_net another try.
As i said before im sending and receiving udp packets with a max length of 192 and a data length of 96. More precisely i do about 130 send calls per second and about 750 recv calls per second. So im running my game with two connected players over wlan, sending and receiving udp packets. Most of the time when i have troubles with not receiving packets i miss them in a row. And than after several frames i receive all of these old packets with one recv call. I had always thought that i lost those packets, but i simply receive it too late. Is it possible that my network,socket... is somehow overloaded at this time? Do i have to use several sockets for every player and rotate between them or recude number of send/recv to avoid this? |
|||||||||||
|
SDL_UDP_Send very slow |
MrOzBarry
|
Are you waiting to receive a certain length, or a certain order? UDP is quite unreliable in terms of order and reliability (packets can be lost).
I think we may have to see some of your network code to better understand what's happening. On Fri, Feb 27, 2015 at 9:14 AM, Meldryt wrote:
|
|||||||||||||
|
Re: SDL_UDP_Send very slow |
Meldryt
|
im not waiting for a certain order or anything else. that is how i create my socket and udp packet
that basically is the receive function in which i update the inputdata from the other players. NETPACKETS is 16, and PACKETSIZE is 192
thats the send function
|
|||||||||||||||||||
|
SDL_UDP_Send very slow |
Luke Groeninger
Guest
|
I’m not a networking guru, but this sounds suspiciously like you’re overflowing a packet queue at some point in the network stack. It would also explain some of the performance issues involved. I would highly recommend finding a way to reduce the number of packets transmitted and increase the amount of data being sent per packet. This should, in general, yield better performance over a network anyways - they don’t do well with lots of tiny packets because they are high latency, high bandwidth connections. Wireless lans are particularly bad about this because typically only one client can be transmitting at once - and at the worst case, the base station needs to retransmit the data for the client, further reducing the amount of data a client can transmit each second. I would also suggest not using an architecture that requires all clients to perform a full state synchronization per frame. There are a ton of techniques involving client prediction and interpolation that can dramatically reduce the frequency in which clients have to synchronize, and help deal with poorly performing networks. A common design pattern for single threaded engines is simple to 1) read incoming data at the start of the frame, 2) process state changes from the server, 3) process state changes from the local client, 4) transmit these state changes to the server without waiting for an acknowledgement, and 5) do graphics/audio rendering until the end of the frame. By allowing the clients to be slightly out of sync on a per-frame basis it allows for significantly higher networking performance (and eliminates the need to repeatedly spam send/receive within a single frame). -Luke |
|||||||||||||||||||
|
SDL_UDP_Send very slow |
MrOzBarry
|
Packet compression is always a good idea, even if it's smaller bits of data.
On Fri, Feb 27, 2015 at 1:22 PM, Luke Groeninger wrote:
|
|||||||||||||||||||||
|
SDL_UDP_Send very slow |
Daniel Gibson
Guest
|
On 02/27/2015 07:24 PM, Alex Barry wrote:
Not necessarily. A (IPv4) UDP packet always has 12bytes/96bits. He wrote "max length of 192 and a data length of 96." so I assume that he's talking about bits (192bit packet length - 96bit data = 96bit header). So he already has 100% overhead from headers per paket.. making the data even smaller by compression (if that's even possible for 12byte data) doesn't make much sense. For comparison: It should be safe to use UDP packets with about 1400 bytes of data nowadays (Ethernet: about 1500bytes incl IP+UDP headers, Internet over PPPoE: about 1492bytes incl. IP+UDP headers, see http://en.wikipedia.org/wiki/Maximum_transmission_unit ) - with 1400bytes of data you'd have less than 1% overhead from the headers. So, as Luke wrote: Try to put more data into the same packet - and in that case compression could actually make sense - so you'd have less packets per frame. Maybe just try sending 10 or so packets with dummy data around each second instead of 130 just to check if that makes any difference with your latency. If latency is still high there is a problem in your network, windows' network stack, SDL_net or your code. After that you could try some network benchmarking tool (maybe iperf?) and check if that reports high latency. If it doesn't, the problem might be in SDL_net or your code. (Btw, 130packets/second is just over 2packets per frame @60fps, doesn't sound *that* horrible.) Cheers, Daniel
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||||
|
Meldryt
|
192 and 96 are bytes. The problem is that i have to send at least 1 better 2 packets per frame (60 packets per sec for a 30 fps game), to keep the game synchronized over the network. I dont know if it makes sense to put the same data multiple times in one packet, if this packet can get lost. |
|||||||||||||
|
Re: SDL_UDP_Send very slow |
Alex
|
Luke Groeninger is right. Listen to him. For example in my game (I working on now), I need to resync only about 5-6 times per second (according to characters speed). It is much more rare syncing than each frame. In most cases syncing every frame is not needed. |
|||||||||||||
|
SDL_UDP_Send very slow |
john skaller
Guest
|
On 28/02/2015, at 6:52 AM, Meldryt wrote:
If your design requires synchronisation you must use TCP/IP and be prepared to lose visual frames to keep the engine synchronised (at least at a high frame rate). So if you use UDP, it is like the real world and you must design your program that way too. One way is: Client/Graphics <- TCP -> Local Server <-- UDP -> Master Server The local server will just have to make guesses as to the state at each point in time, corrected by unreliable data from the master server. Laggy corrections will cause unexpected physical effects... ... welcome to real human brain function! You try killing Diablo in the Chaos Sanctuary at 1 FPS. -- john skaller http://felix-lang.org _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|