On 24/02/02 05:02, Jack Moffitt shaped the electrons to say:> > - The server didn't check for the status of the client's socket before > > the unblocking send(). This caused a disconnection at a minimun network > > congestion, causing a broken pipe error (Linux 2.4 behaviour?) in the > > network. I've just added a poll in sock.c.> > Can you send me this patch alone? I still can not tell what you're > doing, as no one else has reported these kinds of problems.It the first problem I found when I started to use the server and the reason I began to modify it. The patch is sock.diff> > - Added TCP_NODELAY to a nonblocking socket. It is said that it's improve > > performance in Linux. TODO: check Win32 compatibility. > > What's it supposed to do in general? I've had varying success with the > advanced socket options.Turn the Nagle algorithm off, so there it doesn't introduce delays (although it can generate more messages). Should be tested in severeal conditions. <p>> > - Solved a bug in source.c, when checking for recoverable error. It has> > to be done _only_ when result < 0. > > Can I see this patch separate too?No completely because I moved part of it to the new send_queue() function, but basically is: - if (!sock_recoverable(bytes)) { + if (sbytes < 0 && !sock_recoverable(bytes)) { <p><p><p>> > I was very careful checking connection and memory leaks, the maximum RSS> > reported by ps is 1288 KB (after running several days). > > Which I assume means you didn't find any :)Nope. <p> -- ricardo "I just stopped using Windows and now you tell me to use Mirrors?" - said Aunt Tillie, just before downloading 2.5.3 kernel. -------------- next part -------------- A non-text attachment was scrubbed... Name: sock.diff Type: text/x-diff Size: 2292 bytes Desc: sock.diff Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20020224/fb5b482e/sock.bin
On Sun, Feb 24, 2002 at 09:04:03AM +0100, Ricardo Galli wrote:> Sorry, didn't explain well. > > Nagle's algorithm (rfc896) buffers user data until there is no pending acks > or it can send a full segment (rfc1122). > > icecast doesn't need it at all, because it already sends large buffers and > the time to send the next buffers is relatively very long.IMO we should be using the nagle algorithm. It greatly reduces protocol overhead and there will always be less than 1500 bytes unsent. This is small compared to the average client buffer size of 32k. Since we send ~4k chunks, this equates to either: NODELAY: 1500 byte packet (1460 bytes data) 1500 byte packet (1460 bytes data) 1196 byte packet (1176 bytes data) == 2.9% overhead NAGLE: 1500 byte packet (1460 bytes data) 1500 byte packet (1460 bytes data) 1500 byte packet (1176 bytes data, plus 284 from next chunk). == 2.7% overhead That .2% is significant when we're talking about low bandwidth links. It also gets considerably worse when we take into account modem buffering, smaller MTUs, and other network circumstances. The advantage to not using the nagle algorithm is that client buffers will be on average 750 bytes fuller. This is only 1/4 second of audio even at 24kbps. Mike -- M. Lyle --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On 22/03/02 22:24, Jack Moffitt shaped the electrons to say:> > It the first problem I found when I started to use the server and the > > reason I began to modify it. The patch is sock.diff > > I still don't understand the problem, nor have I reproduced it. > > We shouldn't need to check the status of the socket before we call > send(). If there were any send errors, we would have seen them after > the last call to send(). Even if we didn't, it shouldn't affect future > calls (at worst, they will fail again). > I think the behavior you were seeing was cuased by the next bug: > > > > - Solved a bug in source.c, when checking for recoverable error. It > > > > has to be done _only_ when result < 0. > > I did look over source.c and you were correct. I have fixed this in > CVS. > > I'm not sure why I didn't see this before, or why it didn't cause more > problems, but then again, apparently it did for you.I was very surprised as well, I was getting very frequent EPIPE errors when testing connection from my home to my server in the university. My "testing environment" has changed radically, at that time I had an ISDN connection, now I've lost it (got DSL), neverthelles I will try to recreate it. ____But___, there was a serious bug which could be the "real" one and was masked by the "poll()" for a while. I've described it in a previous mail and sent the one-liner patch: ------ The problem resided on the conditional variable being signaled twice (or more) after new connections, but the server thread (connection.c) only get the first of the several new connections. ------ This bug is easier to catch, just open a couple of "simultaneous" wget connections from a client in the same LAN. Something like: for i in `seq 100` do wget http://... & wget http://... & wget http://... done <p> -- ricardo "I just stopped using Windows and now you tell me to use Mirrors?" - said Aunt Tillie, just before downloading 2.5.3 kernel. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On 24/02/02 08:17, Ricardo Galli shaped the electrons to say:> > > - Added TCP_NODELAY to a nonblocking socket. It is said that it's > > > improve performance in Linux. TODO: check Win32 compatibility. > > > > What's it supposed to do in general? I've had varying success with the > > advanced socket options. > > Turn the Nagle algorithm off, so there it doesn't introduce delays > (although it can generate more messages). Should be tested in severeal > conditions.Sorry, didn't explain well. Nagle's algorithm (rfc896) buffers user data until there is no pending acks or it can send a full segment (rfc1122). icecast doesn't need it at all, because it already sends large buffers and the time to send the next buffers is relatively very long. <p> -- ricardo "I just stopped using Windows and now you tell me to use Mirrors?" - said Aunt Tillie, just before downloading 2.5.3 kernel. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> It the first problem I found when I started to use the server and the reason > I began to modify it. The patch is sock.diffI still don't understand the problem, nor have I reproduced it. We shouldn't need to check the status of the socket before we call send(). If there were any send errors, we would have seen them after the last call to send(). Even if we didn't, it shouldn't affect future calls (at worst, they will fail again). I think the behavior you were seeing was cuased by the next bug:> > > - Solved a bug in source.c, when checking for recoverable error. It has > > > to be done _only_ when result < 0.I did look over source.c and you were correct. I have fixed this in CVS. I'm not sure why I didn't see this before, or why it didn't cause more problems, but then again, apparently it did for you. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.